Re: sendmail + sasl == Broken?
* Richard A Nelson (cowboy@debian.org) [030314 13:56]:
> On Fri, 14 Mar 2003, The Doctor What wrote:
>
> > When I upgraded sendmail due to security problems, the
> > sendmailconfig program asked me if I wanted to use PAM, it didn't
> > say what for. I stupidly said "yes".
>
> Eh? I beg to differ ... it's not the best, and I'll gladly take any
> improvements :)
> ----------------
> It is *strongly* recommended that you use PAM as the authentication
> method for sendmail via SASL. Doing so will allow *all* your shell
> users (those with an /etc/passwd entry) to automagically authenticate
> themselves when using a MUA with SASL support turned on.
> ----------------
I did not mean to disparage your text. My apologies.
What happened is that I didn't remember what SASL was. If it had
mentioned SMTP_AUTH, I would have realized what it was. Also, the
script makes no attempt to detect (if it is possible) if the admin
had already set something up.
Perhaps you could show all the non-commented lines from
/etc/mail/sasl/Sendmail.conf
> Make sure you're using the version currently in proposed-updates,
> it corrects LDAP problems that may also affect SASL.
I'll try that first....Nope, that didn't work.
> > Now, SMTP_AUTH no loger works from Evolution (every method says "bad
> > password"). I tried switching the /etc/mail/sasl/Sendmail.conf to
> > use sasldb again, but even that doesn't work.
>
> * Did you stop/restart sendmail after that?
Yes sir. After each change, I re-ran sendmailconfig.
> * What does /var/log/mail.log show for these attempts? and is there
> any message during startup about SASL problems?
The log says:
Mar 14 17:24:03 gerf sm-mta[15246]: STARTTLS=server, relay=rack.gnubian.org [209.61.188.219], version=TLSv1/SSLv3, verify=FAIL, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168
I can only assume that the verify FAIL means that I failed to log
in. I couldn't find a better reference for what these lines mean.
> * What is the output of:
> telnet <host> 25
> ehlo localhost
250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN
is there. This matches my sendmail.mc file:
###
### Trusted Authorization Mechanism
define(`confAUTH_OPTIONS', `A')dnl
TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
define(`confDEF_AUTH_INFO', `/etc/mail/default-auth-info')dnl
###
### Have Sendmail listen on port 465 as if it was SSL only
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')
DAEMON_OPTIONS(`Port=smtp, Name=SMTP')
> I'm specifically looking for the AUTH line (here's mine):
> 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
Yes. That seems right.
> * Does this help `chmod a+r /etc/mail/sasl/Sendmail.conf` ?
# ls -al Sendmail.conf
-rw-r--r-- 1 root smmsp 631 Mar 14 17:20 Sendmail.conf
> > I would really like to get this working again. Using PAM would be
> > really keen, but I'd be happy to go back to using the sasldb.
>
> PAM only works for PLAIN/LOGIN authentication, and should be used
> with auto_transition: true so that CRAM-MD5 passwords are built and
> stored in /etc/sasld for better security on later connections
Evolution will ask the remote system what methods it accepts, I have
been trying all of them, "password CRAM-MD5, DIGEST-MD5, and NT
Login" I assume these correspond to the AUTH methods from above.
> > Ideally, it would be set up so that:
> > * It would only accept SMTP_AUTH if had STARTTLS'ed already.
>
> Only ideal if for PLAIN/LOGIN where you need the extra security of
> not sending plain or weakly encrypted pwds...
>
> You can do this today - see /usr/share/doc/sendmail/doc/op.{txt,ps}.gz:
> AuthOptions :
> p don't permit mechanisms susceptible to simple
> passive attack (e.g., PLAIN, LOGIN), unless a
> security layer is active.
Thank you for pointing me to this reference. I was wondering what
the AuthOption options were. :-) I have changed the line I quoted
you above from 'A' to 'A,p,y'
> > * It would work with PAM, so that the login/passwds would match
> > imap/pop.
>
> Again, PAM only works for PLAIN/LOGIN - but the password is encrypted
> into CRAM-MD5 or whatever and stored in /etc/sasld IFF auto_transition
> is set
Alright! I have it working! Coolness. I cannot say for certain what
fixed it, but setting the AuthOptions to 'A,p,y' has helped tracking
the problem down, by causing Evolution (the only test client I have)
to give me a different error. It started complaining about the
method. This led me to track down that Evolution is storing the
method in the email itself. This meant that my changing the method
in the configuration settings had no effect. :-(
Anyway, I have it working with all four options, though I will turn
off DIGEST and CRAM, since I think using PLAIN or LOGIN via SSL is
much saner and managable.
I would like to thank you very much for helping me out. I think
what would help would be a client to test with (say a simple python
script or something) that would report everything that it can. If
it was included with a howto and a description on how to set up
super high logging (level 14), the combination would be powerful.
Having suggested it, I might try to write such a python script, if
modules exist for sending email. :-)
Thanks again.
Ciao!
--
This is the Steve Allen show. To those of you lunging for the channel
selector, 'Good Night!'
The Doctor What: Da Man http://docwhat.gerf.org/
docwhat@gerf.org KF6VNC
Reply to: