Robert Krig:
> On Wednesday 11 January 2012 09:08:03 Wietse Venema wrote:
> > Fortunately, the Postfix SMTP server is a short-lived process that
> > runs for a few minutes at a time without ever changing the system
> > configuration. Every new Postfix SMTP server process is like a
> > new-born with a blank memory of its past.
> >
> > Therefore, if SASL logins fail, especially when they fail persistently,
> > then either the SASL client has changed, or the SASL server
> > infrastructure **outside POSTFIX** has changed.
>
> But thats just it, they don't fail persistently. I mean, it all works fine,
> until all of a sudden it doesn't anymore and only for these accounts. The
> other accounts continue to work fine.
Some accounts fail persistently, if I recall correctly.
This happens outside the non-persistent Postfix SMTP server, which
maintains no memory of what has happened previously. This part is
really simple.
Now, let's look where errors can persist:
> /usr/lib/sasl2/smtpd.conf
> pwcheck_method: saslauthd
The non-persistent Postfix SMTP server talks to the Cyrus SASL
library, which talks to the persistent saslauthd process.
> /etc/conf.d/saslauthd
> SASLAUTHD_OPTS="-m /var/run/saslauthd -r -a pam"
The persistent saslauthd process talks to the PAM subsystem.
> /etc/authlib/authdaemonrc
> authmodulelist="authmysql"
And PAM talks to the persistent MySQL server.
Somewhere in this chain, the information about some accounts gets
messed up, and the corruption is persistent.
I therefore suggest looking at any one of the PERSISTENT processes
in this chain, instead of the non-persistent processes from Postfix.
Wietse
