Re: sendmail/SMTP-AUTH/PAM Solution!!!

From: Jeff Wiegley, PhD (
Date: 07/23/03

  • Next message: Anthony Rowe: "Re: Replying by email to the newsfeed"
    To: Todd Pytel <>
    Date: 23 Jul 2003 10:07:41 -0700


        I hope you don't mind but I'm copying your last message
    sent to me to the users lists because it did result in a
    solution. and its so simple that I want a permanent record
    of it in a searchable location.

    As anybody reading this will be able to see Todd did an
    excellent job figuring out the idiosynchracies of the
    interactions of sasl and sendmail, especially the changes
    that were made to the syntax and semantics of the
    Sendmail.conf.2 file.

    I need sendmail to do two things:

    1) I need it to provide TLS support. In the sid version of
       debian you will need packages: sendmail, libgnutls7,
       libssl0.9.7 and probably openssl.

       sendmailconfig will detect that you have SSL/TLS
       capabilities but will warn you that you need to add
       the line:
       to the end of /etc/mail/ and /etc/mail/

       just adding that line will get sendmail to support SSL/TLS
       connections (STARTTLS will now be advertised in response to

    2) I needed SMTP-AUTH working. I run smaller sites and want
       authentication to be done against the /etc/passwd and
       /etc/shadow information (or PAM.) I don't want to maintain
       and synchronize multiple credential databases.

       sendmail supposedly can use a variety of authentication
       methods but the only one that I finally understand a
       bit about and got working was saslauth. so you'll need
       sasl2-bin, libsasl2-modules.

       Now the tricky part. sasl will provide you with
       /etc/mail/sasl/Sendmail.conf.2 BUT IT IS CONFIGURED
       WRONG!! sendmail or saslauthd from SASL version 2
       will not understand the sasl_pwcheck_method lines.

       you will need to change it to simply passwd_check.

       here's what I have in my /etc/mail/sasl/Sendmail.conf.2:
            pwcheck_method: saslauthd
       yep just that one line.

       now configure saslauthd by editing /etc/default/saslauthd
       and change START to yes and you can leave the MECHANISM as

       run sendmailconfig again. You can just say "y" to the
       three questions about reusing your current .mc files and
       restarting sendmail; it will preserve the changes you

       that will have restarted sendmail. now just
       /etc/init.d/saslauthd restart to get the saslauthd restarted
       and all should work nicely.

    By doing this you will get SMTP-AUTH working with PAM.

    Oh here's a good one for you... Why I **REALLY** don't
    want to use the sasl2 database... umm /etc/sasldb2
    stores passwords IN CLEARTEXT!!! so if somebody hacks
    the box they instantly know all my passwords. This is
    just stupid.
    A quote from the sasl docs:

       "For simplicity sake, the Cyrus SASL library stores
        plaintext passwords only in the /etc/sasldb2

    Umm. What bright idiot though that the best route to
    implement something secure was the "simple" way??
    At least with plain/login I can keep shadow secret's
    hashed and I can accept only pops and imaps to prevent
    passwords from being communicated in plaintext.

    Thanks for your help!!

    - Jeff

    On Tue, 2003-07-22 at 00:30, Todd Pytel wrote:
    > Hi Jeff,
    > Got the basics working. There are basically two general problems
    > here, elaborated on below...
    > 1) SASL is non-intuitive.
    > 2) Debian's Sendmail.conf.2 is dated.
    > The (very) long versions...
    > 1) SASL is non-intuitive.
    > What you're trying to do (auth against /etc/shadow) seems simple, unless
    > you think about it. Think about a regular console login. You enter your
    > username, get a password prompt, and enter your password. But before
    > that password is checked, it's hashed (MD5, DES, etc.) - otherwise you'd
    > be comparing passwords to plain text files, which is obviously a bad
    > idea. OK, now think about SMTP-AUTH again. Ideally, you don't want to
    > send a password in clear text. You could send a hash, but how do you
    > know which one to use? Linux boxes mostly use MD5, old *nix boxes use
    > DES, OpenBSD uses Blowfish. There have to be standard hashes defined,
    > so the SASL standard defines them - CRAM-MD5 and DIGEST-MD5 (also
    > Kerberos stuff and others, but those get more complicated). Great, so
    > your mail client will send an MD5 hash. Could you auth that hash
    > against /etc/shadow? Yeah, probably. But SASL doesn't - for good
    > reasons. First off, many systems don't use MD5 hashes, and the point of
    > a hash is that it's "one-way" - you can't get the original password out
    > of the hash (without a lot of work) to convert back to the system's
    > native format. Second, in the big picture, MD5 is not really that common
    > - enterprises use other systems (like Kerberos) that are faster and more
    > centralized. Third, creating a SASL mechanism to auth an MD5 against
    > shadow would be terribly platform-dependent, given variations in file
    > formats and system calls. Finally, large organizations (the ones most
    > likely to use SASL) generally want to get users out of the system
    > password files unless absolutely necessary. Not everyone needs a real
    > UID, a shell, or the ability to own files and parent processes.
    > Virtualize the users and let the apps sort it out as necessary. All in
    > all, sending a hash against shadow doesn't make nearly as much sense as
    > it would immediately appear. So SASL prefers using either a) standard
    > and scalable mechanisms like Kerberos or SQL, or b) it's own fast and
    > standardized sasldb built off the MD5 standard. (Sidebar: SASLv2 no
    > longer hashes passwords in sasldb. Though it uses a hash for the
    > communication, it stores the un-hashed password. Why? Don't know, but
    > this leads to yet more confusion in understanding old docs.)
    > That's the hardest part - understanding *why* SASL works as it does.
    > >From there on, it makes (mostly) more sense.
    > So what's a guy to do when he wants to auth against shadow? Well, while
    > SASL prefers (a) and (b) mentioned just above, it provides a
    > fallback for situations that don't work in the preferred manner. The
    > fallback has to be plain text (really Base64 encoded, but effectively
    > plain text), since that's the lowest common denominator. Send a plain
    > text password, and let the other system do whatever it wants to do with
    > it. Somewhat confusingly, there are actually two different plain text
    > mechanisms - PLAIN and LOGIN. From what I can tell, those are minor
    > protocol differences respecting backward compatibility for *nix and MS
    > respectively. PLAIN is technically better, but security-wise, they're
    > the same - Base64 encoded text. So if you allow one, you might as
    > well allow both. With the PLAIN and LOGIN mechs, you get option c)
    > saslauthd. Saslauthd is what's responsible for "doing whatever needs to
    > be done" for the individual system - it's basically a way to encapsulate
    > specific, privileged code and keep it out of the standard SASL protocol.
    > The thing to remember about saslauthd is that it is essentially a plain
    > text method - *it's only safe if you have end-to-end encryption (SSL or
    > TLS) protecting the exchange*.
    > Summary: We need plain text authentication, using saslauthd.
    > 2) Debian's Sendmail.conf is dated.
    > If it weren't bad enough that SASL is non-intuitive and, arguably,
    > confusing, it also just so happens that SASL configuration has changed
    > considerably between SASLv1 and SASLv2. Unfortunately, docs relating to
    > v1 are much more common on the Net, probably because installations using
    > this sort of thing are not prone to quick changes. There's a good page
    > on SASLv2 here:
    > Very important page - wish I had found it earlier. I'm sure it must be
    > included in the Debian docs somewhere, but I couldn't find it. The long
    > and the short of it is that there are *many* fewer options in the config
    > files now. Again, this makes old docs basically worthless. In
    > particular, there used to be both pwcheck_method and
    > sasl_pwcheck_method. As best as I can tell, this is no longer the case.
    > There is now only pwcheck_method, which has 3 theoretical
    > specifications, but really only 2:
    > 1) auxprop - catchall for secure communications. This means auth'ing
    > against sasldb via MD5 hashes, or Kerberos, or (your favorite) OPIE/OTP,
    > or SQL. It looks like "auxprop_plugin" can be used to specify exactly
    > which one to use, but that may be deprecated too... I can't tell. As
    > you've seen, this gets confusing when you don't understand why SQL, etc.
    > is getting involved. In SASL terms, these are the mechs CRAM-MD5,
    > DIGEST-MD5, GSSAPI, KERBEROS-V4, OTP, MYSQL, and a couple other
    > oddballs.
    > 2) saslauthd - catchall for plain-text communications. This will
    > require saslauthd to be running with the appropriate "-a" flag. This is
    > used by the SASL mechs PLAIN and LOGIN (obsolete).
    > 3) pwcheck - obsolete. This is, I think, another plain text auth in
    > theory. But it's explicitly deprecated in favor of saslauthd. I
    > imagine this is the source for the existence of both "pwcheck_method"
    > and "sasl_pwcheck_method" in old configs and scripts. This option has
    > to be explicitly enabled at SASL compile-time, and most packages won't
    > even use it. Would have been better if they had just let it die, IMO...
    > So Debian's Sendmail.conf.2 is pretty damn misleading. Besides the fact
    > that still includes both *pwcheck_method lines, the options listed
    > in the comments for "pwcheck_method" are obsolete. Brilliant. The ONLY
    > thing you need in Sendmail.conf.2 to auth against shadow is
    > pwcheck_method: saslauthd
    > and then make sure you run (as root) "saslauthd -a shadow". You could
    > change "-a shadow" to "-a pam" also, but I didn't check it out because
    > PAM is a PITA I don't like to mess with and it's not necessary in this
    > case anyway.
    > Christ, have I really been talking this long and not posted a config
    > yet? Seems so. I've attached the archive smtpauth.tgz to this mail.
    > It contains two things:
    > 1) mail.tgz - my entire /etc/mail directory for reference. Like I said
    > in the first mail, this stuff is hard enough without all the Debianese
    > going on, so I ripped it all out and did everything manually. I'd guess
    > Debian's tools and the Makefile will complain if you try to use them - I
    > just created directly from using m4. The
    > default init scripts still work fine, though. Don't get me wrong, I'm
    > sure Debian's configuration is fabulous, but it just wasn't what I was
    > interested in figuring out right now.
    > 2) - my .mc file, commented. This is not usable as is,
    > because I used #'s instead of dnl's. More readable that way. I also
    > regrouped some lines - there's no guarantee that that's OK with m4, so
    > refer to the original in mail.tgz.
    > So that's pretty much the end of the story. As I mention repeatedly in
    > the .mc, you still have to get TLS working. I'll leave that part up to
    > you.
    > Cheers,
    > Todd


    To UNSUBSCRIBE, email to 
    with a subject of "unsubscribe". Trouble? Contact

  • Next message: Anthony Rowe: "Re: Replying by email to the newsfeed"