On Fri, May 06, 2016 at 11:01:00PM -0000, John Levine wrote:
> >That's not a fair objection, they would have to deploy upgraded
> >MTAs that support the new extension, just as would deploy MTAs that
> >support DANE or STS to enjoy the benefits of those (yes at present
> >upgrades are only needed for outbound support).
>
> No kidding. The point of the reports is to find the MTAs that haven't
> been upgraded so they can fix them. When you have a giant server
> farm, you can't upgrade everything at once, so you do rolling upgrades
> and sometimes you miss a few or the upgrades fail. If you depend on
> the upgrades succeeding to get reports that tell you that the upgrades
> failed, well, ...
The key observation on that point is that failures to support
authentication properly behave very differently from DMARC.
When an MTA is misconfigured, if reports are sent in real-time via
email, every remote site that connects to the broken MTA will
generate a new email generating a notification flood. This is
much less likely to happen with DMARC.
Notifying the MTA via ESMTP extension one-liners in-band makes it
possible for the receiving MTA to efficiently consolidate the
reports without doubling the traffic load or routing as much email
to the report mailbox as to all other recipients combined.
I should point out I the providers with large hosting mail farms
are not the problem we need to worry about. Frankly, they can
damn-well quite effectively monitor themselves! It is the long
tail of much smaller domains where SMTP transport security needs
an effective alerting channel.
Many small to medium site MTAs don't have a dedicated operations
team. I can easily add a bit of code of Postfix to send them
intermitten reminder alerts every 30 minutes in which the fraction
of authentication failures alerts exceeds some threshold. They
would then benefit from automated monitoring by the wold at large,
and would not have to *publish* an email address for collecting
reports or configure scripts to process them... The (as yet
skeletal) design satisfies KISS.
> >That's false. The most common misconfigurations are untrusted,
> >expired, non-matching or incomplete certificate chains, followed
> >by selectively enabled STARTTLS (perhaps based on client reputation,
> >...).
>
> In some environments, sure. In other environments, nope. I'd prefer
> to use a reporting design that works in as many places as possible
> rather than only on the mistakes I expect.
I think we're looking at two different problem sets, both of which
may need solutions. Clearly, we disagree or their relative
importance, or simply on which one we personally wish to expend
precious mental cycles.
> >If aggregate reporting is the only nail, then the email reporting
> >hammer is the only/primary tool needed in the tool-belt.
>
> I have a folder of 55,000 individual DMARC failure reports, most sent
> and received within a couple of seconds of when the failure was
> detected. (That's separate from the folder of 90,000 aggregate
> reports.) It really is not helpful to claim that it is inherently
> hard or slow to mail failure reports.
I posit that inbound TLS auth does not behave sufficiently similarly
to DMARC to support a completely analogous design.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
