> On Nov 19, 2017, at 4:52 AM, Bron Gondwana <[email protected]> wrote:
>
> That said, I could see sites deploying NO support without deploying YES,
> since YES requires you to to ensure that your downstreams are at least
> claiming to play ball. So that's an argument for either two separate
> documents or the spec saying that it's legitimate to implement NO only. It's
> less important how many documents are produced than the ability for sites to
> offer NO without YES.
I think that a single specification in no way obligates
anyone to implement all its features, a site could implement
any of the four possibilities regardless of the number of
documents the IETF publishes in this space. A single
specification is IMHO simpler, since it concerns the
same security policy issue:
* Whether to deliver despite lack of a secure channel
The "REQUIRETLS=YES" case says "stop" and asks the nexthop
to do likewise both via out-of-band (ESMTP) and in-band
(header) signalling.
The "REQUIRETLS=NO" case says "go", and asks the nexthop
to do likewise just via in-band (header) signalling.
The header should I think be a common header, and the
same considerations apply wrt. "Resent" and "List"
messages. That is, if the header is normally:
TLS-Required: Yes|No
Then in a resent message (that has a Resent-From or
a Resent-Message-Id header) the above header is ignored
and any TLS policy override would need to be:
Resent-TLS-Required: Yes|No
and in a list message (that has a List-Id header) any
override would have to be a "List-TLS-Required" header.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
