If I understand Mark correctly, his data indicates that DNS works great unless you are:
- dependent on Microsoft as a DNS client to submit the query or - dependent on Microsoft as a DNS server to respond to the query. Sadly, that is a lot of dependent traffic. On Mon, Nov 4, 2024 at 7:18 PM Mark Alley <mark.alley= [email protected]> wrote: > Just sharing on the topic of authentication, DNS, and temperrors - I have > recent statistics timeline (attached) involving DKIM failure rates for a > high volume of mail for $dayjob that directly correlates the effect of TTLs > and caching on temperrors and authentication (with Microsoft being an > anomaly in this dataset). This volume in total roughly accounts for 738k > DKIM failures out of 695.5m emails over 30 days, which is about a 0.1% DKIM > failure rate overall. > > Splitting the failures up by reporter, Microsoft currently is the > overwhelming offender when it comes to temperrors, by magnitudes of several > thousands of percentage points, compared to all other receivers combined. > Even increasing TTLs inordinately high had barely any effect on Microsoft's > DNS errors. All other reporters fell off a cliff once the DKIM TTLs were at > 24 hours. > > This also seems to apply to SPF as well. > > - Mark Alley > On 11/4/2024 5:31 PM, Douglas Foster wrote: > > Surprisingly, for email, DNS errors are not rare. I have been collecting > data from three sources: > > - The incoming messages to my server > - The Aggregate Report data about messages that came from me or appear to > come from me, and > - The Authentication Results header fields on incoming messages, which is > evaluated by unrelated servers about other unrelated domains. > > In each case, my TempError rate is 1 in 350 messages or higher. I > expected something on the order of 1 in a million or 1 in a billion. > > I don't understand why the error rates are so high. I may undertake a > study to determine what percentage of TempErrors are transient events and > what percentage are highly repeatable events, but I have not done so yet.. > Perhaps Google or someone else can contribute some insight. > > Doug Foster > > > > > On Sun, Nov 3, 2024 at 1:29 PM Alessandro Vesely <[email protected]> wrote: > >> On Sun 03/Nov/2024 13:56:42 +0100 Douglas Foster wrote: >> > The other problem is that the Tree Walk makes the entire document >> > experimental. Tree Walk is a great tool for batch-mode detection >> of >> > PSL errors, but it has multiple problems as a real-time tool. >> > >> > - It disables best-guess DMARC based on default policy. Instead of >> > disabling best-guess DMARC, this document should be embracing it. >> >> >> Best-guess DMARC can be a local filtering method, but it's not being >> standardized. Using the Tree Walk doesn't preclude to use the PSL for >> any >> local intent. >> >> >> > - It is prone to inconsistent results and indeterminate results >> caused >> > by DNS errors. >> >> >> On a well supplied server, DNS errors are quite rare. An error >> retrieving >> DMARC records, which can happen also when the org domain is discovered by >> PSL, >> deserves a 4xx temporary error. >> >> >> > - Multiple DNS lookups are reasonably expected to have lower >> performance >> > than one database lookup, especially since high-throughput >> environments can >> > use memory-resident databases for the PSL lookup. >> >> >> All the involved domains can be queried in one shot. That way the time >> required is about the same as querying a single record. >> >> >> > - Inconsistent results can be mitigated by using long-term caching >> > outside of DNS, but that adds complexity and overhead. >> >> >> Agreed. It is much better to deploy a dedicated DNS server. >> >> >> > [...] >> > >> > In aggregate, I see no justification for DMARCbis to be given Standards >> > Track status, unless the Tree Walk is separated out as an experimental >> > option, either in an appendix or in a separate document. >> >> >> Using the PSL was the experiment. Standardization provides a >> better-defined >> method by which a domain owner can decide which domains are >> "organizational" >> without having to seek help from a vaguely defined group that maintains a >> list >> designed for a different purpose. >> >> I don't think experimental status is required for that. Anyway, that is >> to be >> decided by the IESG or the RFC-Editor, methinks. Our charter says: >> >> The task of defining a standard mechanism for identifying >> organizational >> domain is out of scope for this working group. However the working >> group >> can consider extending the base DMARC specification to accommodate >> such a >> standard, should it be developed during the life of this working >> group. >> >> >> Best >> Ale >> -- >> >> >> >> _______________________________________________ >> dmarc mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
