January « 2017 « Core-Admin

Archive for January, 2017

Postfix reports “Connection timed out” but telnet works

Posted by Francis Brosnan Blázquez on January 11, 2017

Keyword index

Postfix connection cache
Postfix caching connection timeout
Postfix keeps reporting “Connection timed out”

Introduction

If you happen to find connection timeout reports from Mail delivery reports or directly from log, having a similar information like follows:

Jan 11 07:32:14 server-smtp-01 postfix/error[11965]: 62E6DEBAD: to=&lt;soporte@xxx.cl&gt;, relay=none, delay=17159, delays=17159/0.04/0/0.04, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mailserver.xx.es[194.X.187.X]:25: Connection timed out)

..but at the same time, if you run a telnet operation it works without any problem:

telnet 194.X.187.X 25
Trying 194.X.187.X...
Connected to 194.X.187.X.
Escape character is '^]'.
220 mailserver.xx.es ESMTP

In such context, even if you restart postfix you still find out that it keeps reporting “Connection timed out”.

At the same time, you already checked that no firewall is blocking that connection: for example, root might be allowed to run telnet over such port but not “postfix” user.

Why Postfix keep on reporting “Connection timed out”

All these “Connection timed out” reported by Postfix are usually caused by the postfix connection cache state code: http://www.postfix.org/CONNECTION_CACHE_README.html

That caching code is used by Postfix to speed up operations and avoid keep on talking with slow or failing hosts. It is a performance improvement that, in some cases, might cause problems to you.

At some point in the past, the destination SMTP server started failing with a timeout. Then, that state was cached by postfix causing this problem.

How to solve “Connection timed out” when telnet works

First, try to review configuration parameter “smtp_connect_timeout” to increase it. By default 30 seconds is configured. Do not increase it more than 90 because it might cause you other problems.

After that, run the following commands to requeue and restart postfix. Remember, this will retry everything:

postsuper -r ALL
/etc/init.d/postfix restart

Posted in: Postfix

Controlling postfix content filter Amavis with Valvula (access policy delegation protocol)

Posted by Francis Brosnan Blázquez on January 9, 2017

Key index

