Subject: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2019 07:07:09 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-uta-smtp-require-tls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Benjamin's DISCUSS.

To elaborate on one point a bit: it seems to me that it's harmful to
security to allow the sender to unilaterally override the recipient's
preferences that something be encrypted. To forestall one argument,
yes, the sender knows the contents of the message, but the recipient
knows their own circumstances, and they may be at particular risk

       The choices of key lengths and algorithms change over time, so a
       specific requirement is not presented here.

This is not a verifiable conformance requirement. You
either need to not have a 8174 SHOULD here, or actually specify what
"meaningfully secure" means.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   email by giving the originator of a message an expectation that it
   will be transmitted in an encrypted form "over the wire".  When used,
   REQUIRETLS changes the traditional behavior of email transmission,

This does not seem to accurately describe "RequireTLS: NO"

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2019 12:22:32 -0800

On Thu, Feb 21, 2019 at 10:37 AM Viktor Dukhovni <[email-masked]>
wrote:

> > On Feb 21, 2019, at 10:07 AM, Eric Rescorla <[email-masked]> wrote:
> >
> A recipient has no expectation that the sending MTA supports any of
> DANE, MTA-STS, REQUIRETLS, or even STARTTLS.

Nor do Web servers have any expectation that clients support HSTS, but we
still don't allow it to be overridden by some http-no-really:// link.

> The most the recipient can do is abort the SMTP transaction at any
> pre-STARTTLS "MAIL FROM" (typically sent with the pipelined recipient
> list) when STARTTLS is not used by the sender (or MITM attacker).
>
> More harmful to security than acknowledging that either participant
> has the freedom to choose the policy that works best for them, is
> restricting their choices to the point of making the use of security
> mechanisms too burdensome to deploy.
>

The problem with this mechanism is that it is denying the recipient the
right
to choose what works for them.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Feb 2019 15:42:59 -0500

> still don't allow it to be overridden by some http-no-really:// link.

"http-no-really://" links are not the right analogy, links are
typically delivered to the user, they rarely expressions of the
user's policy choice.

Browers have interactive human users who can on the spot chose to
override whatever security policy is in place.  Firefox by default
offers me the opportunity to make certificate exceptions permanent,
and I always have to remember to uncheck the check-box to make an
exception for just the one connection.

SMTP servers deliver in the background, with the user out of the
loop, hence the need for "REQUIRETLS = no".

> right to choose what works for them.

I am not aware of any such right.  The receiving system is announcing
a capability, and the sending system does its best to achieve the
highest common security level.  The input to finding the highest
common level includes software feature availability and local policy,
potentially including user preference.

The receiving system *cannot* expect to enforce its ceiling, all
it can do is offer more security, and hope that it will be used.
For that to happen, more senders would have to support the security
mechanisms, but they are likely to hold back if these offer no way
workable way to manage exceptions.

Firefox and Chrome offer dialogues to bypass the built-in browser
security mechanisms, a somewhat analogous control should be available
to mail user agents.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2019 12:52:08 -0800

> typically delivered to the user, they rarely expressions of the

No, they're the expression of the link generator's policy choice, but the
same situation obtains, if you do, for instance, XHR.

> exception for just the one connection.

You can't override HSTS, actually.

> highest common security level.

No, it's saying "don't deliver this at all, if you can't do this"

>   The input to finding the highest

See above.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Feb 2019 17:30:36 -0500

> On Feb 21, 2019, at 3:52 PM, Eric Rescorla <[email-masked]> wrote:
> 

That may be true of HSTS, but is certainly not true of DANE or MTA-STS.
Both specify how to deliver (more) securely *if* you choose to enable
the mechanism for the destination in question or by default.  Neither
mechanism is mandated.  Local policy always comes first.  One might
for example want to reach the postmaster of a broken site, or send
a mundane time-sensitive message.

