Noviembre 2

SMTP AUTH Connection Tests

When configuring an OutBound SMTP Relay, it is important to restrict the access to owned / authorized networks or to specific users with authentication (to not be used as ‘OpenRelay Server for garbage submission).

For this reason it is important to know how-to check if the Authentication Mechanism is working perfectly.

In order to issue the AUTH command to an SMTP server, it is fundamental to have the base64-encoded version of the Username and Password.
This perl command (MIME::Base64 module is required) will do the encoding:

perl -MMIME::Base64 -e\
 'print encode_base64("\000username\000password")'

The output (in this case) is: AHVzZXJuYW1lAHBhc3N3b3Jk

Depending on server configuration, would be necessary to use SSL or TLS before sending the AUTH command.
Sending the AUTH command without using SSL or TLS, would mean sending username and password in clear text, this is obviously insecure.

To connect to a NON-Secured SMTP server on IP address 1.2.3.4, it is possible to simply use telnet client on port 25 (SMTP) or 587 (Submission):

# telnet 1.2.3.4 25

To check if a server supports TLS, send the EHLO command during an unencrypted SMTP session (example running in localhost):

# telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
relay postfix/smtpd[XXXX]: connect from localhost[127.0.0.1]
220 relay.test.bravi.org ESMTP Postfix (2.8.5) OutBound relay
EHLO TEST
250-relay.test.bravi.org
250-PIPELINING
250-SIZE 32768000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
relay postfix/smtpd[XXXX]: disconnect from localhost[127.0.0.1]
221 2.0.0 Bye
Connection closed by foreign host.

If “STARTTLS” capability is present on the list, the server will accept STARTTLS command. It is possible to use the “-starttls smtp” option of openssl s_client to connect.
This makes openssl connect normally (without encryption), send a STARTTLS command, negotiate the SSL encryption, and then allow you to interact with the encrypted session.

openssl s_client -starttls smtp -crlf -connect 1.2.3.4:25

Or for Submission:

openssl s_client -starttls smtp -crlf -connect 1.2.3.4:587

For SSL server with SSL Wrapper enabled (SMTPS) the command would be:

openssl s_client -crlf -connect 1.2.3.4:465

Analyzing previous telnet session (EHLO command response) if AUTH is on the list, and that PLAIN is one of the supported options, it is possible to test authentication as follows:
1. Authencication OK:

AUTH PLAIN AHVzZXJuYW1lAHBhc3N3b3Jk
235 2.7.0 Authentication successful

2. Authencication KO:

AUTH PLAIN AHVzZXJuYq3rrHBhc3N3b369
535 5.7.8 Error: authentication failed

Once authenticated, it is possible to continue with a normal SMTP session.

Category: POSTFIX, POSTFIX, TIPS AND TRICKS | Los comentarios están deshabilitados en SMTP AUTH Connection Tests
Octubre 1

Reduce SPAM and improve security – Amavis + SpamAssassin + ClamAV + Procmail + PostScreen

Installation

and we will also add some compression tools to be able to scan the archives for viruses too.

Postscreen is part of Postfix and does not require additional package.

Configuration

  • ClamAV:

Per default, ClamAV will automatically update its database every hour. If you want to update it now, you can run:

Then, to avoid ownership issues during scans from ClamAV and Amavis, we need to add ClamAV and Amavis users to each others’ groups:

  • Amavis:

You will need to make Amavis and Postfix communicate.

In /etc/postfix/master.cf, below the line:

add:

to looks like that:

And at the end of the file add:

then in /etc/postfix/main.cf, add:

Now you need to configure Amavis directly. In /etc/amavis/conf.d/15-content_filter_mode, make sure the 2 variables

are uncommented. You’re now good to go to SpamAssassin

  • SpamAssassin:

I suggest to create a dedicated user to run spamassassin to better control the process and have dedicated logs.

In root (su) type:

Its configuration file is located in /etc/default/spamassassin. You will need to modify few things to enable SpamAssassin:

and change the following to 1

You will also need to modify the OPTION line to become:

and add a new line with:

Now you need to configure Postfix to use SpamAssassin

At the line:

add below (new line):

then at the end of the file, add:

Finally restart all the services you have touched to.

If any issue happen during the restart, it should tell you what to do. If no issue, you should now be protected from Spam and Viruses.

You can try if it works by sending a fake spam to your mail box. Simply send you an email with the content:

or try with a inoffensive virus from The European Expert Group For IT-Security.

  • Procmail:

