> On Feb 28, 2019, at 11:01 AM, Barry Leiba <barryle...@computer.org> wrote:
>
> 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.
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.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
