Heho, On Tue, 2023-02-28 at 22:21 -0500, John Levine wrote: > We briefly considered that and decided against it because the vast > majority of actual DMARC records will continue to work unchanged, and > long experience says that if you try to change the version number, > you end up living with the old and new versions forever. Yeah; Maybe it's time for an RFC for next month only containing "All IETF created protocols MUST not have a numbered version indicator." (This is (only partially) joking; But i somehow feel like there will never be DKIMv2, STSv2, or TLSRPTv2 ;-))
> Remember that unknown tags are now ignored. In practice pct turned > out to be impossible to implement so most people didn't try. The > required->recommended for p= is to make it consistent with the > _report._dmarc records in section 7.1 of RFC 7489. Hm, yeah, and introduced tags should not be an issue as per 7489 already. Still, i am a bit wondering; Looking at the data flushed in so far (and already multiple bugs filed against implementations)... there are a lot of funny milters and often unmaintained software integrated in funny docker stacks (probably preaching to the choir there, but i have a lot of grievances with those setups), and generally a lot of awry things (example.com. IN TXT "v=spf1 include:example.com -all" is, for example, far more common than i'd have ever believed...). Then again, considering how bad _my_ code usually is... i am not too sure how well many of those libs hold up towards change. Point being, it might be interesting to conduct a structured study into how different implementations in different versions handle DMARC policies with different levels of 'errors' to inform this. I have a colleague who might still have a lab-setup of implementations around, to see if they could quickly do that. With that information, i could then also provide a better score for DMARC parsing, i.e., make a statement on like "current policy would validate in $list_of_common_implementations but not in $hopefully_short_list_of_other_implementations". With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
