@mattr:

What I need is to make it possible to send email from outlook (just one pc for now) via postfix to the world, preferably with my ordinary unix account login/password. Oh, I'm on ubuntu 8.
(As I'm about to post this I'm realizing it grew rather large, so here goes…)

Since it's not absolutely clear, I'm assuming that your PC is back at home or work or something, and thus from your Linode's perspective is an "external" host that is trying to use it to send mail, correct?

First, I can sympathize with the complexity - jumping right into TLS (transport layer security) with its certificates, keys, and probably a bunch of new concepts has a rather steep learning curve. The good news is that your TLS knowledge will translate to many other applications beyond email.

While I haven't done authentication with Postfix before, I might in the future, so took a peek. I suspect your specific error is either related to the fact that Postfix run's chroot'd beneath /var/spool/postfix so some of the paths you are seeing actually have to be relative to that root, or that you haven't made postfix part of the sasl group to be permitted to connect to the saslauthd socket.

Taking one step back, it may help your mental picture to clearly separate TLS and SMTP SASL as two independent features. TLS can protect the raw network connection, including authentication of each party, but it applies to the raw network data. SASL is authentication at the application layer that the SMTP server uses to identify the user enqueuing a message, providing one or more ways to exchange the authentication information. That exchange can occur over a normal or TLS-protected connection.

