Description of problem: sendmail has starttls crypto support, yea! not enabled , nay! Version-Release number of selected component (if applicable): sendmail-8.12.9-7 How reproducible: anytime sendmail talks to another tls enabled mail server Steps to Reproduce: 1. install sendmail 2. send mail to tls enabled mail server 3. Actual results: echo test| /usr/sbin/sendmail teststarttl Jul 29 12:49:18 morticia sendmail[23793]: h6TJnHbS023793: to=teststarttl, ctladdr=chrismcc (500/500), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30005, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (h6TJnHsd023794 Message accepted for delivery) Jul 29 12:49:19 morticia sendmail[23796]: STARTTLS=client, relay=mail.clemson.edu., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 Expected results: [chrismcc@morticia mail]$ diff sendmail.mc.redhat sendmail.mc -u --- sendmail.mc.redhat 2003-07-29 12:50:10.000000000 -0700 +++ sendmail.mc 2003-07-29 12:50:23.000000000 -0700 @@ -46,8 +46,8 @@ dnl # Rudimentary information on creating certificates for sendmail TLS: dnl # make -C /usr/share/ssl/certs usage dnl # -dnl define(`confCACERT_PATH',`/usr/share/ssl/certs') -dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') +define(`confCACERT_PATH',`/usr/share/ssl/certs') +define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt') dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem') dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem') dnl # [chrismcc@morticia mail]$ sudo make sendmail.cf [chrismcc@morticia mail]$ sudo /sbin/service sendmail restart echo test| /usr/sbin/sendmail teststarttl Jul 29 12:51:48 morticia sendmail[23896]: STARTTLS=client, relay=mail.clemson.edu., version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256 Additional info: note the 'verify=OK' sendmail will _always_ try tls if the other server supports it. it will try to verify the cert, but it has no CA data to use (ca-bundle.crt) so it will always fail. make sense? same for taroon, should I make another bug?
I'm as eager as anyone to see STARTTLS adopted universally, but I'm not sure enabling this by default is a good idea yet. There are a lot of broken ESMTP servers out there, and this does cause problems with some of them.... For example, MS Exchange 5.5 (still widely used, unfortunately) out of the box as a server advertises STARTTLS support, even when TLS is not configured / enabled. When the sendmail client connects, it will naturally try to negotiate, fail, and go boom. I enable STARTTLS both client-side and server-side on all my SMTP servers, but I know to monitor the logs and to whitelist (or blacklist, depending on your point of view ;-) the servers which advertise STARTTLS even though they don't actually support it. I don't know that it's reasonable to expect everyone using RH to have to do the same, or even to know to do the same....
Is it possible to have sendmail just be tolerant of such broken servers? E.g. give up on TLS when things go wrong, but not give up on transmission?
Chris, can you supply an example of a broken Exchange server ( off bugzilla if need be ). The only problems I've seen are FAIL with fallback to non TLS.
We need a better infrastructure to setup certs within Red Hat. Newest rpm at http://people.redhat.com/laroche/sendmail* has some script, but we need more of this. greetings, Florian La Roche
Fixed since 8.12.10-3.