Subject: Re: [Uta] REQUIRETLS update

From: Jim Fenton <[email-masked]>
Date: Thu, 12 Jan 2017 09:48:59 -0800

On 12/16/16 3:31 PM, Viktor Dukhovni wrote:
>> On Dec 16, 2016, at 5:53 PM, Jim Fenton <[email-masked]> wrote:
>>
>> It seems that Viktor and I have differing views on the usefulness of
>> MAYTLS and REQUIRETLS. That said, I agree that it doesn't make sense to
>> have two mechanisms for this, so I will try to formulate a hybrid
>> mechanism for the next iteration of the draft.
> Thanks.  With that out of the way, I can elaborate on some of the policy
> details that need to be discussed as part of this.
>
I'm working on the revision of the REQUIRETLS draft, and ran into a
situation with "MAYTLS" that I'm not sure how to resolve.

In the case of REQUIRETLS, it makes sense to make sure that the SMTP
server to which the message is being sent supports REQUIRETLS, because
otherwise the REQUIRETLS characteristics of the message will be lost and
the message may be sent in the clear on a subsequent hop.

But with MAYTLS (or what I'm thinking of as REQUIRETLS=NO, since it's
asking that TLS not be required), there are two ways to handle this:

1. Go ahead and send message to an SMTP server not supporting the
extension. But then the sender's request to send regardless of DANE or
STS policy gets lost on subsequent hops. If the need was only to do this
for a single hop, the SMTP client can just ignore the DANE or STS policy
and wouldn't need the extension at all.

2. Make sure that the server supports the extension, but then the
message will be more likely to be blocked/bounced, which is the opposite
of the sender's intent (this is for urgent, non-sensitive messages).

In other words, MAYTLS is very fragile unless onward support is
confirmed and doing so is likely to run counter to the sender's request.

Thoughts?

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Jan 2017 17:59:14 +0000

> situation with "MAYTLS" that I'm not sure how to resolve.

[ Thanks for moving forward with this work! ]

> the message may be sent in the clear on a subsequent hop.

Yes.

> and wouldn't need the extension at all.

Yes.  Send regardless.  The signal is a best-effort signal.

Since the MAYTLS feature is intended to facilitate delivery over
security, mail needs to be delivered whether the feature is supported
or not.  So in some cases the signal may not get through all the
requisite hops, but typically it only needs to get as far as the
border MTA of the sender's organization.  The MSA may not be that
border MTA.

Another approach is to define a new message header that requests
a delivery despite apparent security downgrade.  Such a signal
would tunnel through MTAs that are oblivious to the signal.

> of the sender's intent (this is for urgent, non-sensitive messages).

So no this.

> confirmed and doing so is likely to run counter to the sender's request.

I think that best-effort support is sufficient.  Sites that support
DANE or STS are early adopters with comparatively new MTAs, and
are also more likely to also have MAYTLS support (once that's
implemented in the most recent versions of popular MTAs).

-- 
	Viktor.