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]