The title of RFC7672 is:

   SMTP Security via Opportunistic DNS-Based Authentication of Named
         Entities (DANE) Transport Layer Security (TLS)

the word "opportunistic" is not an accident, the mechanism is not
and should not be a mandate from the receiving system.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 26 Feb 2019 15:37:00 -0800

The general approach of REQUIRETLS is that the sender is in a good
position to determine the sensitivity of the message(s) they are
sending, because they know what the message is. Ultimately, for the last
hop anyway, the recipient has the ultimate control: they can refuse to
accept a message unless STARTTLS has been negotiated. For intermediate
hops, it's a matter of trying to balance the (perhaps) conflicting
wishes of the sender and recipient. And as Viktor has pointed out, this
provides a workaround for misconfigured mail systems. RequireTLS: NO is
not a very robust mechanism in any case, because it's very possible that
a relay MTA will not support REQUIRETLS and will ignore the header
field. But it's an attempt to get explicitly non-sensitive messages through.

> "meaningfully secure" means.

This text was removed in the -07 draft, and now has a reference to RFC
7525 for TLS negotiation requirements. Let me know if this addresses
this issue.

This text was also corrected in the -07 draft.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Feb 2019 19:09:33 +0000

I think Jim's explanation makes sense -- even if it's not required, you can still do best-effort -- and captures the desired semantics exactly right.  I hope the SecAD's will clear that discuss item.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2019 14:10:43 -0800

On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <[email-masked]> wrote:

> sending, because they know what the message is.

Right, this is what I am disputing.

Ultimately, for the last
> accept a message unless STARTTLS has been negotiated.

Actually, this doesn't work for two reasons:

1. There might be an active attacker.
2. Requiring TLS on the *receiver* side means that you can't talk to
clients which don't speak TLS.

-Ekr

For intermediate

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 Feb 2019 17:44:04 -0600

On Thu, 21 Feb 2019 07:07:09 -0800, Eric Rescorla wrote:
> [...]

This is placing too strong an emphasis on security to the detriment of
availability.

As in all things, we have to make trade-offs, and perfection is not
available to us.

In particular:

 - Email to postmaster@domain *must* be able to flow in the face of
   security-related misconfiguration, full stop.

   And, it's not always postmaster that is the contact.  The actual
   address of the actual postmaster can come from DNS SOA RRs, web
   pages, etc...

   If it were only postmaster@... surely you'd be amenable to exempting
   that.

 - Senders own the contents of what they send.  Recipients own the
   contents of what they receive.

   Each can have different policies as to how it should be sent or
   received, but each also can post it on social media, newspapers,
   whatever.

   Just because one of the parties wishes something be kept
   confidential, there is no guarantee in the absence of legal,
   contractual obligations (and PGP or S/MIME, since hop-by-hop
   transport security might not cut it or even be available).

   Refusing to accept insecurely-sent messages does not ensure their
   confidentiality!

The recipient does NOT know the sender's circumstances, and I do think
the sender's trump the recipient's.

HOWEVER, it is fair and *highly* desirable of the recipient to *mark* a
message as received insecurely -- keeping in mind that the recipient
can't force the sender to have authenticated the recipient...

My idea of an ideal end-state for hop-by-hop security for e-mail is
that:

a) *senders* should be able to specify in the envelope that they want
   secure, encrypted, authenticated delivery of email at every hop,

b) senders should get bounces when that cannot happen,

c) *recipients* get an indication of the security of any given e-mail's
   path to the recipient (perhaps we need a Transmitted: header by which
   each sending hop MTA can record what it did to authenticate the next
   hop),

d) (a) and (c) get prominent UI indications in MUAs,

e) as explained above, *senders* get a "make it go please" button for,
   e.g., "hey, dear recipient, your mail system is misconfigured, I
   cannot send secure e-mail" type messages.

Lastly,

