Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
Richard A Nelson wrote:
On Mon, 29 Sep 2003, Jeff Wiegley wrote:
I'm very tired of struggling with sendmail to get it to support STARTTLS
and SMTPAUTH under debian.
More on this in a minute...
STARTTLS is a pretty easy single include line in the .mc files.
Yes, and more secure to boot - especially if you only allow plaintext
methods *after* STARTTLS negotiations
Yep, I definately like TLS. I'm migrating all my settings to it as
soon as I can figure out evolution and sendmail won't cooperate and
start a decent TLS connection.
I've figure out that you only need the two lines:
include(`/etc/mail/tls/starttls.m4')dnl
include(`/etc/mail/sasl/sasl.m4')dnl
in the .mc files on the latest debian to get both STARTLS and SMTP AUTH
going but two items remain:
1) Is there anything I have to configure or check to get the behavior
you described as "[only] allow plaintext methods *after* STARTTLS
negotiations"? Or is it this way by default?
2) Maybe there is a sort of dependency bug in the debian sendmail
package: When I installed sendmail it brought in libsasl but nothing
caused either sasl2-bin or libsasl2-modules to be installed.
It was stupid of me that I couldn't figure out why AUTH wasn't
being presented for the longest time but I finally figured out that
if you don't have any mechanisms available then AUTH is disabled.
It seems weird that sendmail really needs sasl and sasl really needs
some modules but these modules (and daemon) were not installed along
with my request for sendmail. Just a small item but maybe the
sendmail dependencies could include sasl2-bin and libsasl2-modules?
No big deal about this. It was just confusing.
but AUTH is a real pain.
Indeed :(
What is the easiest method (preferrably one that doesn't require sasl)
to get AUTH setup so that:
1) non-STARTTLS connections do NOT offer PLAIN or LOGIN, and
2) STARTTLS connections do honor PLAIN or LOGIN?
No dice, man... SMTP AUTH *is* based upon SASL v1 or v2... There is
a GNU TLS, and iirc, even a GNU SASL replacement - but dont expect
a quick change from upstream or me; I know I've not investigated it
at all, and I'd expect that upstream hasn't even heard of it - bigger
fish to fry ATM.
Thanks. I knew about SASL but I didn't realize that SMTP AUTH was
dependent on it. I thought SMTP AUTH was around before SASL and
therefore maybe there was some way to reconfigure it to not use
sasl.
[snipped the sasl dead horse content]
I'm sorry about that. I searched for relevant sendmail lists, or some
Debian WiKi type things and couldn't find anything very pertinent;
especially any focused on the debian sendmail package. I stumbled across
this list just an hour or so after mailing you. I thought it wouldn't
deal with sendmail; just about firewalls and IPsec, classic security
items. But, of course, I was wrong.
Here's a double sorry: Sorry, but you'll probably find a couple of
bugs entered about sendmail via the reportbug tool. I was having these
problems with a couple of clients and I was desperate for help.
I'm happy to help, but the other problem you mention is thusfar unique
to you, and I only follow these groups on an as time/sanity permits
basis and dislike having to tie notes from disjoint locations together
to get a cohesive picture of a problem... so pick a spot, any (singular)
spot and let me know where that is.
I choose the debian.security list. (Except for things that I find that
I really think are bugs; those I'll submit via reportbug.) For now
I'll try to do some investigation as to why my STARTTLS connections
are crashing due to that Decryption failure. But it seems to be an
issue between sendmail and evolution. Mozilla doesn't seem to
have a problem with outgoing STARTTLS connections. But evolution
sure does.
Maybe somebody else can help...
When evolution trys to connect to starttls I get the following in
/var/log/mail.log:
Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server, error: accept
failed=-1, SSL_error=1, timedout=0, errno=0
Sep 30 10:33:21 mail sm-mta[25586]: STARTTLS=server:
25586:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or
bad record mac:s3_pkt.c:424:
Mozilla doesn't cause this error. and no other evolution user seems to
be complaining about this. But I can duplicate the error on all the
Debian sid boxes I have by just upgrading and then removing and
reinstalling sendmail. I've submitted a bug report to Ximian. Can
anybody help me by informing me of some way that I can obtain more
information about that first mail.log line? Why would the accept fail?
How can I find out what SSL_error=1 means?
Thanks, (Especially to Richard for dealing with the multiple avenues)
- Jeff
Reply to: