Smtp Auth

Relying on your ISP to send ones mail is becoming increasingly problematic. A couple of weeks back one spammer started a spamhaus PBL shutdown of xnet`s entire dynamic IP range for 48 hours. A few weeks before that i was told to reboot my router to get another IP.

 

Anyway it was time to set up smtp on the vps. There are many guides to doing this but most are confusing and the whole topic is one not well understood. Take a look at your average email client config:

 

 

Ask any of your desktop support clients to go near this and their eyes glaze over. What do the various secure settings actually do? Cryptographers think this is bad UI, even the developers think this is bad UI.

 

Im no expert but i can tell you what these settings actually do.

Use name and password - this turns on stmp auth

Use secure auth - this uses a simpler encryption ( eg   CRAM MD5 or DIGEST) to send the login, and the login only, but only if the mail server supports it, which many dont, see below.

Connection security: this relates to encryption of the whole email exchange:

• none, mail sent in plain test, auth also in plain text unless `use secure auth`above used
• StartTLS, starts out talking to the mail server in plain text just enough to establish common protocols, then negotiates a move to tls for the full mail exchange, including the login, possibly on another port
• SSL/TLS, theres no plain text dialog at all, its encrypted from the get go. SSL and TLS are more or less the same, Transport Layer Security is just the new name/version for Secure Socket Lyer.

 

Now if you read the postfix manual page on TLS, the very first line disparages the idea of adding tls to postfix:

 

Also you must understand that the encryption only lasts as far as the first MTA, so no real end to end encryption is actually achieved.

 

All that just to encrypt a dozen characters! What is clear is that you must encrypt the login. If you send smtp passwords in the clear its only a matter of time before these are intercepted for the simple reason that in this life the scale of peoples determination is directly proportional to the size of the prize, in our case an open relay for spammers is the jackpot.

 

Note that if you are authing using the same user/password for pop as smtp, then you will clearly need to secure the pop login as well! Duh.You can do that by setting the line in dovecot that says disable_plaintext_auth = yes, and turn on TLS for pop in the client. Logical really.

 

But the question becomes can we avoid this whole TLS route and yet still encrypt the smtp auth login process, and avoid the certificate issues, the reasonably serious encryption overhead etc?

 

What follows is the TLS method on Debian Lenny, assuming you auth against system passwords, pam et al.   Later I will attempt to get the MD5-CRAM solution to work.

 

 

POSTFIX SMTP AUTH +TLS

 

I followed these guides:

• [http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL]
• [http://www.postfix.org/SASL_README.html]
• [http://workaround.org/ispmail/lenny/authenticated-smtp]
• [http://www.linuxmail.info/postfix-smtp-auth-dovecot-sasl/]

 

SASL

Its regrettable that sasl has so many s`s and l`s because it has nothing at all to do with encryption. Simple authentication, is what it is. If you arent running Dovecot then youll need to go the Cyrus route. What follows assumes dovecot, which by most accounts is simpler to use.

 

First alter /etc/dovecot/dovecot.conf to the effect of:

 

Then add to /etc/postfix/main.conf

 

Be sure to restart both services, this is overlooked in both the authoritative postfix and dovecot refs above.

 

Make sure /var/spool/postfix/private/auth is created and readable by postfix. The only other gotcha is to watch out for ISPs that block port 25 other than their own mail server. If thats the case you can work around that by adding a port redirect to your mail server`s firewall.

 

This will allow your clients to use port 2525 instead or as well.

 

Youll need to redo this at every boot by whatever means you start your firewall. Test it on your client pc, eg windows start, run, cmd, should yeild:

 

If you dont get the mail server banner first line, and it times out or disconnects, then you have a firewall/port issue. For all other issues check the mail log /var/log/mail. If youre good to go, read on.

 

TLS

That should give you a working smpt+auth but with with no security. To go ahead and add TLS:

 

What this does is allows us to use the STARTLS option in the client, so youll need to add the auth username, and set starttls on port 2525. The smtpd_tls_auth_only=yes directive enforces tls auth (for relaying not other MTAs trying to send your mailserver mail, remember smtpd_recipient_restrictions, that says that mail intended for us is exempt from smtp auth), so this protects both your users privacy, but more importantly your mailserver from becoming an open relay. The first time a client connects theyll get a certificate warning and theyll have to tell it that yes, its safe to use and store the self signed out of date certificate.   If you want to know more read the rather dense postfix page on tls.

 

MD5-CRAM

 

Like i said before it ought to be possible to encrypt only the logins, and send the email in plain text. These four links lead me to believe that its possible.

• [www.andybev.com/index.php/SMTP_authentication_and_Postfix]
• [http://isp-control.net/forum/thread-10682.html]
• [http://www.tummy.com/Products/vpostmaster/recipes/dovecotsasl.html]
• [http://forum.linode.com/viewtopic.php?t=3995]

 

The thing is that you cant auth against the system passwords, pam or ldap etc , because none of those systems have access to the plain text passwords, for security reasons, whereas CRAM needs the plain text to work with. If you are willing to store the smtp auth passwords in plain text (or a CRAM compatible encrypted format), then it should work. AFAIC having passwords stored sub optimally is a small price to pay for not transmitting them in plain text. After all the server is secure right? And passwords read rights are limited to the auth process only.

 

The only downside is that it might limit you in what email clients support CRAM, but AFAIK all the main clients do.

 

Ill let you know if it works.

www.webspaces.net.nz/page.php?view=smtp-auth 2012-05-06