> On May 1, 2016, at 8:53 PM, John Levine <[email protected]> wrote:
>
> One of the reasons DMARC reports are useful is that large domains
> often don't know where all their mail servers are.
Yes, often true for outbound mail, where various internal teams
operate or outsource some specialized email flow.
This does not apply to inbound mail. They'd better know where
their inbound mail servers are, their names and IP addresses are
listed in the MX records, and matching certificates have to be
provisioned and kept up to date.
Inbound and outbound email are very different problem spaces.
> More often than not the
> reports go to a third party like Agari who does the crunching.
Would that still make sense for inbound TLS reporting? I'm
somewhat skeptical.
> Also, it would operationally be a terrible idea to demand that a
> provider make software changes to every single one of its mail servers
> just to collect a few statistics about how their TLS is working.
There's no need to modify every server. Just as many of the inbound
servers as one wants to modify for a representative sample of the
traffic. If a bunch of servers behind a load-balancer have the same
configuration (there may a few such bunches behind a single VIP) then
enabling reporting at one or two of them will quickly yield
representative data through the law of large numbers.
Ultimately, one would roll out support for the hypothetical SMTP verb
across the board.
The key thing to keep in mind is that reporting is a favour that sending
systems are willing to perform for receiving systems. Therefore, it is
more important that reporting be simple for sending systems.
If reporting is too complex on the client side, it might not happen at all.
Also there need not be just one way to do reporting. The in-band proposal
is just one way to it synchronously, without needing to accumulate aggregate
state on the client, and in a manner that works well when delivery ultimately
succeeds with a second MX host after failing on the first.
There can also be an aggregate asynchronous channel. Clients would choose
whichever works best for them.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
