On 11/16/17 3:49 PM, Viktor Dukhovni wrote: > 1. I agree that REQUIRETLS=NO needs a header so it can be > tunnelled via an "agnostic" MTA. > > 2. However, even REQUIRETLS=YES needs a header, because: > > a. Within an MTA a message may make multiple internal > hops, for example processing via a loopback SMTP > proxy that does virus scanning, or forwarding via > a spam-scanning appliance that is statically configured > to always do TLS both upstream and downstream, but does > not support REQUIRETLS=YES explicitly. > > b. Messages may get filtered via procmail and the like > and then forwarded, and again the delivery channel > has no means to preserve REQUIRETLS=YES except via a > header.
Let me think about the procmail->forward case a bit. Is that considered forwarding of the same message or origination of a new one (same question for mailing lists)? We could define a header field that is consulted when a message is originated (transitions from something else to SMTP) to set the REQUIRETLS option for that first hop. I would want it to be clear that for all other hops, the REQUIRETLS option on MAIL FROM is what gets used. > > 3. Therefore, REQUIRETLS will need a header for both YES and > NO, but the YES case will also want to see a "REQUIRETLS" > in the EHLO response of a remote MTA, so it can commit to > honouring the extension. > Having the NO option only be a header field simplifies things. It was making a mess of negotiation of the REQUIRETLS SMTP extension having REQUIRETLS=NO not actually require REQUIRETLS to be negotiated. But I still see these as two separate features, REQUIRETLS and IgnoreTLSPolicy. I can picture that there would be implementations of IgnoreTLSPolicy that might not include REQUIRETLS and vice versa. That's why I see them as separate documents. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
