[dmarc-ietf] Re: DMARCbis version -33 is ready for document shepherd and AD processing

[Todd Herr <[e-mail]>]

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 [e-mail] (an address that relays

the messages to another address with a real mailbox) or

[e-mail] (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 <[e-mail]> 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.
> --
> [e-mail]
>
> _______________________________________________
> dmarc mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Todd Herr | Technical Director, Standards & Ecosystem
Email: [e-mail]
Phone: [phone]


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.