与此同时,我注意到如果发生TLS握手错误,sendmail将不会再费力地使用标准的未加密传送方法.这是正常的行为吗？
如果(并且仅当)我明确地要求它用于域,我希望这个逻辑到位.例如,如果我在/ etc / mail / access中添加了TLS_SRV选项.在这种情况下,我没有.从本质上讲,Sendmail只运行“机会主义TLS”.
到目前为止,我遇到的所有信息都表明这个问题是预期的行为并且是硬编码的…
按照http://www.sendmail.org/m4/starttls.html#disable_starttls：
By default STARTTLS is used whenever
possible. However,there are some
broken MTAs that don’t properly
implement STARTTLS. To be able to send
to (or receive from) those MTAs,the
ruleset try_tls (srv_features) can be
used that work together with the
access map. Entries for the access map
must be tagged with Try_TLS
(Srv_Features) and refer to the
hostname or IP address of the
connecting system.
根据http://etutorials.org/Server+Administration/Sendmail/Part+II+Administration/Chapter+10.+Maintain+Security+with+sendmail/10.10+STARTTLS/：
If the access database is not used,
the connection is allowed in all
cases,both inbound and outbound,
unless the value in ${verify} is
SOFTWARE,in which instance the
connection is not allowed.
这两个模糊都表明,当另一方声称支持TLS时,try_tls功能是跳过TLS的唯一选项.我知道这是一个选项,但它很麻烦,因为这意味着我需要在出站域出现问题时手动创建例外.
还有其他方法让sendmail回退吗？
Note: this patch is integrated in 8.16 (at least available as snapshot)
截至本文,8.16还不是released,所以现在你必须使用/ etc / mail / access或/ etc / mail / access_db作为Seth suggested,并确保使用makemap hash / etc / mail重建.db / access<在/ etc /邮件/访问 至于全球使用tls_failures的安全风险;考虑到这是从opportunistic TLS开始,我认为避免使用这个新选项只会有助于一些真正的边缘情况,其中收件人邮件服务器被临时重新配置并稍后更正.