f) forward notifications of failure to meet security policy (sender's or
   recipient's!), subject to DoS / spam filtering, naturally.

   A forward notification being like a bounce, but in the other
   direction.  The sender's address, the subject, etc., might not be
   disclosed -- the important thing is that the recipient should be able
   to discover misconfigurations and fix them.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Feb 2019 20:06:49 -0600

> I think Jim's explanation makes sense -- even if it's not required, you can still do best-effort -- and captures the desired semantics exactly right.  I hope the SecAD's will clear that discuss ite…

To be clear: I don't have a particular problem with the specific mechanisms
and behavior that let a sender indicate an intent to knowingly send
messages that may not receive full TLS protection.  My objection is more on
the terminology used to describe the behavior, and the process by which the
change in behavior of existing protocols is specified.

-Benjamin

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Feb 2019 08:01:55 -0800

> Right, this is what I am disputing.

I have to agree with EKR about it not completely being the sender's
decision, though for a rather different reason.  I really doubt that
in the vast majority of cases any human user will actively choose or
not choose this option on a message-by-message basis.  I think that in
the real world we'll see one of two use cases:

1. The sending system is just configured to require TLS, because, of
course, it's a Good Thing to make sure TLS is used all the time.  This
might or might not cause frustrating delivery problems, depending upon
how broadly and quickly this gets deployed.

2. Some other aspect of a message, such as having it marked "Company
Confidential", "Top Secret", or some such, will result in the sending
system requiring TLS for that message.  My experience with working in
organizations that use such markings is that they overuse them: the
sending human doesn't actually determine the sensitivity; rather, the
sending human becomes used to putting "Top Secret" on nearly
everything, or "Confidential and Privileged", in the case of lawyers,
on absolutely everything including, "Let's have lunch."

For EKR's concern about the recipient's preference, this protocol
would need some sort of recipient policy that senders would look up.
While I absolutely see the value in that, I'm not sure how workable it
would be.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 28 Feb 2019 08:15:03 -0800

> d) (a) and (c) get prominent UI indications in MUAs,

See, this is why we often say that IETF folks should not generally try
to design UI things:
There are plenty of studies that show that users -- apart from those
of us on this discussion thread and our ilk -- don't understand these
sorts of UI indications.  General users grossly misunderstand the
"lock" symbol that browsers use to tell us that HTTPS is in effect.
I'm sure that any attempt to create some version of "this message
was/wasn't sent in a way that the message content can't have been
looked at in transit (well, except for someone looking at it while it
was stored waiting to be relayed)" that's understandable to a typical
user will be wildly unsuccessful.

Barry

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2019 11:28:09 -0500

>on absolutely everything including, "Let's have lunch."

This is why I have never thought this thing makes sense.  It's just
another bit of unenforcable threatening boilerplate that any sensible
recipient will ignore.  As Jim knows, I've already implemented it in
my MTA with that interpretation in mind.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Feb 2019 11:42:08 -0500

> On Feb 28, 2019, at 11:01 AM, Barry Leiba <[email-masked]> wrote:
> 
> not choose this option on a message-by-message basis.

The primary motivation for "Require TLS = no" is to allow the user
to *resend" a message that is not getting through, or to reach the
destination domain's postmaster because of downstream (receiving
system misconfiguration), to send a message that requires no meaningful
confidentiality.  Individual users are very well positioned to make
that judgement call.  The sending domain's administrator does not
have to support user opt-out, when corporate risk from HIPAA or
similar trumps user preference.

This would not generally be something the user needs to decide
a priori when sending the initial message, it is a failure
fallback option, just like the various options to proceed despite
security issues in browsers, but requiring a new message tagged
appropriately, because delivery failure is asynchronous.

The sender may well be the postmaster of the sending domain, fully
aware of the semantics.

Indeed on my system, I have sender-dependent DANE policy, allowing
one sender address to reach recipients whose TLSA records are stale,
or otherwise broken.  That would be better replaced by the per
message "Require TLS = no".

-- 
-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 09:33:29 -0800

