On 6 Apr 2018, at 16:20, Jim Fenton wrote:
The major change in this version is the removal of the options (CHAIN, DANE, and DNSSEC) from the REQUIRETLS SMTP option as discussed in London. There were also inconsistencies in the header field name (Require-TLS vs. RequireTLS) so I chose the latter.
Although I don't intend to implement this because I don't foresee a use case, I reviewed it out of curiosity:
1. Section 4.3 needs to allow use of implicit TLS (RFC 8314) in addition to STARTTLS. The submission client would verify the TLS certificate of the submission server as documented in RFC 8314.
2. There should be an example showing the SMTP protocol used with the REQUIRETLS mail from parameter.
3. The IANA considerations are incomplete. For example, they are missing fields required to register in the SMTP mail system response codes registry. See RFC 5248. I'm not sure this specifies all the IANA registration fields described in RFC 5321 for an SMTP extension. IANA considerations are not typically removed during publication.
Architecturally, I see "RequireTLS: No" as potentially useful to work around MTA-STS deployment bugs.
I think the text related to bouncing a REQUIRETLS message is highly problematic. Metadata related to email is not private due to laws in certain jurisdictions and pretending it can be more private than it is does a disservice to implementers and users. The mail bounce infrastructure is already problematic and this makes that infrastructure more complicated; if this were implemented it would increase the chances of lost mail and/or the cost of mail system operations. I find both of those outcomes objectionable. Even if I decided to implement REQUIRETLS, I'd deliberately choose not to implement the entire section about bounce processing as presently written (and document that choice as both an intentional choice and a good one).
If you want to say something about bounce processing, I believe this is the best you can do without making the bounce processing unduly complex:
If a REQUIRETLS message is bounced, the server MUST behave as if RET=HDRS was present as described in RFC 3461. If both RET=FULL and REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS bounce message MUST use an empty MAIL FROM return-path as required by RFC 5321. When the MAIL FROM return-path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message to be discarded even if the next-hop relay does not advertise REQUIRETLS.
- Chris _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta