与此同时,我注意到如果发生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.
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开始,我认为避免使用这个新选项只会有助于一些真正的边缘情况,其中收件人邮件服务器被临时重新配置并稍后更正.