On 2/27/19 2:10 PM, Eric Rescorla wrote:
>
>
> On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <[email-masked]
> <mailto:[email-masked]>> wrote:
>

If I'm reading this correctly, you're concerned about the header field
(don't require TLS even if recipient domain policy says to) rather than
concerned about the REQUIRETLS SMTP extension requiring the use of TLS.
Let me know if this is incorrect.

The preferences we're talking about here (MTA-STS and DANE) are
basically advertisements saying, "if you send mail to this domain, you
should expect to use TLS when doing so." There will always be SMTP
clients that don't implement MTA-STS and DANE (and possibly even
STARTTLS) and will behave exactly as they do today. You described it
correctly as a preference; if the sender wants to emphasize delivery
over security, they can ignore that preference. That's basically what
the header field (RequireTLS: no or perhaps TLS-Required: no) does.

> 1. There might be an active attacker.

Please elaborate on the type of active attacker you are referring to. An
impostor SMTP server? Note that either DNSSEC or MTA-STS is required in
the secure (SMTP extension) case in order to guard against forged MX
records.

> clients which don't speak TLS.

I probably should have labeled it as a non-serious idea. But if the
concern is that someone might override the domain's preferences that
messages be sent via TLS by sending a message without TLS, you can't
talk to clients that don't speak TLS, right?

-Jim

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2019 09:42:31 -0800

On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <[email-masked]> wrote:

> concerned about the REQUIRETLS SMTP extension requiring the use of TLS. Let
> me know if this is incorrect.
>

Yes.

The preferences we're talking about here (MTA-STS and DANE) are basically
> advertisements saying, "if you send mail to this domain, you should expect
> to use TLS when doing so."
>

and "if you recognize this indicator, you should fail if the server doesn't
do TLS", right? Just like HSTS.

There will always be SMTP clients that don't implement MTA-STS and DANE
> (and possibly even STARTTLS) and will behave exactly as they do today.
>
Yes, this is the situation with HSTS as well.

> You described it correctly as a preference; if the sender wants to
> emphasize delivery over security, they can ignore that preference. That's
> basically what the header field (RequireTLS: no or perhaps TLS-Required:
> no) does.
>
Yes, what I am saying is that it's not solely the sender's decision, and
that this is an indicator that privileges the sender's choice of
nonsecurity over the recipient's; of security. Now, arguably, this is a
weakness in the semantics of MTA-STS and DANE in that they could have three
states: insecure OK, secure only, and secure only unless the sender
explicitly says OK, But that's not how they are designed.

> Please elaborate on the type of active attacker you are referring to.
>

A Dolev-Yao/3552 network attacker that controls the entire network.

An impostor SMTP server? Note that either DNSSEC or MTA-STS is required in
> the secure (SMTP extension) case in order to guard against forged MX
Suppose that you are example.com and you want to ensure that anyone who
sends to you uses TLS. Rejecting non-TLS connections doesn't work because
unless the sender enforces TLS, the attacker will just impersonate you,
refuse to negotiate TLS, and then re-connect to you offering TLS.

I probably should have labeled it as a non-serious idea. But if the concern
is that someone might override the domain's preferences that messages be
sent via TLS by sending a message without TLS, you can't talk to clients
that don't speak TLS, right?

See above. The enforcement has to be on the client, just as with HSTS.

-Ekr

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 09:47:20 -0800

> how broadly and quickly this gets deployed.

FWIW, I read EKR's comment differently, that he was concerned about
overriding the recipient domain's preference that TLS be used with the
RequireTLS: no (or perhaps TLS-Required: no) header field. From his
followup message just received, it sounds like that's the case.

WRT your concern above, I expect that problem to be self-correcting.
Sending systems that are configured in this way will learn quickly about
the delivery problems, and correct what is arguably a misconfiguration
of their mail systems. We can't design protocols so that they are free
from the possibility of misconfiguration.

> on absolutely everything including, "Let's have lunch."

