> 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 fish. 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
> 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 sendmail.cf directly from sendmail.mc 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) sendmail.mc.com - 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