On Mon 16/Sep/2024 16:59:13 +0200 Todd Herr wrote:
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.
I'd prefer to note misalignment rather than explaining why SPF fail. That is,
having the last five lines above replaced by the following four:
NEW
most likely fail SPF checks unless the RFC5321.MailFrom address is
rewritten by the relaying MTA, in which case it will not any more
be aligned with RFC5832.From. DKIM signatures will generally
remain valid and aligned in these relay situations.
However, I understand this looks like personal taste. I can as well accept the
current text as quoted above.
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.MailFrom is present and the forwarder maintains the
original 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.MailFrom
with its own domain, SPF might pass, but Identifier Alignment with
the RFC5322.From header field will fail.
https://datatracker.ietf.org/doc/html/rfc7960#section-2.2
Agreed. It's actually better than both versions above, albeit a bit longer.
How about quoting it, instead?
so can we please just call this good and move on?
As you see fit.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