You may want to make sure they are store in your Junk box to separate them from your regular inbox. Here is where Procmail enter. (Although Sieve in Dovecot could do the same)

First, you will need to tell postfix to use procmail.

add the following line:

then, we need to config the rules.

From the Dovecot wiki, it states that Procmail seems to have some intermittent delivery problems if you use the system-wide configuration with Maildir style mailboxes. (/etc/procmailrc) and thus should use $HOME/.procmailrc instead.

Hence, to avoid having to configure that at every new email/user we will use the skel system to ensure our .procmailrc is copied to every new user.

In root, create the /etc/skel/.procmailrc file

and copy this simple configuration:

This will route the SPAM in the .Junk folder. (You should be able to subscribe to this folder using your favourite email client like Thunderbird,…)

When you will create a new user, the user will have this .procmailrc in its home and should be able to have it email running directly.

As explained in the first part of this tutorial, to create a new user: (In root)

A long tutorial but you should now have access to a secure mail system.

A New CAPTCHA Approach

If you want to use Postscreen to have an additional layer of Spam protection, you can follow below tutorial:

  • Postscreen:

In your /etc/postfix/main.cf, add a section for Postscreen as following:

Few explanation:

greet_banner

When a client connect to Postscreen, it will start to communicate by sending a first banner “Please wait to be seated” and 6 seconds later, the remaining information on the SMTP identity. According to SMTP protocol, the client needs to wait to receive the entire banner. Spam bots will probably not wait (as they are configured to send as many mails as possible) and Postscreen will not accept its mail.

pipelining_enable

Initially, before the ESMTP (Extended SMTP), the protocol was half-duplex, mining the server and client needed to send 1 command at a time and wait for the answer of the other. Enabling this option will indicate to the client that he needs to send 1 command at the time as Postscreen “does not” support ESMTP. Here again, most probably Spam bots will not respect that and send the entire set of commands directly.

non_smtp_command_enable

This test is a simple filter that block the commands CONNECT, GET and POST, used by spam bots when they use proxies. This filter is actually already implemented in Postfix (Since version 2.2) but having at the upstream should help reduce the load on the smtp daemon.

bare_newline_enable

This test is still very simple but a lot of Spam bots don’t respect it….in the SMTP protocol implementation, each line should finish by <CR><LF> for “Carriage Return & Line Feed”. But a lot of zombies only use the <LF> at the end of their line.

Obviously many more options exists and you should read the official documentation to learn more.

Then you need to modify the /etc/postfix/master.cf to enable Postscreen and allow him to route the validated mails to smtpd.(In root)

and replace the line

by

and then restart postfix

However you will receive mails with a delay from few minutes (5mn from Hotmail and 20mn from Gmail based on my previous test) to few hours depending on the client side….that’s why I don’t use Postscreen in fact.

Category: POSTFIX | Los comentarios están deshabilitados en Reduce SPAM and improve security – Amavis + SpamAssassin + ClamAV + Procmail + PostScreen
Febrero 7

Postfix domain rewriting with canonical maps

 

In some cases you want to rewrite all email for a specific domain to another domains. For example all incoming email for example.org should be rewritten to example.com. Postfix uses canonical maps to rewrite domains or mail addresses. Insert the following line to the /etc/postfix/main.cf:

canonical_maps = hash:/etc/postfix/canonical

Create the file /etc/postfix/canonical and add the following line:

@example.org   @example.com

Create the hash map of the canonical file by:

$ postmap /etc/postfix/canonical

Reload Postfix to active the changes.

$ /etc/init.d/postfix reload

All emails send to milo@example.org will now be displayed as milo@example.com in the TO field of the mail client. It’s still necessary to have the address milo@example.com as a local or virtual alias. This is not necessary for the address milo@example.org. But the domain example.org should be listed in the mydestination or virtual_domain option, otherwise Postfix will block all incoming emails for this domain. | In some cases you want to rewrite all email for a specific domain to another domains. For example all incoming email for example.org should be rewritten to example.com. Postfix uses canonical maps to rewrite domains or mail addresses. Insert the following line to the /etc/postfix/main.cf:

canonical_maps = hash:/etc/postfix/canonical

Create the file /etc/postfix/canonical and add the following line:

@example.org   @example.com

Create the hash map of the canonical file by:

$ postmap /etc/postfix/canonical
Category: POSTFIX, TIPS AND TRICKS | Los comentarios están deshabilitados en Postfix domain rewriting with canonical maps