Scrutinized

Test, Test, Test

Once you've configured your new mail server to the best of your knowledge, it's time for some testing. One tried and trusted method is manually tracing the SMTP dialogs. Simulating the delivery of email from external sources where TLS is required proves to be tricky – even authentication is not exactly trivial. The following line solves the encryption problem:

openssl s_client -starttls smtp -connect mail.example.org:587 -crlf

You now just need to base64-encode the password and username; the SMTP Auth command supports several variants for this, but passing in as a parameter is probably the easiest way. Base64 encoding is done like this:

perl -MMIME:Base64 -e 'print encode_base64("\000Username\000Password");'

After the obligatory ehlo , you now just need AUTH PLAIN <Output>, where <Output> is the result of Base64 encoding. It should then be possible to send email from an external source.

Protection Against Viruses

OpenSMTPD scans the incoming or outgoing email for viruses and for spam, if so desired (e.g., using AMaVis – A Mail Virus Scanner [4]). Although the server does not have an extra email filter interface, that is not a big drawback: AMaVis listens to the mail server on a non-privileged port, accepts the email to be tested, and sends it back to OpenSMTPD again on a different localhost port. OpenSMTPD accepts the mail, tags it, and puts it back into the normal delivery queue with just a slight delay.

This process works just as well with ClamAV and ClamSMTP [5], the SMTP proxy for clamd. Compared with AMaVis, Clam has the advantage of being much more compact and is thus a better match in terms of the OpenSMTPD philosophy. Because the configuration is ultimately the same for AMaVis and clamsmtpd from the perspective of MTA, I will be using the lean open source scanner as an example.

If you want to scan incoming and outgoing email, you can run two ClamSMTP scanners to distinguish between the two streams again later. Otherwise, you could be letting an open relay creep in through the back door. The OpenSMTPD configuration then looks just like Listing 5: Untagged mail ends up with the virus scanner. The scanner then sends it back again via ports 30025 and 40025, depending on whether the mail was incoming or outgoing. The messages are tagged internally here, which leads to a special delivery.

listen on all port 25
listen on 127.0.0.1 port 30025 tag scanned_out
listen on 127.0.0.1 port 40025 tag scanned_in
table aliases db:/etc/aliases.db
accept for local alias <aliases> deliver to mbox
accept tagged scanned_in for domain "example.com" virtual <users> deliver to mbox
accept tagged scanned_out for any relay
accept from any for domain "example.com" relay via smtp://127.0.0.1:10025
accept from source 10.0.0.0/24 for any relay via smtp://127.0.0.1:20025

Setting up ClamSMTPD

ClamSMTPD needs two configuration files to distinguish between incoming and outgoing email. The supplied configuration file in /etc/ is the Ubuntu sample configuration; all other ClamAV configuration files are in /etc/clamav. Anyone who has a problem with this can move clamsmtpd_out.conf and clamsmtpd_in.conf to the correct directory.

In contrast to some solutions [6], I prefer a Unix socket for local communication rather than a TCP port on localhost; Ubuntu sets this up inherently. The changes compared with the standard clamdsmtpd.conf are shown in Listings 6 and**7. The two commands

clamsmtpd -f /etc/clamav/clamsmtpd_in.conf
clamsmtpd -f /etc/clamav/clamsmtpd_out.conf

start the proxy. For testing, it is possible to send the EICAR test virus [7], which does no harm but must be detected.

OutAddress: 30025
Listen: 127.0.0.1:20025
PidFile: /var/run/clamsmtp/clamsmtpd_out.pid

OutAddress: 40025
Listen: 127.0.0.1:10025
PidFile: /var/run/clamsmtp/clamsmtpd_in.pid