On 10/13/2017 10:54 AM, John Levine wrote:
SRS is one of those magic bullets that might have worked if everyone in the world implemented it at the same time, and the design were written by someone who understood the security issues.
Would you please elaborate on (or point me to existing documentation) on the security issues that you're referring to?
In the real world, any change to e-mail is implemented gradually, so you have to be prepared for the old way and new way to work in parallel for a long time.
Agreed.
So if you have to be prepared to ignore overenthusiastic SPF -all anyway, who needs SRS?
Maybe it's just me, but I've never felt the desire to ignore overenthusiastic SPF. Rather I've always been more of the opinion to push back and have the (purported) sending domain adjust their SPF record or persuade the forwarder to use something like SRS.
I feel that if a sending domain sets "-all" they (hypothetically) know what they are doing and that they do in fact want me to treat things that fail SPF as spam. - Or the first few failed deliveries turns into a learning opportunity for the sending domain and they adjust their policy.
There's no technical way to tell an incoming message with a real rewritten SRS address from one with a fake SRS address intended to make spam look less spammy, other than by checking against a whitelist of known virtuous forwarders.
What's wrong with using SPF to filter fake messages coming from an invalid source? I.e. -all on the SRS domain. (I typically have each MTA use it's hostname as the SRS domain and publish an SPF record for the host that only allows it to send messages from it's name.)
But if you have that whitelist, you don't need SRS, you just skip the SPF check on mail from those forwarders. (Gmail approximately does that.)
I've never felt the need for such a white list. - Maybe it's the nature of my small mail server having different use cases compared to the bigger players.
The other problem that SRS is supposed to fix, forwarding back bounce messages, barely exists any more. Due to the floods of spam with forged return addresses, bounce messages are now mostly reflected spam going back to someone who didn't send the message in the first place. MTAs (other than those written in Redmond WA) try hard to reject undeliverable mail during the initial SMTP session rather than accept and bounce.
I agree that's how things should be. Sadly, I still see people not doing so, and sending bounces after the fact.
The comment about some rule against changing bounce addresses is wrong. Every mailing list rewrites the bounce address on mail it forwards. That makes sense for lists, since they need to handle subscriber bounces, not the person who originally sent the message.
I assume you're referring to Hector's comment about the "Return Path (5321.MailFrom)" being sacrosanct.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
