I'm probably missing something obvious, but I can get sendmail to give me AUTH PLAIN and LOGIN options.
What I have is fairly standard configuration. The relevant part of sendmail.mc looks something like this:
define(`confCACERT_PATH',`/etc/ssl/certs') define(`confCACERT',`/etc/ssl/ca-bundle.crt') define(`confSERVER_CERT',`/etc/ssl/smtp.crt') define(`confSERVER_KEY',`/etc/ssl/smtp.key') define(`confAUTH_OPTIONS', `A p') TRUST_AUTH_MECH(`EXTERNAL LOGIN PLAIN') define(`confAUTH_MECHANISMS', `EXTERNAL LOGIN PLAIN') DAEMON_OPTIONS(`Port=25, Name=MTA') DAEMON_OPTIONS(`Port=465, Name=TLSMTA, M=s')
So basically, LOGIN and PLAIN should be offered when SSL/TLS is in use (but not for plaintext sessions). However, when connecting over TLS, sendmail doesn't advertise them:
$ openssl s_client -connect localhost:465 [ SSL/TLS handshake output deleted, AES256 cipher was used ] 220 testbox.miliv.org ESMTP Unauthorized access prohibited EHLO localhost 250-testbox.miliv.org Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DELIVERBY 250 HELP
Attempt to "brute-force" use them results in error (as expected):
AUTH PLAIN 504 5.3.3 AUTH mechanism PLAIN not available
I'm sure I'm missing something obvious here, probably a flag or two either in confAUTH_OPTIONS or in DAEMON_OPTIONS, but couldn't dig out which.
Alraedy drank all coffe, and becoming desparate ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Probably a silly question, but did you rebuild your sendmail.cf after modifying the sendmail.mc?
Mike
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of alex@milivojevic.org Sent: Wednesday, July 06, 2005 1:16 PM To: CentOS mailing list Subject: [CentOS] sendmail + plain auth
I'm probably missing something obvious, but I can get sendmail to give me AUTH PLAIN and LOGIN options.
What I have is fairly standard configuration. The relevant part of sendmail.mc looks something like this:
define(`confCACERT_PATH',`/etc/ssl/certs') define(`confCACERT',`/etc/ssl/ca-bundle.crt') define(`confSERVER_CERT',`/etc/ssl/smtp.crt') define(`confSERVER_KEY',`/etc/ssl/smtp.key') define(`confAUTH_OPTIONS', `A p') TRUST_AUTH_MECH(`EXTERNAL LOGIN PLAIN') define(`confAUTH_MECHANISMS', `EXTERNAL LOGIN PLAIN') DAEMON_OPTIONS(`Port=25, Name=MTA') DAEMON_OPTIONS(`Port=465, Name=TLSMTA, M=s')
So basically, LOGIN and PLAIN should be offered when SSL/TLS is in use (but not for plaintext sessions). However, when connecting over TLS, sendmail doesn't advertise them:
$ openssl s_client -connect localhost:465 [ SSL/TLS handshake output deleted, AES256 cipher was used ] 220 testbox.miliv.org ESMTP Unauthorized access prohibited EHLO localhost 250-testbox.miliv.org Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DELIVERBY 250 HELP
Attempt to "brute-force" use them results in error (as expected):
AUTH PLAIN 504 5.3.3 AUTH mechanism PLAIN not available
I'm sure I'm missing something obvious here, probably a flag or two either in confAUTH_OPTIONS or in DAEMON_OPTIONS, but couldn't dig out which.
Alraedy drank all coffe, and becoming desparate ;-)
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Quoting Paul Heinlein heinlein@madboa.com:
On 7/6/05 11:23 AM, Mike Kercher wrote:
Probably a silly question, but did you rebuild your sendmail.cf after modifying the sendmail.mc?
The other silly question: what do you system and/or mail logs say?
Short answer: nothing particulary usefull.
Long answer:
After rebuilding the sendmail.cf, restarting sendmail, and connecting to it (only EHLO, and QUIT commands issued), this is all that is recorded in log files:
Jul 6 13:34:28 testbox sendmail[7220]: alias database /etc/aliases rebuilt by alex Jul 6 13:34:28 testbox sendmail[7220]: /etc/aliases: 578 aliases, longest 49 bytes, 16563 bytes total Jul 6 13:34:28 testbox sendmail[7229]: starting daemon (8.13.1): SMTP+queueing@01:00:00 Jul 6 13:34:31 testbox sendmail[7243]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jul 6 13:34:35 testbox sendmail[7243]: j66IYV5d007243: localhost [127.0.0.1] did not issue MAIL/EXPN/VRFY/ETRN during connection to TLSMTA
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 7/6/05 11:51 AM, alex@milivojevic.org wrote:
Quoting Paul Heinlein heinlein@madboa.com:
The other silly question: what do you system and/or mail logs say?
Short answer: nothing particulary usefull.
OK, so I've got some other questions:
I don't understand the EXTERNAL option, along with LOGIN and PLAIN. I've never used it; is it necessary?
Assuming you've got a stock Red Hat-esque sendmail binary that's linked against the SASL libraries, and assuming that your /usr/lib/sasl2/Sendmail.conf file points to saslauthd as the password-checking mechanism -- have you started the saslauthd daemon?
Quoting Paul Heinlein heinlein@madboa.com:
OK, so I've got some other questions:
I don't understand the EXTERNAL option, along with LOGIN and PLAIN. I've never used it; is it necessary?
Me neither ;-)
I believe EXTERNAL should allow for SSL/TLS authentication (for example if client has certificate and is listed in access.db). But I'm not sure. I don't use it, I left it since it was there by default (only removed GSSAPI and two MD5 mechs since those are useless for me in this installation).
Anyhow, removing EXTERNAL does not make any difference. I'll leave it out of the configuration for now, just to rule out posiblity that it has any influence on the problem I have.
Assuming you've got a stock Red Hat-esque sendmail binary that's linked against the SASL libraries, and assuming that your /usr/lib/sasl2/Sendmail.conf file points to saslauthd as the password-checking mechanism -- have you started the saslauthd daemon?
Yes, saslauthd is running and correctly configured. I've tested it with testsaslauthd, and it works.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Quoting Mike Kercher mike@CamaroSS.net:
Probably a silly question, but did you rebuild your sendmail.cf after modifying the sendmail.mc?
Yes, I did rebuilt it, and I did restarted sendmail.
I also attempted to add 'a' flag to the TLSMTA (found advice on comp.mail.sendmail). It didn't helped of course (per documentation, it simply requires authentication, so after adding it, all commands were failing).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Am Mi, den 06.07.2005 schrieb alex@milivojevic.org um 20:16:
I'm probably missing something obvious, but I can get sendmail to give me AUTH PLAIN and LOGIN options.
What I have is fairly standard configuration. The relevant part of sendmail.mc looks something like this:
define(`confCACERT_PATH',`/etc/ssl/certs') define(`confCACERT',`/etc/ssl/ca-bundle.crt') define(`confSERVER_CERT',`/etc/ssl/smtp.crt') define(`confSERVER_KEY',`/etc/ssl/smtp.key') define(`confAUTH_OPTIONS', `A p') TRUST_AUTH_MECH(`EXTERNAL LOGIN PLAIN') define(`confAUTH_MECHANISMS', `EXTERNAL LOGIN PLAIN') DAEMON_OPTIONS(`Port=25, Name=MTA') DAEMON_OPTIONS(`Port=465, Name=TLSMTA, M=s')
Looks good (though it is a good idea to end each line with a "dnl")
The cyrus-sasl-plain rpm is installed?
Alexander
Quoting Alexander Dalloz ad+lists@uni-x.org:
Looks good (though it is a good idea to end each line with a "dnl")
The cyrus-sasl-plain rpm is installed?
Ha, I *knew* it was something trivial :-)
Nope, it was not installed. As soon as I installed it, voila, PLAIN and LOGIN are there. Many thanks Alexander.
Aleksandar
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-
alex＠milivojevic.org -
Alexander Dalloz -
Mike Kercher -
Paul Heinlein