Hi Tim, The I-D linked below provides for yes, no (not signed), or na (for not applicable). The expired case should perhaps map to "no"? The lookup only sets an AD bit...
Best Ale On Mon 21/Oct/2019 19:49:03 +0200 Tim Wicinski wrote: > > Alessandro > > There are a couple of different combinations of dnssec valid/invalid/expired > you would want to account for. > > Tim > > > On Mon, Oct 21, 2019 at 10:54 AM Alessandro Vesely <[email protected] > <mailto:[email protected]>> wrote: > > On Wed 07/Aug/2019 17:16:29 +0200 Murray S. Kucherawy wrote: > > > >> If the definition of ptype smtp were "a parameter of the SMTP session > used > >> to relay the message" it would be perfect. I'd propose that > policy.iprev > >> be deprecated and smtp.remote-ip used instead>> > > > > Given that RFC8601 was published just last month, it'll probably be a > while > > before this happens. > > > Wouldn't an accepted erratum be enough to change the wording in the IANA > page? > > > About the new ptype, a reviewer suggested to also use it to report > whether the > query supported DNSSEC. No DNSWL that I know supports it. However, I > know > some DKIM filters report that feature either as a comment or as a reason > in the > dkim= methodspec. Using the new ptype might make that clearer. Consider: > > Authentication-Results: example.com <http://example.com>; > dkim=pass dns.sec=yes [email protected] <http://example.org> > header.b=j5aQ3SJv > > What you think? > > https://tools.ietf.org/html/draft-vesely-authmethod-dnswl-11#section-2 > > > Best > Ale > -- > > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
