Thanks for your review, Chris:
On 4/9/18 6:08 PM, Chris Newman wrote: > 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. Agreed. I was somewhat focused on message relay (since submission is the first hop, and the sender can directly control what happens there). But submission is also SMTP, and the REQUIRETLS should handle all uses of SMTP consistently. > > 2. There should be an example showing the SMTP protocol used with the > REQUIRETLS mail from parameter. Good idea. > > 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. I'll fix this section; it does appear to be incomplete. I should have said that the IANA Considerations are updated at publication, right? I'm not entirely clear on how the status codes (specifically the detail sub-code) are assigned. Do I leave it as .X in the draft, to be changed into an actual value at 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. Part of the point of REQUIRETLS is that end-to-end encryption doesn't cover everything -- specifically not the message header and envelope information. While that information is not private to the MTAs handling the message and potentially the jurisdictions in which they reside, TLS prevents that information from being available to the jurisdictions through which the message merely passes. The point of the bounce language is to make sure that is still the case for a message bounce. I'm still concerned about metadata leakage on these bounce messages. I do see a problem that the current text (section 5 paragraph 3) assumes that the sender of a bounce would get feedback about whether the bounce delivery failed, which doesn't work because the envelope-from address would be empty as required by RFC 5321. So what I would have it say there is that bounce messages resulting from REQUIRETLS should always be redacted. Unfortunately, this means that the bounce is only delivered to the postmaster, which isn't particularly useful. So then we're back to sending bounces to REQUIRETLS messages with REQUIRETLS also, and not doing any special redaction, other than noting that some bounces may be discarded by the mail system as a result. I really don't see the value in changing RET=FULL into RET=HDRS. In many cases, who's sending mail to whom is as (or more) interesting to an eavesdropper as the message content. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
