Hi!

I'm trying to get a "big picture" about how postfix works with
various SASL options.  It looks like there's a big overview
missing in the docs somehow.

We've basically two big kinds of SASL mechanisms: plaintext
(which are login and plain) and non-plaintest (everything else).
The "everything else" requires custom storage for secrets, be
it plaintext passwords storage or some mechanism-specific
format.

As far as I can see, Cyrus SASL can work with plaintext methods
using saslauthd (which has very simple username,password => ok|bad
protocol), and can use any mechanism when having accesses to
secrets storage directly from an application (postfix in our
case).

There's nothing in the docs saying if dovecot sasl can work with
non-plaintext mechanisms.  In almost all docs and examples I've
found, dovecot side of the config is configured with
"auth_mechanisms = plain login".  There are some vague references
to usage of other mechanisms, for example

 
https://serverfault.com/questions/713442/postfix-dovecot-with-mysql-backend-md5-hashed-passwords-and-cram-md5-auth

but these are rare, usually very old, and inconclusive.  So the
question is whenever non-plaintext mechanisms are actually
supported with dovecot sasl type.

And finally, some SASL mechanisms also provides encryption, like an
alternative to TLS. Am I right this is not implemented in Postfix?

This SASL thing turned out to be quite complex due to various
possibilities and restrictions (so much for "simple").


This was a big picture / overview part.  Now, there's another
aspect: accessing SASL data/sockets from Postfix.  And in this
context, there are really awful suggestions which are repeated
in multiple places, especially when postfix is configured to run
chrooted - like suggestions to move /etc/sasldb2 to /var/spool/postfix/
and made it rw to postfix:postfix - this feels insane.  Adding there
various libraries and config files for cyrus sasl plugins and other
"interesting" stuff..

It *feels* like postfix needs some separation of this sasl stuff into
its own process somehow, similar to how proxymap is done, so that
eg cyrus sasl code is not linked directly into smtp[d] with all its
large code.  If we don't use sasl-based session encryption, it should
be relatively easy.  This daemon can have its own privileges which
allows it to work with secrets database without granting access to
it to whole postfix.

Thanks,

/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to