Re: easiest way to configure STARTTLS and PAM/AUTH on debian sendmail?
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
> 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.
> I'm 100% against sasl in general just for the simple fact that the
> developers have chosen to store passwords and user credentials in
> PLAINTEXT in a file on the filesystem. (add to that the need to
> maintain and synchronize two different databases or username/password
> information.)
Read the mailing lists, the horse carcass is almost completely decayed.
Yes, the two two sources is a PITA, but I don't see things changing...
If there is to be a plaintext authentication, from whence does it come?
/etc/shadow is MD5, ldap can use MD5 or other, etc... Upstream seems
convinced that this isn't a problem, and that the callbacks to support
automigrate aren't worth the effort (which is what sendmail did by
default for SASL v1) :(
I note with some disatisfaction that you emailed me on this, and I
responded within hours (modulo the time delta) - only to see the
various posts of yours here... Maybe I shouldn't stay up this late,
but it still seems coherent, for what little info there was !
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.
--
Rick Nelson
Intel engineering seem to have misheard Intel marketing strategy. The phrase
was "Divide and conquer" not "Divide and cock up"
(By iialan@www.linux.org.uk, Alan Cox)
Reply to: