Re: [dmarc-ietf] Tree Walk impact
On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote: On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely wrote: On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote: Both approaches have problems. Stop-at-last enables the walk to exit the current organization and stop on a private registry, for both alignment evaluation and for aggregate report transmission. This is not a minor problem, even if it is arguably infrequent. The illustrative example in the draft says: _dmarc.a.b.c.d.e.mail.example.com _dmarc.e.mail.example.com _dmarc.mail.example.com _dmarc.example.com _dmarc.com That is, no stop at all. In this respect, a psd=n at example.com would save a lookup. However, it is not something that we can recommend, after we chose the obscure tag name. > I'm not sure I understand what you're saying... The illustrative example cited is intended to illustrate a full tree walk that follows the steps for a full tree walk that are spelled out in the numbered list just prior to the illustrative example. Yup, I'm not criticizing the text (I wouldn't know how to better it). Just wondering how to implement it. It is understood that programs must behave /as if/ they followed the letter of the spec, but don't have to actually do so. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree Walk impact
On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely wrote: > On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote: > > Both approaches have problems. Stop-at-last enables the walk to exit > the > > current organization and stop on a private registry, for both alignment > > evaluation and for aggregate report transmission. This is not a minor > > problem, even if it is arguably infrequent. > > > The illustrative example in the draft says: > > _dmarc.a.b.c.d.e.mail.example.com > _dmarc.e.mail.example.com > _dmarc.mail.example.com > _dmarc.example.com > _dmarc.com > > That is, no stop at all. In this respect, a psd=n at example.com would > save a > lookup. However, it is not something that we can recommend, after we > chose the > obscure tag name. > > I'm not sure I understand what you're saying... The illustrative example cited is intended to illustrate a full tree walk that follows the steps for a full tree walk that are spelled out in the numbered list just prior to the illustrative example. That numbered list includes conditional stops (i.e., if one record is found with the specified condition, stop) in steps 2 and 7. -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* todd.h...@valimail.com *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree Walk impact
On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote: Both approaches have problems. Stop-at-last enables the walk to exit the current organization and stop on a private registry, for both alignment evaluation and for aggregate report transmission. This is not a minor problem, even if it is arguably infrequent. The illustrative example in the draft says: _dmarc.a.b.c.d.e.mail.example.com _dmarc.e.mail.example.com _dmarc.mail.example.com _dmarc.example.com _dmarc.com That is, no stop at all. In this respect, a psd=n at example.com would save a lookup. However, it is not something that we can recommend, after we chose the obscure tag name. For implementation, it might be faster and politer to lookup .com in the strict PSL (ICANN domains) than querying _dmarc.com. If you have a dedicated caching DNS, .com SOA min TTL is 86400, so the empty _dmarc.com stays there for the whole day and the local DNS might be quicker. Yet, I'd keep comparing with the PSL, at least for an initial period. Certainly one is not going to re-start the tree walk from scratch for each authorizing domain. I'll try coding that in the next but one zdkimfilter release. (Will that still be before DMARCbis publication?) Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
