> On Nov 17, 2017, at 4:02 AM, Jim Fenton <[email protected]> wrote:
>
>> 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)?
Typical (or at least common) use of procmail and similar tools is
forwarding some or all mail to another system where the user will
actually access the email, so if TLS is be used at each hop from
sender's MUA to the intended recipient's mailbox, it needs to be
enable to tunnel through the occasional non-SMTP hop, or a secure
SMTP hop that does not (explicitly) support REQUIRETLS.
For example, at my place of work we have SMTP spam-filtering
appliances that receive all mail over TLS, scan it, and re-inject
non-spam back into the mailstream via authenticated TLS. However,
they don't support REQUIRETLS, so the ESMTP signal will be lost
in transit through these devices. However a header will make
it through, and the mail can then continue on its way with TLS
enforced again downstream.
> 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.
Yes, the ESMTP handshake will be required on all SMTP hops, except
for any where local configuration statically asserts that the nexthop
preserves REQUIRETLS passively (via the header as above, because
once email leaves the REQUIRETLS-agnostic handler, it re-enters
the mail stream in a way that revives REQUIRETLS from the header).
This may mean that mailing list software will need to strip
REQUIRETLS, this can be done by stripping the header at the
MTA before giving it to the list manager.
Users resending unencapsulated messages (mutt's "bounce" feature,
or Mail.app's "Redirect") may (bug or feature?) then also trigger
REQUIRETLS when the message is resent. One way to deal with that
is to look at "Resent-Require-TLS:" rather than "Require-TLS:"
when a message has "Resent-From:" or "Resent-To:" headers.
One might similarly look for "List-Require-TLS:" when a message
has "List-*" headers. So this requires a bit more care.
>> 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.
Naturally.
> 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.
The possibility of partial support does not make a strong case for
separate specification, folks have implemented parts of specifications
before. The overlaps of the designs, is more compelling.
Furthermore, the "NO" case will be by far the more frequently used
feature. If we want STS and DANE to not be crippled by service
providers with downgrade resistant enforcement on by default, we
need to give users an opt-out mechanism. There'll be enough
operational errors to require occasional work-arounds by senders.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
