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
