On Saturday, February 19, 2022 12:47:33 PM EST John R Levine wrote: > >> Um, surely you've been around long enough to know that "transition > >> period" > >> means "forever". > > > > Yes, if the PSL lasts forever. > > No, if old DMARC verifiers last forever, which they will. For example, we > published the RFC 8463 about new DKIM signatures four years ago. How many > ed25519 signatures do you see? > > >> Just treat the first DMARC record you find in an upward walk as an org. > >> It > >> seems to me that will get the desired result at least as often as the PSL > >> does, and does not require an incompatible flag or a forever period. > > > > To me, it seems you get the right result more often if you take the last > > (topmost) DMARC record found. Didn't we have some numbers on that? > > I don't remember, perhaps someone else can remind us. In the situation > Mike's been warning about, the topmost record fails dangerously.
As I understand it, yes, but I don't 100% agree that it's a protocol problem. Typically if a company you have hired to do a job does so poorly, then you hire someone else. I don't think it's possible to write protocol to avoid problems like this entirely. To jump back to your us.com example: > ... customer cust.us.com > > _dmarc.com NXDOMAIN > _dmarc.us.com something (it has an MX) > _dmarc.cust.us.com something (it also has an MX) > _dmarc.sales.cust.us.com NXDOMAIN Using the RFC 7489/PSL approach, the org domain is cust.us.com (PSL domain [us.com] plus one label). Walking up the tree one would look for DMARC records in: _dmarc.sales.cust.us.com _dmarc.cust.us.com and then potentially: _dmarc.us.com _dmarc.com If us.com had published a DMARC record with psd=y, then we would know for sure that cust.us.com is the org domain. I think when walking up you want the first record for policy domain and the last non-PSD record for org domain. In your example both the first DMARC record and the org domain are the same, but imagine that later cust.us.com decided that for their sales subdomain they needed a different handling policy, so a new DMARC record appears at _dmarc.sales.cust.us.com. If we take the first DMARC record as the org domain, then it changes from cust.us.com to sales.cust.us.com. If they had been using dkim.cust.us.com it would suddenly fail to align. I think this would be a very surprising property of the system and not really what we are after. On the other hand, if you walk up starting with the 5322.From domain to find policy and walk down to find the org domain, stopping at the first, non-psd=y domain you find, I think it works better: _dmarc.com _dmarc.us.com _dmarc.cust.us.com Making changes below the org level no longer affects which domain is the org domain. I do think that an exact match should always be used. For example, let's imagine the operators of us.com decide to use it in email for their own email and publish a DMARC record, but they use psd=y so as to not disturb the alignment of their customer's mail. When looking for the policy domain for a message with 5322.From of us.com, first _dmarc.us.com is looked up and a record is found, so that is the policy record. Then the org domain is identified: _dmarc.com _dmarc.us.com A record is found and even though it's got psd=y, it's the org domain because us.com is the 5322.From domain. I think walk-up for policy and walk down for org yields less surprising results and will more consistently emulate the non-error results from the current PSL based approach (in RFC 7489 domains between the exact domain and the org domain are ignored, walking down the tree would also preserve that property of the existing system). The only "new" requirement it imposes is for the org domain to have a DMARC record. There may be a non-zero number of domains that don't have one now, but I think it will be exceedingly rare. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