Sure, people overclassify stuff all the time. If that isn't working for
people, they won't use those markings to key the use of REQUIRETLS, but
will instead discover what domains they ought to be able to communicate
with via TLS, and use it for those domains.

> While I absolutely see the value in that, I'm not sure how workable it

Isn't that recipient policy MTA-STS or DANE?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 10:35:00 -0800

On 2/28/19 9:42 AM, Eric Rescorla wrote:
>
>
> On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <[email-masked]
>>     On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>     If I'm reading this correctly, you're concerned about the header
>     field (don't require TLS even if recipient domain policy says to)
>     rather than concerned about the REQUIRETLS SMTP extension
>     requiring the use of TLS. Let me know if this is incorrect.
>
>
> Yes.
>
>     basically advertisements saying, "if you send mail to this domain,
>     you should expect to use TLS when doing so."
>
>
> and "if you recognize this indicator, you should fail if the server
> doesn't do TLS", right? Just like HSTS.
>
>     There will always be SMTP clients that don't implement MTA-STS and
>     DANE (and possibly even STARTTLS) and will behave exactly as they
>     do today.
>
>     emphasize delivery over security, they can ignore that preference.
>     That's basically what the header field (RequireTLS: no or perhaps
>     TLS-Required: no) does.
>
> Yes, what I am saying is that it's not solely the sender's decision,
> and that this is an indicator that privileges the sender's choice of
> nonsecurity over the recipient's; of security. Now, arguably, this is
> a weakness in the semantics of MTA-STS and DANE in that they could
> have three states: insecure OK, secure only, and secure only unless
> the sender explicitly says OK, But that's not how they are designed.

That's right, "secure only" is not the semantics of MTA-STS and DANE. So
TLS-Required: no is consistent with those semantics. It might be
interesting to see how MTA-STS and DANE could be extended to have the
other states, but the lack of those states is outside the scope of
TLS-Required: no.

>     An impostor SMTP server? Note that either DNSSEC or MTA-STS is
>     required in the secure (SMTP extension) case in order to guard
>     against forged MX records.
>
> Suppose that you are example.com <http://example.com> and you want to
> ensure that anyone who sends to you uses TLS. Rejecting non-TLS
> connections doesn't work because unless the sender enforces TLS, the
> attacker will just impersonate you, refuse to negotiate TLS, and then
> re-connect to you offering TLS.

Since MTA-STS and DANE do not have a "secure only" state, this is
outside the threat model of those protocols. Adding requirements to
clients implementing TLS-Required (such as that they check for MTA-STS
and DANE [and in turn implement DNSSEC]) doesn't do anything about the
bigger problem with clients who don't implement TLS-Required.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Feb 2019 13:35:54 -0500

> do TLS", right? Just like HSTS.

Thanks for the clarification, I now see how you're arriving at your
position.  The key difference is that you see MTA-STS and DANE as
analogous to HSTS in setting a mandatory security policy for the
client.  But the analogy is crucially imperfect.

    * With browsers, given an "http://" URL or bare domain in the
      browser's address bar, the client either honours that and uses
      an unauthenticated, unencrypted channel, or given HSTS
      unconditionally upgrades to encrypted authenticated HTTPS.

    * With SMTP, there isn't a second email address format for email
      delivery over TLS.  The MTA chooses the best available security
      level opportunistically.  The baseline is cleartext delivery.

    * SMTP upgrades to (unauthenticated) STARTTLS opportunistically,
      when offered by the peer.  Even in the absence of DANE, MTA-STS,
      etc., the sender can and most often does use STARTTLS (~92%
      of the time in/out of Gmail).  Which is sufficient to deal
      with passive monitoring.

    * But active attacks can forge MX replies, strip STARTTLS or
      MiTM the TLS session.

    * What DANE and MTA-STS (after first contact) do is harden the
      peer signal against active attack, *enabling* the sending system
      to negotiate the highest shared security level.

    * Neither *obligates* the sending system to use them without
      exceptions.

    * This is in part because even without either, STARTTLS is then
      typically used, and is often viewed as an adequate compromise
      between security and reliabile delivery.

