Comment by kbolino
1 month ago
If you have trusted forwarders, you just add them to the SPF policy (which can be recursive, though there is a pretty low limit on how many records can be looked up). I've not had an issue with this, personally. However, assuming DKIM can be tightened up as proposed above, I'm not sure SPF would be necessary anymore.
There are quite a few problems with that. Biggest issue is that it would require the domain owner's explicit cooperation with each forwarder. It would also allow more than just forwarding existing letters. Real-life shows that SPF really doesn't work with forwarders and it probably never will.
What does forwarder mean to you here? Because, from my perspective, a forwarder that I don't trust--or even know about--should not be allowed to deliver legitimate-looking mail from my domain. DKIM alone is weak to replay and payload extension so I don't think, as it stands right now, it is sufficient on its own.
So it seems, to me, that SPF is working exactly as it ought to. Just to be clear, this isn't pure theory or ignorant preference on my part, I've set up SPF for trusted forwarders before.
Yes, they should be able to deliver such email. Forwarding messages is absolutely vital for a lot of use-cases, starting from trivial one-to-one forwards but also mailing lists. DKIM signatures can also expire and length extension attacks are not possible unless both the signer and assessor are badly configured. In any case a theoretical replay is significantly less dangerous than unauthorised mail being sent because of SPF's inherit looseness.
In the end once the letter has left your server, it is _not_ up to you to decide what they do with it. We already have ARC to basically bypass SPF when DKIM is missing. Letters _will_ be forwarded.
SPF is obsolete and weak in other ways as well. A mere IP address is not the proper way to authenticate or authorize anything.
5 replies →