On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote: > (Note, here, that Barry has in his proposed text limited the constraint to > those types of deployments where the damage is likely. I concur. DMARC, > as currently defined, works just fine when deployed in transactional > situations. Or, at least, I haven't seen that identified as a problem > case.)
I have been trying to point out a problem in even for transactional messages. Some receive-side forwarders that people use break DKIM signatures, and of course break SPF. So a transactional message sent to a forwarded address might be rejected if the address to which it is forwarded enforces DMARC. IMO, receive-side forwarding is an important use case. It allows people to maintain a consistent email address if they change mail providers. For people whose email provider is their ISP, that keeps them from being locked into that ISP. It’s possible that this might be solved if the forwarder implements ARC, but only if the address to which it is forwarded knows how to implement ARC. I suspect that many DMARC enforcers currently don’t. -Jim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