When sending domain supports outbound DANE (which is further along
the adoption curve than the more recent MTA-STS) it can (and many
do) implement exception lists to deal with remote misconfiguration,
or to for some other local policy reason.  There is conversely also
some use of local mandatory TLS policy, when neither DANE nor MTA-STS
are available.

DANE and MTA-STS describe what a sender must do *when* doing DANE
or MTA-STS, in order to get a result that is (more) resistant to
active downgrade attacks, but they are not mandates.  The sender
can elect to not implement either or both, or to skip either or
both for selected destinations.

Even with MTA-STS or DANE not implemented or disabled, the sender
can still use unauthenticated STARTTLS, or stronger.

All that this draft does is specify a way for the sending system
to give the user some control over the handling of his message,
so that MUAs and downstream relays can recognize the user's
preference and perhaps take it into account.

We should keep in mind that email is often the medium used to
communicate about operational failures.  And that not infrequently,
insecure email is the medium through which more essential security
is brought back into service elsewhere.

Thus, for example, TLSRPT (RFC8460) suggests that reports be sent
even when MTA-STS or DANE fail for the remote destination.

Again, this draft extends the same flexibility to the user, if
supported by the user's MSA and beyond.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Feb 2019 10:39:47 -0800

> my MTA with that interpretation in mind.

I suspect that your implementation has missed a few MUSTs in the
specification :)

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Feb 2019 14:59:06 -0500

> is brought back into service elsewhere.

I think a note by John Callas from a current thread on the Cryptography
list is apt:

    Remember that the rules of infosec are Confidentiality, Integrity,
    and Availability. You don’t want to do something like maximize
    C and minimize A. I’ve heard several stories about people who
    made that mistake and now do not have available the few thousand
    bitcoins they once had.

Keeping also in mind that providers and users are more likely to
adopt technologies that provide C, so long as they can still get A
when needed.  So to maximize confidentiality *in practice* we must
not over-emphasize it to the detriment of availability.

Hop-by-hop transport security in email is in good measure a concession
to the fact that we're (for good reasons) as far as ever from any
broad deployment of end-to-end email encryption, and that hop-by-hop
TLS is the compromise that can reach broad adoption.  The security
specified in DANE and MTA-STS is ultimately only useful if broadly
deployed.  Let's make that deployment easier.

If after some years of broad deployment, all but a negligible number
of operators learn how to operate their MTAs flawlessly, monitoring
and provisioning tools improve etc., and the need for exceptions
goes away, then we can deprecate "TLS-Required: no" (or whatever
the name is in the end) as having served its purpose by easing the
path to adoption in the years prior.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Feb 2019 20:11:20 -0600

> confidentiality.  Individual users are very well positioned to make

If those are the *primary motivation*s, then why does neither "resend" nor
"postmaster" appear in the -07?

-Benjamin

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Feb 2019 21:29:35 -0500

> On Feb 28, 2019, at 9:11 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Well, for me (can't speak for others), it did not seem like an important
detail.  The mechanism is independent of what one might guess to be the
user's most likely motives.  Perhaps these should have been explicit,
but they seemed obvious and inessential. :-(

The idea is that the recipient's promise to have working TLS with either
DANE, MTA-STS or both might not always work out, and so users as well as
MTA administrators might sometimes need a plan B.  The individual user
is generally well placed to make a judgement call about the sensitivity
of his message.

That may not be true for "corporate citizens", but the corporate SMTP
gateway is controlled by the organization, not the user, and is free to
not honour the user's signal, like any signal from remote MTAs, this
signal from the user is input to local policy, not a mandate.

Only "RequireTLS = yes" imposes a clear mandate on conformant MTAs.

-- 
	Viktor.