> On Dec 7, 2016, at 4:33 AM, Jeremy Harris <[email protected]> wrote:
>
>
> I disagree. If that is a need, it should be a separate specification.
> Otherwise we bikeshed REQUIRETLS to death.
I don't see how extending the specification to cover both of the
complementary behaviours brings "bikeshedding" into the picture.
All that happens is that instead the submission phase options
extend from binary (default behaviour, or require TLS) to ternary,
(default behaviour, require TLS, or permit insecure), where the
last option delivers in the clear and/or without authentication,
when authenticated TLS would otherwise be indicated by DANE or
similar policy.
The receiving MTA would advertise a single ESMTP capability
(let's say "USETLS" rather than "REQUIRETLS") to support
both non-default behaviours. The client would then send
either:
MAIL FROM:<sender> USETLS=[MAY|MUST]
where "MUST" is the current "REQUIRETLS" proposal, and
"MAY" is the converse that makes TLS optional even in
the face of contrary security policy.
Administrators can disable either or both options, if
contrary to site policy, in which case the client's
message must be refused at either the "MAIL TO",
"RCPT FROM" or "DATA" commands with a suitable new
DSN status code.
Adding a second, essentially identical ESMTP capability
(flip side of per-message TLS policy), and writing a mostly
identical converse draft seems silly.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
