My current working copy of the document has these two paragraphs: As discussed in "Interoperability Issues between DMARC and Indirect
Email Flows" [@!RFC7960], use of p=reject can be incompatible with and cause interoperability problems to indirect message flows such as "alumni forwarders", role-based email aliases, and mailing lists across the Internet. As an example of this, a bank might send only targeted messages to account holders. Those account holders might have given their bank addresses such as [email protected] (an address that relays the messages to another address with a real mailbox) or [email protected] (a role-based address that does similar relaying for the current head of finance at the association). When such mail is delivered to the actual recipient mailbox, it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA, as the incoming IP address will be that of example.edu or association.example, and not an IP address authorized the originating RFC5321.MailFrom domain. DKIM signatures will generally remain valid in these relay situations. and I believe that the referenced RFC (RFC 7960) does a pretty good job of describing why forwarding might cause issues with DMARC and SPF here: If the RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom is present and the forwarder maintains the original RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. If the forwarder replaces the RFC5321 <https://datatracker.ietf.org/doc/html/rfc5321>.MailFrom with its own domain, SPF might pass, but Identifier Alignment with the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From header field will fail. https://datatracker.ietf.org/doc/html/rfc7960#section-2.2 so can we please just call this good and move on? On Fri, Sep 13, 2024 at 12:07 PM Tero Kivinen <[email protected]> wrote: > Alessandro Vesely writes: > > I googled a bit on that but didn't find a satisfactory analysis. There > are > > several good files, e.g. http://www.open-spf.org/whitepaper.pdf or > > > https://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Forwarding_BP.pdf > . > > M3AAWG is just now in process of updating that Email forwarding best > practice. There should be new version published in few months. > -- > [email protected] > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Todd Herr | Technical Director, Standards & Ecosystem Email: [email protected] Phone: 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 -- [email protected] To unsubscribe send an email to [email protected]
