Fwiiw, Lurker opinion: I ideally vote to make DMARCBis Experimental Status and begin to explore the “required” integration between envelope (5321 only) protocols and payload (5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling with 3rd party signature support.
But realistically, we should finish DMARCBis as is, as Levine desires. However, imto, keeping it a Standard Track will increase the ignorance. I don’t see any new gains for current my package implementation. At best, the industry is acknowledging a big integration problem. Domains who can’ get past sending mail the large Mall Hosting domains and managed domains DMARC processing are learning to relax their policies. PS: I don’t plan any appeal <g> — HLS > On Oct 28, 2023, at 12:49 PM, Murray S. Kucherawy <superu...@gmail.com> wrote: > > On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton <rich...@highwayman.com > <mailto:rich...@highwayman.com>> wrote: >> Paying attention to the (sometimes inferred) age of a signature is also >> important for reducing the opportunity for replay, viz: it would be a >> Good Thing for senders to set appropriately short expire times. > > Why does it have to be inferred sometimes? Have you found "t=" values to be > occasionally inaccurate? > > The DKIM standard advises against using "x=" to combat replay attacks. We > could always update that advice, but we might also want to review why it was > put there in the first place. I remember the reason being a good one. > > I think there's also been discussion around the reliability of "x=" across > implementations. Since it's not mandatory to support, it doesn't seem to be > very common to produce without the expectation of consumers. > > -MSK, participating > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
