Good thought. Since it's acting as though it doesn't implement MTA-STS, then it should not include these messages in TLSRPT reports, correct?
On 3/28/19 2:51 PM, Brotman, Alexander wrote: > > Jim, > > > > I’m not sure how much of an impact this might have, but should there > be a reference to TLSRPT? Either not to be counted or to explain the > lack of TLS based on “TLS-Required: no” being set? > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:*Uta <[email protected]> *On Behalf Of *Jim Fenton > *Sent:* Wednesday, March 27, 2019 4:34 AM > *To:* [email protected] > *Subject:* [Uta] Revised wording on security consideration re TLS-Required > > > > Thanks for the feedback on my proposed language for a new security > consideration regarding conflicts between the TLS-Required header > field and DANE and MTA-STS recipient policies. Here's another stab at it: > > ===== > > 8.4. Policy Conflicts > > > > In some cases, the use of the TLS-Required header field may conflict > with a recipient domain policy expressed through the DANE [RFC7672] or > MTA-STS [RFC8461] protocols. Although these protocols encourage the > use of TLS transport by advertising availability of TLS, the use of > ”TLS-Required: No” header field represents an explicit decision on the > part of the sender not to require the use of TLS, such as to overcome > a configuration error. The recipient domain has the ultimate ability > to require TLS by not accepting messages when STARTTLS has not been > negotiated; otherwise, "TLS-Required: No" is effectively directing the > client MTA to behave as if it does not support DANE nor MTA-STS. > > > > ===== > > > > Comments welcome. > > > > -Jim >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