Limiting Amavis with policy delegation
Limiting Amavis with Valvula policy server (http://aspl.es/valvula)
Limiting content filter service with Valvula policy server

Abstract

Controlling mails checked or produced by Content Filter server (Amavis) by the access policy delegation protocol (Valvula) configured at Postfix.

Introduction

Due to the way Postfix works when you configure the parameter “content filter =”, where you configure Amavis or any other Content Filter service, this makes all mail that comes in into Postfix queue, to be then sent to Amavis (or the content filter server you might have) so that mail is processed and, in turn, if everything is fine, that mail comes back to Postfix through a different internal port (typically 10025/tcp).

From here, we will assume your Content Filter service is Amavis and Valvula your policy delegation server. If it is not the case, this article is still relevant for your configuration.

Once Amavis have decided that everything is correct, that mail is sent back to postfix in a dedicated port usually declared as follow at /etc/postfix/master.cf:

# amavis connection, messages received from amavis 
127.0.0.1:10025 inet n - y - - smtpd
 -o content_filter=
 -o local_recipient_maps=
 -o relay_recipient_maps=
 -o smtpd_restriction_classes=
 -o smtpd_client_restrictions=
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_recipient_restrictions=permit_mynetworks,reject 
 -o mynetworks=127.0.0.0/8
 -o strict_rfc821_envelopes=yes
 -o receive_override_options=no_address_mappings

As you can see, any mail will be accepted on that port (10025) as long as it comes from localhost (total trust).

However, the problem we want to solve is how to deal with mails originated from within the server itself (submitted by mail/maildrop) or because a mailman installed (or some configuration produced by the Content Filter server that might produce mails by itself) to make them be also limited by your policy server (Valvula).

In that case, given the configuration above, all mails that comes in into Amavis, are not controlled by the policy server you might have installed (in this article Valvula).

What to change to make policy server be called so your policy is applied

With this information identified, in the case it is required to filter mails sent back to postfix by the Content Filter server, you can update the following parameter:

        -o smtpd_recipient_restrictions=permit_mynetworks,reject

..to the following:

        -o smtpd_recipient_restrictions=check_policy_service,inet:127.0.0.1:3579,permit_mynetworks,reject

This is the recommended setting with Core-Admin, where the relevant part is “127.0.0.1:3579″ and has to be updated with your local settings.

This way when Amavis finishes, that mail will have to go through Valvula when it goes back to postfix.

Interactions that might cause this configuration

This change might make Valvula (or the policy server configured) to be called twice for every mail received. First when it is received and second after Amavis finishes processing mail.

Why not configure this by default

This configuration here described might be interesting in some scenarios.

For the case of dedicated mail servers this configuration is not useful/needed. We mean “dedicated mail servers” those that do not have mailing list software, web pages or any other software that might produce mail internally that might be needed to be limited, blocked or discarded.

In the other hand, this configuration might not be interesting in all those cases where this limitation can be done in origin (updating the configuration of the service producing those mails to limit) or even using postfix’s authorized_submit_users.

In short, this is not the only configuration available to limit/control mails from inside the server using policy delegation protocol.

Posted in: Administrador de Correo, Amavis, Postfix, Security, Valvula

Let’s Encrypt: the silent revolution

Posted by Francis Brosnan Blázquez on January 7, 2017

Let’s encrypt: the silent revolution of SSL certificates

If have ever bought a SSL certificate —in fact that is the old name, because now everything is TLS [2] — you will know that they have a cost and that cost is because one “trusted” organization places its “digital sign” in our certificate so that browsers, in turn, through this “trust chain”, accept this certificate.

And that is all about this SSL/TLS technology: trusting chain.

Asymmetric Cryptography: the shortest description ever

To understand why SSL/TLS is so important for today’s internet security and that characteristic “green” we see when we write https:// to access our favorite site, we have to understand what is Asymmetric Cryptography [1] and how it relates with what we mentioned before: “trusting chain”.

Shortly, asymmetric cryptography allows to generate a public certificate and a private key so that everything that is cyphered with the public certificate will only be available for decoding with the private key (which is the one installed at the server and never will get out of there, unless security breach).

On top of this mathematical cryptography pillar lays the TLS protocols [2] (evolved version of SSL), which provides a set of information exchange between the connecting client and the server so both parties can exchange information in a secure manner.

However, there is a “but” and it located in that part that talks about “exchanging information in a secure manner”.

The missing part to complete SSL/TLS: the trusting chain

The only thing that ensures SSL/TLS is that both parties, once completed the handshake, will be able to exchange messages without having to worry about a third party will have access to them as they transit.

However, the big problem to solve follows: how to ensure that we are talking with the server we want to and not another intercepting this communication?

Here is where the trust chain and Certificate Authorities that we all know enter, to name some: GeoTrust, Thawte, Verisign, Comodo…

What extra mile Certificate Authorities provides

With all these technical items identified, the missing piece to complete the puzzle are those companies and organizations that have reputation and due to agreements, they have managed to include their certificates –simplifying the process for the shake of clarify— into browsers so most of them recognizes them by default.

Because browsers accept and trust these certificates, everything that is signed by them will be also recognized and accepted without error.

What provides Let’s encrypt?

The foundational aim of the project is: free and secure certificates for all. But, without having to pay anything to legacy certificate authorities?

Yes. Then, where is the trick? There is no catch.

However, we have to understand its origin to better understand project’s purpose.

Let’s encrypt is an initiative backed by big companies in the tech filed that need their devices, intranets and management portals, etc, to have a certificate recognized by most of all browsers.

After all, what stop these companies to reach similar agreements with browsers’ vendors so their certificates are also supported?

Mixing a protocol to validate and deploy certificates, let’s encrypt not only provides certificates that are totally recognized and without costs: it also automates requesting and configuring certificate, freeing from this burden to system administrators.

Then, will certificate authorities disappear?

In our opinion, no. They will have to specialize to issue certificates that requires a new extra mile. At the same time they will keep issuing certificates for companies, entities and organizations. That is where Let’s Encrypt “do not want to go” (but they could).

[1] https://es.wikipedia.org/wiki/Criptograf%C3%ADa_asim%C3%A9trica
[2] https://es.wikipedia.org/wiki/Transport_Layer_Security

Posted in: Let's Encrypt, Security, SSL/TLS