On Tue, May 10, 2016 at 10:07:06AM -0700, Chris Newman wrote:
> > I'm not suggesting that out-of-band reporting should not also be
> > specified. Let's also specify in-band reporting.
>
> The MUA STS (aka DEEP) specification already has in-band reporting for
> SMTP Submission. We could extend that model for SMTP relay. How closely
> does that approach match to what you�re thinking about?
Yes, the
CLIENT latch-fail <security-tag>
(some places in your draft appear to use "latch-failure").
command is related in spirit to what I'm thinking of, but the
specific set of "security-tag" values is not quite as detailed as
I would hope for.
You have "tls10", "tls12", "tls-cert" and "tls-dane-tlsa".
I am more inclined to separate the mechanism and send
more detail along the lines of:
* Sent in clear, (can be pipelined with QUIT when peer
supports PIPELINING):
TLSSTATUS (STS|DANE|...) NOSTARTTLS <CRLF> [ QUIT <CRLF> ]
* Sent over unauthenticated TLS (can be pipelined with QUIT
when peer supports PIPELINING):
TLSSTATUS DANE NOTRUST <tlsa-base-domain (source of policy)
TLSSTATUS STS NOTRUST <nexthop-domain> (source of policy)
TLSSTATUS (STS|DANE) EXPIRED <mxhostname> (SNI/MX hostname)
TLSSTATUS (STS|DANE) NOMATCH <mxhostname> (SNI/MX hostname)
* Either cleartext or over TLS as applicable when attempting
to use a "backup" MX host when primary fails authentication
and was skipped:
TLSSTATUS (STS|DANE) BACKUP <nexthop-domain> <primary-mx-skipped>
That way if the primary is messed up and unmonitored, the signal
may get through via the backup, and the backup administrator will
know why they are suddenly getting the traffic.
The idea is to give the administrator of the receiving system a
concise, but actionable, indication of what's wrong, even when the
MX host supports multiple domains and perhaps multiple cert chains
via SNI, only some of which have issues.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
