On Tue 10/Sep/2024 19:08:47 +0200 Scott Kitterman wrote:
On September 10, 2024 4:59:08 PM UTC, Steven M Jones <[email protected]> wrote:
On 9/10/24 5:06 AM, Scott Kitterman wrote:
On September 10, 2024 10:20:59 AM UTC, Alessandro Vesely<[email protected]> wrote:
Hmm... there are relays that don't change the bounce address. For such cases, the
explanation of why SPF checks fail would be different... I'd suggest removing the
explanation (that is ", as the incoming ... the sending domain"). It should be
well known by now that SPF breaks forwarding.
I don't think it's safe to assume people know this. I do think the point is
worth addressing. Perhaps adding (if the Mail From address is not rewritten by
the relay) after necessarily fail SPF checks would address the point.
I agree that generally, if there's anyplace we should favor being more explicit
than implicit, it's an IETF specification document.
Is a parenthetical like this too disruptive to the flow of the text?
When such mail is delivered to the actual recipient mailbox it will fail SPF
checks (provided the rfc5321.MailFrom was not altered), as the sending IP
address will be that of example.edu or association.example, and not an address
authorized for the sending domain.
Looks good to me.
To me not much. "provided the rfc5321.MailFrom was not altered" selects a part
of forwarding. What if it was altered? If we want to be more explicit than
implicit, we have to explain why the check likely fails in each case.
BTW, some forwarding sites have liberal SPF records, such as:
"v=spf1 ip4:0.0.0.0/1 ip4:128.0.0.0/1 ip6:0::/1 ip6:8000::/1 +all",
which allow alumni to send out from their current MSA using their alias.
In such case, for recipients having using a vanity address too, forwarding
might pass the check.
There are several sites that provide deeper analyses than that. Perhaps we're
better off citing one of them?
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
