我昨天发布在askubuntu.com上，但没有得到任何回应。
我们运行一个生产Ubuntu服务器，每天为数千人提供服务。 Sendmail目前没有在这个服务器上工作。 我们花了好几天的时间尝试恢复，但我们还没有find任何解决scheme。
目前有一个错误报告似乎与这个问题有关，所以它比我们影响更多的人。
这是我们所知道的。
星期天我们在服务器上运行更新。 第二天我们发现sendmail没有发送邮件。
/var/log/sendmail.log在每个电子邮件条目上报告“stat = Deferred”。
它偶尔会重复以下消息：
STARTTLS=client, error:connect failed=-1, SSL_error=1, errno=0, retry=-1 STARTTLS=client: 7042:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338:ruleset=tls_server, arg1=SOFTWARE, relay=xxx.xxx.edu, reject=403 4.7.0 TLS handshake failed. 我们检查了SMTP服务器上的日志，发现如下：
06-25T10:57:20-06:00 gw26 sm-mta[17229]: STARTTLS=server, error: accept failed=0, SSL_error=1, errno=0, retry=-1 No explanation available 2015-06-25T10:57:20-06:00 gw26 sm-mta[17229]: STARTTLS=server: 17229:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1110:SSL alert number 40 Explain this log line 2015-06-25T10:57:20-06:00 gw26 sm-mta[17229]: t5PGvKk0017229: opus.byu.edu [128.187.102.135] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
我们花了很多时间在Google上search，发现有几个人在其他操作系统（CentOS和OpenBSD）上遇到了相关的问题。 看来OpenSSL已经更新，现在需要更长的SSL密钥才能正常工作。
启动板页面上的这个错误可能是相关的。
我们试图通过遵循这里给出的CentOS指令来解决这个问题。 注：我们更改了新的dhparams.pem文件的位置。
在您的服务器上生成DH参数文件：
openssl dhparam -out /etc/pki/tls/certs/dhparams.pem 1024 Configure sendmail to use this parameters file, and to use only strong ciphers.添加到/etc/mail/sendmail.mc：
O LOCAL_CONFIG O CipherList=HIGH:!ADH O DHParameters=/etc/pki/tls/certs/dhparams.pem O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 O SSL_OP_CIPHER_SERVER_PREFERENCE O ClientSSLOptions=+SSL_OP_NO_SSLv2 O SSL_OP_NO_SSLv3然后使用make -C / etc / mail /和service sendmail重新启动。
这似乎没有任何改善。
编辑：
通过执行以下操作closuresTLS，sendmail立即开始运行。 但是，这不是一个解决scheme，因为我们不想发送明文电子邮件。
添加
Try_TLS:1.2.3.4 NO到/ etc / mail / access。
在/ etc / mail中做一个make并重新启动sendmail。
据我所知，问题是您的 OpenSSL升级使您不能容忍其他的短DH密钥长度，以保护对话免受Logjam攻击 。 这就是为什么增加你的 DH密钥长度（ openssl dhparam ...等）没有任何帮助，而closuresTLS。
显然，我们所有人都喜欢的是一个OpenSSL的标志，就像--I'd-rather-my-mail-got-encrypted-even-if-the-NSA-are-reading-it-on-the-fly-so-just-shut-up-about-short-DH-keys-already 。 不幸的是，这种行为似乎被编译到OpenSSL中，开发人员并没有select支持像我所build议的那样的标志，而且sendmail似乎没有编译成能够取消触发这种行为的密码套件。
这也意味着长期的解决scheme是让其他邮件服务器的pipe理员升级他们的DH密钥长度。 您可以逐个域地closuresTLS的使用，并access映射条目
Try_TLS:mail.example.com NO
（感谢novosial.org的想法），如果你能确定你交换了大量电子邮件和pipe理员响应速度慢的特定同行。 但据我所知，如果你的服务器（像我的）是突然对其他人的encryption参数挑剔的人之一，那么解决这个问题的能力是有限的。
我遇到了同样的问题，并纠正sendmail.cf如下。
O CipherList=HIGH:!ADH:+DH
这意味着使用DH密钥的密码的优先级降低。 这样做时，优先使用与DH密钥无关的密码，所以不会发生DH密钥错误。