Issues with SSL/TLS and AUTH

Some people seem to have trouble understanding the various options involving SSL, TLS, and AUTH. In order to try and help, I have made a list of the settings you should use with my service-qmail-smtpd-run script in order to set things up the way you want them.

The cells with the green background are the "standard" settings that most people use on their mail servers. The cells with the red background are DANGEROUS because they allow your users to send their passwords across the network in clear text. Think very carefully before using one of these options.

In addition, the cells with red text should not be used for servers which are listed in the MX record for any domain, since outside servers may have legitimate mail for the domain but not have a valid userid and password to be able to use AUTH.

The idea here is that you should:

• be running qmail with my combined patch set, version 6c or later;

• download the service-qmail-smtpd-run script from my web site;

• plug the values listed above into your local copy of the script; and

• use the result as your /service/qmail-smtpd/run script.

Even if you're writing your own script, you should at least read through my script- the PORT and AUTH variables are used by my script and not by qmail-smtpd, and the SSL variable is used both my the script and by qmail-smtpd. You may need to adjust your own script to handle the functions of these variables within your own script.

Notes

Even though they are documented in the service-qmail-smtpd-run script itself, it may be helpful to explain each variable here.

PORT

This sets the TCP port number on which the service will listen. The "standard" values are 25, 465, and 587, but any valid port number can be used. However, keep in mind that if you are configuring a service for use by the outside world (to handle incoming mail for your own domain names, for example) that the incoming connections will arrive on port 25- so if the server is handling incoming mail from the world, you do want to make sure that you have a port 25 service running, even if it's not the only one.

SSL

Setting SSL=1 causes the script to use sslserver instead of tcpserver, which means that the incoming connections will be SSL-encrypted before any other programs (such as qmail-smtpd, rblsmtpd, greylisting, etc.) ever get a chance to run. The default is SSL=0, which results in a normal non-SSL service. Note that SSL and TLS are both methods of handling encryption, but they work differently.

FORCE_TLS

Setting FORCE_TLS=1 tells qmail-smtpd to not accept ANY incoming mail until a successful STARTTLS command has been processed and the connection is encrypted. The default is FORCE_TLS=0, which results in a server which does not require STARTTLS (unless the server also has REQUIRE_AUTH=1 and ALLOW_INSECURE_AUTH=0.) This setting is forced to 0 if you have SSL=1.

DENY_TLS

Setting DENY_TLS=1 will prevent the service from allowing the STARTTLS command. This option is there for people who have a servercert.pem file, but need an SMTP service which does not support the STARTTLS command for some reason.

AUTH

Setting AUTH=1 turns on support for the AUTH command, when the connection is encrypted (or when ALLOW_INSECURE_AUTH=1 is set) and a suitable method of handling the AUTH command is available. This might mean a checkpassword program (such as vpopmail's vchkpw) is specified on the qmail-smtpd command line, or it might mean an AUTH_CDB file. There are variables within the script to configure which AUTH method you wish to use, and how it should be configured.

This variable does not mean that AUTH should be required, only that it will be supported. If you have "AUTH=0", the AUTH command will not be advertised or supported.

REQUIRE_AUTH

Setting REQUIRE_AUTH=1 will make the service not accept ANY mail unless the client has sent a valid AUTH command. This also prevents incoming mail from being accepted for your own domains, so do not use this setting if the service is accepting "normal" mail from the outside world.

If this is enabled and your MUA (Mail User Agent, the "email program" on your workstation) does not send an AUTH command, you will see this error message:

503 AUTH first (#5.5.1)

ALLOW_INSECURE_AUTH

One of the ways that attackers find their way into your system is by using a "packet sniffer" to watch one of your users access their mailbox or an SMTP session which involves an AUTH command. I have added code to the combined patch which will prevent the AUTH command from being advertised (or from being processed if a client sends it anyway) if the connection is not encrypted. Setting ALLOW_INSECURE_AUTH=1 will bypass this check, and the AUTH command will be available (if it is otherwise available, of course.)

This option should only be used in situations where you know that the network path from the clients to the server will be otherwise secured, such as a VPN or a local connection where the traffic never leaves your network.

Copyright 1995-2024 John M. Simpson KG4ZOW (email) (PGP key)
Last updated 2008-08-08 03:43:25 +0000