One of the significant discussions at the Prague meeting (and originally resulting from IESG comments) was that the Section 6, "Mailing list considerations" was incomplete because it didn't consider other causes of origination such as Sieve and vacation programs. So I have drafted an alternative Section 6, below. Please review and comment. (Thanks Barry L. for reviewing first draft).
6. Reorigination considerations In a number of situations, an agent for the addressee of a message originates a new message as a result of an incoming message. These situations include, but are not limited to, mailing lists (including administrative traffic such as message approval requests), Sieve [RFC 5228], "vacation" responders, and other filters to which incoming messages may be piped. These newly originated messages may essentially be copies of the incoming message, such as with a forwarding service or a mailing list expander. In other cases, such as with a vacation message or a delivery notification, they will be different but might contain parts of the original message or other information for which the original message sender wants to influence the requirement to use TLS transmission. Agents that reoriginate messages should apply REQUIRETLS requirements in incoming messages (both requiring TLS transmission and requesting that TLS not be required) to the reoriginated messages to the extent feasible. A limitation to this might be that for a message requiring TLS, redistribution to multiple addresses while retaining the TLS requirement could result in the message not being delivered to some of the intended recipients. User-side reorigination (such as use of Sieve rules on a user agent) typically does not have access to the SMTP details, and therefore may not be aware of the REQUIRETLS requirement on a delivered message. Operators of user-side agents that expect sensitive traffic should consider this possibility, and if operationally feasible (when forwarding to a specific, known address; when appropriate configuration options are available) should apply REQUIRETLS whenever feasible to messages that do not contain the "TLS-Required: No" header field.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
