>> 1. Company has lots of MTAs, collect statistics to see which ones >> are misconfigured in preparation for publishing policy statements.
>> For items 1 and 2, the ESMTP extension won't work, since the MTAs as >> likely as not won't have it. >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, ... >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. >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. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