The reason you often see them combined is that once you have a secure network connection, the application can be much less concerned with the security of data, such as passwords, that it sends across the link. So having the TLS session lets you use simpler application layer schemes (like SASL's PLAIN) without worry. But the two parts are still quite independent.

Further complicating the SASL side is that actual implementation of the SASL authentication methods can be internal to an application (such as Postfix) or provided by an external server (such as saslauthd), so there's yet another level of flexibility/complexity. saslauthd, in turn, supports various backends, such as its own local database file, or "pam" to tie into the standard Linux authentication. And of course, in your setup, you actually have two applications (Postfix and Dovecot) that are doing authentication independently, which may or may not share a mechanism.

Since it sounds like you've got TLS functioning (self-signed is fine as long as you have control over both server and clients, not to mention cheaper), I'll give a shot at the SASL side of things. Starting from a fresh Postfix setup on my Ubuntu 8.04 system, I was able to get SASL based authentication working with saslauthd (sans any TLS) by:

SASL: * Installing sasl2-bin (sudo apt-get install sasl2-bin)

• Editing /etc/default/saslauthd, to set START=yes, and change the OPTIONS line to use "/var/spool/postfix/var/run/saslauthd". It's important that this be beneath /var/spool/postfix since that's the only directory tree postfix can see while running as it chroot's there. By default the configuration is using "pam" authentication which will look up users on the local system.

• Start saslauthd (sudo /etc/init.d/saslauthd start)
  Postfix: * Create an smtpd.conf file in /etc/postfix/sasl with the contents: pwcheck_method: saslauthd mech_list: login plain The final line restricts what authentication methods are announced by Postfix to the connecting client. saslauthd only supports plain text password methods, but by default the sasl support built into Postfix will announce all possible schemes. If you leave that line out and a client tries (as it should) to use a more secure scheme such as CRAM-MD5 or DIGEST-MD5, then Postfix will internally try to access a sasldb file in it's local "etc" without using saslauthd.

• Edit /etc/postfix/master.cf to uncomment the submission line and some of its options so that it looked like:

  submission inet n       -       -       -       -       smtpd
  #  -o smtpd_tls_security_level=encrypt
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  #  -o milter_macro_daemon_name=ORIGINATING
  

  Note that this requires authentication, but not tls_security. You'll likely want the tls flag enabled in production. It's also listening on the submission port (587) rather than 25 in case clients are prevented from directly contacting port 25, as many home users are. But you could certainly use the same options on the smtp entry (port 25) or any other custom port if you wanted. I'm not using any milters so the final option isn't that important for me, but if you wanted filters that could work based on the client connecting, that's useful. And of course, there's a bunch of sasl and tls related settings that you can investigate later to fine tune the behavior for authenticated connections.

• Add postfix to the sasl group, so it can connect to the daemon (sudo adduser postfix sasl)

• Restart postfix (sudo postfix reload)
  At that point, Postfix was listening on port 587 with authentication, which I could test from a home PC as (** are commands I sent):

** > telnet xxx 587
   Trying xxxx
   Connected to xxxxxx.
   Escape character is '^]'.
   220 xxxxxxxxxxx ESMTP Postfix (Ubuntu)
** EHLO yyyyyyy
   250-xxxxxxxxxx
   250-PIPELINING
   250-SIZE 10240000
   250-VRFY
   250-ETRN
   250-STARTTLS
   250-AUTH PLAIN LOGIN
   250-ENHANCEDSTATUSCODES
   250-8BITMIME
   250 DSN
** AUTH PLAIN
   334 
** zzzzzzzzzzzzzzzzzzzzzzzzzzz==
   235 2.7.0 Authentication successful

In particular, note the "250-AUTH" initial response. Per PLAIN authentication my submission was a base-64 encoding of a utf-8 encoding of username+nul+username+nul+password (the first username is who I want to act as, the second is the authentication user).

Since we've restricted ourselves to plain text authentication methods, this is not a configuration you'd want to use without TLS like I am here. However, if TLS is an issue (either unnecessary complexity, or a problem for some of your clients), you could decide to switch to a better authentication scheme and remove TLS. One downside to this is that you won't be able to authenticate against the local system accounts, but will have to use a separate SASL database. If you're likely to have clients that wouldn't otherwise need a full account on the system, this may actually be neater, as you don't need wasted system accounts just for SASL authentication. It can also do away with the need to run a separate saslauthd daemon.

For example, if you completely remove any /etc/postfix/sasl/smtpd.conf file, then by default Postfix will internally use its SASL libraries to authentication. Postfix on my Ubuntu system is built against both Cyrus and Dovecot libraries (you can check with "postconf -a"). The default is Cyrus (smtpdsasltype setting), but if you are maintaining a Dovecot authentication database, you could opt to use that instead.

But for Cyrus, it will look for an /etc/sasldb file. Since Postfix is chroot'd, this file is actually /var/spool/postfix/etc/sasldb. By default, you also need to make sure that the domain you use for accounts in this file matches your fully qualified hostname in Postfix (which can be queried with "postconf -h myhostname"). Although you'll no longer run the saslauthd daemon, you'll still want the sasl2-bin package to have the tools to manage the password file.

To set this up, given the result of the above configuration, I: * Removed the /etc/postfix/sasl/smtpd.conf file

• Created a sasl password database file to authenticate against, such as:````

  saslpasswd2 -f /var/spool/postfix/etc/sasldb -u postconf -h myhostname -c db3l
  (enter password)
  (repeat for any other users)
  ````

• Make sure the file is readable by postfix. I chose to do that by putting it in the postfix group (chgrp postfix sasldb2) rather than making it world readable. You could also change its ownership but then "postfix check" gives a warning. Note that you may have a real /etc/sasldb around that "postfix check" may warn if it's different than the version in /var/spool/postfix. I just removed the /etc version since nothing else was going to be using it.

• Add "noplaintext" to the default smtpdsaslsecurity_options value of "noanonymous", either via main.cf or an option on your submission line in master.cf. This is a simple way to eliminate the risky (over a non-TLS session) authentication choices .

• Reload postfix (sudo postfix reload)
  Then you'll have a server on 587 that only supports non-cleartext authentication methods:

> telnet xxxxx 587
Trying xxxxx...
Connected to xxxxx.
Escape character is '^]'.
220 xxxxxx ESMTP Postfix (Ubuntu)
EHLO yyyyyyy
250-xxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

and authenticates directly against the users in your sasldb database which can be maintained independently of the rest of the system.

Of course, there are more permutations on all of this, but hopefully the above will give you a starting point from which you can explore the various options.

– David

PS: Just for the record, if you just want to solve your single PC problem for testing independent of all the TLS/SASL stuff, you can add the address of your PC to the mynetworks parameter in /etc/postfix/main.cf (as a x.y.z.w/32 host address) to permit the relaying temporarily. Just remember to keep it up to date if you have a dynamic address that changes.

Dear David,

Thank you so much! That is a fabulous explanation!!!!!

I can now send email from Outlook on my work PC via postfix to the world. But, I'm not sure it is actually encrypting the traffic.

NOTE! After doing this writeup I SOLVED it.

I was able to see that TLS is being started by adding this to main.cf:

smtpdtlsloglevel = 2

Which in the mail.info log shows:

setting up TLS connection from MYIP

Anonymous TLS connection established from MYIP: TLSv1 with cipher RC4-MD5 (128/128 bits)

xxxxxxxx: client=MYIP, saslmethod=LOGIN, saslusername=mattr

So I think it is solved. But I leave my post here for anyone who has this problem in the future.

I will briefly say what I did to make it work and what is different from how you posted.

After reading your post, I did:

• changed method from shadow to pam (For now I am using pam, not a separate sasldb, for authentication.)

• in /etc/postfix/sasl/smtpd.conf, changed saslauthd_path from /var/run/saslauthd/mux to /var/spool/postfix/var/run/saslauthd/mux

• added postfix user to group sasl

• It still didn't work, meaning that Oulook prompted for login and password which were always refused. I was getting:

warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory

–> THEN, when I commented out the saslauthd_path line in smtpd.conf, SASL suddenly started working! I'm no longer prompted for login/password.

It stopped working when I uncommented this:(which you recommended).

-o smtpdclientrestrictions=permitsaslauthenticated,reject

So commented it back in and it works. Maybe it is conflicting with something?

FWIW I found on the net a way to find out where saslauthd is:

netstat -peln | grep saslauthd

netstat -peln | grep saslauthd

unix 2 [ ACC ] STREAM LISTENING 5800975 11353/saslauthd /var/spool/postfix/var/run/saslauthd/mux

unix 2 [ ACC ] STREAM LISTENING 5713075 26139/saslauthd /var/run/saslauthd/mux

unix 2 [ ACC ] STREAM LISTENING 5803536 11992/saslauthd /var/spool/postfix/var/run/saslauthd/mux

Don't ask me why the second line is there. That /var/run/saslauthd folder doesn't exist anymore. Must be an old thread..

OK. Now, the question is, SASL works but is TLS really encrypting the traffic when I send my login to postfix? The AUTH LOGIN method is a plain text format I understand. In the mail.info log, the POP3 connections via dovecot say TLS started but the SMTP connections do not say that.

Quick background: I didn't really understand the way to use dovecot in postfix, which might have been faster. My postfix has both dovecot and cyrus support and I'm using cyrus. So my (maybe confused) understanding is that the postfix TLS setup is a totally separate one from the one being used by dovecot, instead of somehow hooking into dovecot's TLS.

FWIW there is some info related to this at:

http://ubuntuforums.org/archive/index.php/t-346366.html

and some nice material from Hardening Linux by James Turnbull - has a section on hardening email and postfix page 373

and SMTP AUTH page 383 which is at:

http://books.google.com/

In the mail log, I get saslmethod=LOGIN, saslusername=xxxxx

In Outlook account settings > Advanced, I have the "This server requires an encrypted connection (SSL)" checkboxes checked for both Incoming server (POP3) and Outgoing server (SMTP)

I'm on ports 995 (POP3) and 25 (SMTP). So it ought to be encrypted.. but this is windows again.

I tried to check TLS is running two ways, openssl and swaks.

openssl s_client -connect host:port -starttls smtp

this showed the certificate ca was not sent maybe a problem.

(see log below, which says "No client certificate CA names sent" but does not fail so maybe that's not a problem?

swaks -s MYDOMAIN.net -tls -a -au MYLOGIN -ap MYPASSWD –protocol ESMTPSA

(ESMTPSA means smtp +tls +authentication)

It says TLS started w/ cipher DHE-RSA-AES256-SHA then AUTH LOGIN and Authentication successful, so I think TLS worked maybe.

But then why doesn't it say tls used in the postfix mail.info log?

(see swaks log below)

I am using a self-signed cert by the way, which I made like so:

mkdir /etc/postfix/sasl

cd /etc/postfix/sasl

openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650

I am using this same /etc/postfix/sasl/smtpd.pem for cert. (See at bottom, my main.cf.)

I leave you with this output from the openssl test, I'd appreciate it if you could tell me 1) is TLS working now, 2) must I add some kind of CA certificate.

Thanks a million!

Sincerely,

Matt

****Below are the openssl and swaks logs.

OpenSSL test:****

$ openssl s_client -starttls smtp -connect localhost:25

CONNECTED(00000003)

depth=0 /C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxxx

verify error:num=18:self signed certificate

verify return:1

depth=0 /C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxxx

verify return:1

–-

Certificate chain

0 s:/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx

i:/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx

---

Server certificate

-----BEGIN CERTIFICATE-----

snip

-----END CERTIFICATE-----

subject=/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx

issuer=/C=JP/ST=Tokyo/L=Tokyo/O=Internet Widgits Pty Ltd/CN=xxxxxxxxxxxxxxx

---

No client certificate CA names sent

---

SSL handshake has read 1715 bytes and written 351 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA

Session-ID: xxxxx

Session-ID-ctx:

Master-Key: xxxxx

Key-Arg : None

Start Time: 1245066243

Timeout : 300 (sec)

Verify return code: 18 (self signed certificate)

---

250 DSN

(and here I can type into the ongoing telnet session)

SWAKS log:

$ swaks -s xxxxxxxx.net -tls -a -au USERNAME -ap PASSWORD –protocol ESMTPSA

To: xxxxxxxxxxxx@gmail.com

=== Trying MYDOMAIN.net:25…

=== Connected to MYDOMAIN.net.

<- 220 MYDOMAIN.net ESMTP Postfix (Ubuntu)

-> EHLO localhost

<- 250-MYDOMAIN.net

<- 250-PIPELINING

<- 250-SIZE 10240000

<- 250-VRFY

<- 250-ETRN

<- 250-STARTTLS

<- 250-AUTH PLAIN LOGIN

<- 250-AUTH=PLAIN LOGIN

<- 250-ENHANCEDSTATUSCODES

<- 250-8BITMIME

<- 250 DSN

-> STARTTLS

<- 220 2.0.0 Ready to start TLS

=== TLS started w/ cipher DHE-RSA-AES256-SHA

~> EHLO localhost

<~ 250-MYDOMAIN.net

<~ 250-PIPELINING

<~ 250-SIZE 10240000

<~ 250-VRFY

<~ 250-ETRN

<~ 250-AUTH PLAIN LOGIN

<~ 250-AUTH=PLAIN LOGIN

<~ 250-ENHANCEDSTATUSCODES

<~ 250-8BITMIME

<~ 250 DSN

~> AUTH LOGIN

<~ 334 VXNlcm5hbWU6

~> bWF0dHI=

<~ 334 UGFzc3dvcmQ6

~> Z3lvemE5OQ==

<~ 235 2.7.0 Authentication successful

~> MAIL FROM: <~ 250 2.1.0 Ok

~> RCPT TO:<xxxxxxxxxxxxxxxx@gmail.com>

<~ 250 2.1.5 Ok

~> DATA

<~ 354 End data with . ~> Date: Mon, 15 Jun 2009 20:56:34 +0900

~> To: xxxxxxxxxxxx@gmail.com

~> From: mattr@localhost

~> Subject: test Mon, 15 Jun 2009 20:56:34 +0900

~> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks

~>

~> This is a test mailing

~>

~> .

<~ 250 2.0.0 Ok: queued as 3D7F78DDA

~> QUIT

<~ 221 2.0.0 Bye

=== Connection closed with remote host.

main.cf:

See /usr/share/postfix/main.cf.dist for a commented, more complete version

Debian specific: Specifying a file name will cause the first

line of that file to be used as the name. The Debian default

is /etc/mailname.

myorigin = /etc/mailname

smtpdbanner = $myhostname ESMTP $mailname (Ubuntu)

biff = no

appending .domain is the MUA's job.

appenddotmydomain = no

Uncomment the next line to generate "delayed mail" warnings

delaywarningtime = 4h

readme_directory = /usr/share/doc/postfix

TLS parameters

smtpdtlssessioncachedatabase = btree:${datadirectory}/smtpdscache

smtptlssessioncachedatabase = btree:${datadirectory}/smtpscache

See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for

information on enabling SSL in the smtp client.

alias_maps = hash:/etc/aliases

alias_database = hash:/etc/aliases

myorigin = telebody.net

mydestination = MYDOMAIN.net, localhost, ANOTHERDOMAIN.com, ANDANOTHER.com, mail.MYDOMAIN.net

mailboxsizelimit = 0

recipient_delimiter = +

smtpdrecipientrestrictions = permitmynetworks permitinetinterfaces permitsaslauthenticated rejectunauth_destination

Added by Matt 2009-0310

headerchecks = regexp:/etc/postfix/headerchecks

html_directory = /usr/share/doc/postfix/html

smtpdsaslauth_enable = yes

smtpddelayreject = no

smtpdusetls = yes

smtpdtlscert_file = /etc/postfix/sasl/smtpd.pem

smtpdtlskey_file = /etc/postfix/sasl/smtpd.pem

brokensaslauth_clients = yes

smtpdsenderrestrictions = permitmynetworks permitsasl_authenticated

smtpdtlsCAfile = /etc/postfix/sasl/smtpd.pem

smtpsaslsecurity_options = noanonymous

smtpsaslpasswordmaps = hash:/etc/postfix/saslpasswd

smtpsasltype = cyrus

relayhost = $mydomain

relayhost =

smtpdsaslpath = smtpd

@mattr:

So I think it is solved. But I leave my post here for anyone who has this problem in the future.
Glad to hear that you're up and running. Perhaps I can shed a little light on some of the questions you encountered along the way.

> After reading your post, I did:

(…)

• in /etc/postfix/sasl/smtpd.conf, changed saslauthd_path from /var/run/saslauthd/mux to /var/spool/postfix/var/run/saslauthd/mux

(…)
That setting, as you found out, is superfluous, since Postfix's default will work fine as long as you set the OPTIONS field in /etc/default/saslauthd appropriately as in my first post.

Remember that Postfix runs chroot'd in /var/spool/postfix. So when you included the setting, any value you put there is relative to that root. If you were going to include the setting, the right value would have been "/var/run/saslauthd/mux".

> It stopped working when I uncommented this:(which you recommended).

-o smtpdclientrestrictions=permitsaslauthenticated,reject

So commented it back in and it works. Maybe it is conflicting with something?
I'm not entirely sure if you are saying it works with or without that setting. Normally you comment something "out" not "in" - are you saying it fails with this line or without it?

If it only works without this line, that does seem strange, since your sender restrictions in main.cf only let mail be relayed with SASL authentication, so if that's working it would imply your client is authenticating properly, which in turn ought to satisfy these restrictions as well. So I can't say for sure why having the setting enabled causes a failure. Unless the failures were when you were also making other changes, so perhaps you'd be able to turn this back on in your final configuration.

Not having this setting does mean that you are permitting unauthenticated client connections, which may or may not be what you desire. They won't be able to relay messages but they could generate mail destined for local users, for example.

If instead you're saying that it works when you leave that line uncommented, but fails otherwise, at least on my setup, it seems to work either way. It's possible that other changes you made resulted in other restrictions if you leave it off. I don't see anything obvious in the main.cf you posted, but given that you most likely want this setting anyway (to reject unauthenticated requests), not sure it's that critical. You could try checking with "postconf | grep restrictions" when you didn't have the option enabled in master.cf to see if anything jumps out at you.

> # netstat -peln | grep saslauthd

unix 2 [ ACC ] STREAM LISTENING 5800975 11353/saslauthd /var/spool/postfix/var/run/saslauthd/mux

unix 2 [ ACC ] STREAM LISTENING 5713075 26139/saslauthd /var/run/saslauthd/mux

unix 2 [ ACC ] STREAM LISTENING 5803536 11992/saslauthd /var/spool/postfix/var/run/saslauthd/mux

Don't ask me why the second line is there. That /var/run/saslauthd folder doesn't exist anymore. Must be an old thread..
It looks like you have older copies of saslauthd still running. The number in front of the name (e.g., 11992 in "11992/saslauthd") is the process ID, so you might check those out. I don't know if saslauthd forks while running, so whether or not the two processes with the right path are correct.

I do know that on my system, after restarting saslauthd, and even during my tests when running, I never have more than one process ID shown. It's pid will be stored in in the saslauthd.pid file in its directory (/var/spool/postfix/var/run/saslauthd in your case).

I'd probably suggest either a clean reboot (if it's a test system), or kill off all the saslauthd processes you can find and then restart it cleanly.

> OK. Now, the question is, SASL works but is TLS really encrypting the traffic when I send my login to postfix? The AUTH LOGIN method is a plain text format I understand. In the mail.info log, the POP3 connections via dovecot say TLS started but the SMTP connections do not say that.
Your final update indicated that you were able to increase the logging to identify a TLS connection, so I'll skip that. Note that if you have the smtpdtlssecurity_encrypt option enabled in master.conf (my example left it commented out), then you are telling Postfix to require (as opposed to just offering) TLS on connections.

For example, if I change my master.cf from my last post to include that setting, my master.cf entry becomes:

submission inet n       -       -       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

And a test session to my server looks like:

> telnet xxxxx 587
Trying xxxxx...
Connected to xxxxx.
Escape character is '^]'.
220 xxxxxxxxxxxxxxx ESMTP Postfix (Ubuntu)
EHLO yyyyyy
250-xxxxxxxxxxxxxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <someuser@somehost>530 5.7.0 Must issue a STARTTLS command first
AUTH PLAIN
530 5.7.0 Must issue a STARTTLS command first</someuser@somehost>

Nothing works without STARTTLS first (which will then negotiate keys and encrypt the session). So with this configuration, the submission port (587) is guaranteed to use encryption, or in your case the default port 25. When locking things down, don't forget to ensure that you don't have Postfix accepting connections on other ports with weaker configurations.

You may also note that no authentication mechanisms are shown pre-TLS. What actually happens is that an SMTP client issues the STARTTLS command and then restarts a session with a new ELHO command, at which point the available authentication options are displayed, e.g.:

> openssl s_client -connect xxxxx:587 -starttls smtp
(...)
250-xxxxxxxxxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
EHLO yyyy
250-xxxxxxxxxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

> Quick background: I didn't really understand the way to use dovecot in postfix, which might have been faster. My postfix has both dovecot and cyrus support and I'm using cyrus. So my (maybe confused) understanding is that the postfix TLS setup is a totally separate one from the one being used by dovecot, instead of somehow hooking into dovecot's TLS.

Nope, you're basically correct in terms of the configurations being distinct.

TLS is security over individual connections, which each application will implement over its own connections. As such, there's really no concept of "hooking into dovecot's TLS", at least with respect to each connection. What you can do is share some of the data necessary to implement TLS. Each TLS connection is going to require certificates and keys (with each application having its own way of configuring references to those items). You can maintain those centrally for example, and could choose to use the same server certificate/key for both applications.

TLS is independent of the dovecot and cyrus SASL mechanisms built into Postfix. Those deal with SASL authentication using two different libraries (and thus underlying databases), but are independent from TLS. As mentioned in my last post, the SASL authentication can occur with or without TLS - if TLS is present the SASL authentication just occurs over the secured channel. The cyrus mode lets Postfix directly access sasldb files (without needing saslauthd) for example, but Postfix still has all of its own smtpdtls* settings for controlling how TLS is negotiated, whether or not SASL authentication is going to be used.

> I tried to check TLS is running two ways, openssl and swaks
These are great ways to test that your server supports TLS, but I agree that they won't necessarily indicate that some other client (like Outlook) is also using TLS, since enabling that is a client choice on a per-connection basis. In other words, your openssl test connection might work fine, but if you also permit unencrypted sessions, a client may just choose not to enable TLS. Having it required in your configuration covers that, as does some increased logging as you later determined.

> openssl s_client -connect host:port -starttls smtp

this showed the certificate ca was not sent maybe a problem.

(see log below, which says "No client certificate CA names sent" but does not fail so maybe that's not a problem?

No, that shouldn't be a problem. The message is referring to "certificate CA names" and not certificates themselves.

TLS supports certificate exchanges in both directions, in which case both server and client can be authenticated. The setup you're using only has a certificate transmitted to the client. The openssl message means that your server hasn't also sent a request to the client (openssl in this case) for it to provide its own certificate.

Client authentication can further strengthen the security of a connection, but it requires that you generate certificates for clients and that they install them in whatever application they will be using. It's not that commonly used, particularly with public servers, and the client application has to support sending its own certificates.

> I am using a self-signed cert by the way, which I made like so:

mkdir /etc/postfix/sasl

cd /etc/postfix/sasl

openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650

I am using this same /etc/postfix/sasl/smtpd.pem for cert. (See at bottom, my main.cf.)

I leave you with this output from the openssl test, I'd appreciate it if you could tell me 1) is TLS working now, 2) must I add some kind of CA certificate.

1) Yes and 2) no, but you can if you want. (My guess is for your purposes, no, unless for example you'll also be offering a secure web site or other services).

The two major goals of TLS are authentication and privacy (encryption). A certificate is designed to provide authentication, as well as a starting point for negotiating the encryption key for the session. A public key within every certificate is paired with a private key (which is never released).

Using a self-signed certificate essentially bypasses authentication (your Outlook client trusts that your server is who it says it is, but has no basis for that trust, so will work when connecting to any old server), but still retains encryption. Your setup really only needs the privacy of TLS since it's the SASL authentication that controls use of the service.

A step up would be for you to create a CA certificate (essentially the same process but marking the certificate as a CA). Then, you can create other certificates and "sign" them with your CA certificate. You use the other certificates for servers like Postfix, and have your clients install your CA certificate in their applications so they can verify your server certificates.

A further step would be to use a commercial CA (Verisign, Entrust, etc…) or public CA (such as CACert) to sign a certificate for you. You then depend on your client already having the outside CA certificate installed for verification. This is how most web site certificates work.

But since you are authenticating the SMTP (or IMAP) transactions at the application level, there's not much benefit to adding complexity at the TLS level just to get further authentication.

In a lighter (maybe too silly) vein, think of it this way. Let's say we have two people, Charles (your client) and Sam (your server, with its self-signed certificate). They've never met. Sam is going to the post office and is willing to drop off additional letters for anyone who asks nicely. Charles has a letter he wants dropped off, knows how to ask nicely, and is expecting to use Sam.

Your current scenario of a self-signed certificate is like Charles approaching Sam, who says that yes, he's Sam. Charles takes his word for it, whispers his request nicely in Sam's ear, at which point Sam accepts the letter. Charles only has Sam's own word that he is in fact Sam, but Sam knows for sure that Charles asked nicely. Nobody else heard what Charles whispered.

In the next level up, let's start over but say that someone (Matt, your self-signed CA certificate) has been introduced to Charles and Sam separately. Now Charles approaches Sam, who says that yes, he's Sam. Instead of trusting him, Charles turns to Matt and asks if he's telling the truth. Matt has previously met Sam, so he confirms Sam's story, and since Charles has met Matt, he trusts him and thus trusts Sam. So he again whispers a nice request and gives Sam his mail.

The next level works very similarly, but this time, Charles has known someone else (Valerie, the Verisign CA) since high school. Sam has recently taken Valerie out for an expensive dinner, so she knows him as well. Now, when Charles approaches Sam, he can ask Valerie to vouch for Sam before handing over his letter.

In each of these cases, Sam could also have asked Charles who he was (the client certificates I mentioned earlier) which in turn could have all of the same variations for how Sam could trust Charles' answer.

In all cases, what Charles was whispering in Sam's ear was private, which includes, in your case, the users and passwords being used to authenticate with Postfix/Dovecot.

The important aspect of the latter two cases is that the client has independent information (the CA certificate) obtained before it ever tried to connect to the server, and which it can use to verify what your server is saying. The difference between creating your own CA versus using a commercial or public certificate is largely one of how the client received the original CA certificate and how much he trusts who he received it from. The big commercial CA certificates come pre-installed in browsers, for example, which is important for public web sites from a usability perspective.

In an enterprise or other closed environment, on the other hand, an internal CA can be used (and internally distributed to all clients along with client certificates) which can then fully authenticate both servers and clients. Browsers, for example, all support installing additional CA certificates as well as client certificates that can be used when authenticating an intranet for example. Another example would be how OpenVPN secures its links.

But unless your mail clients are going to reject a connection to a site using a self-signed certificate (unlikely), going the CA route will probably just add complexity without much benefit.

-- David