In article <6a14ffbc-d704-b168-c5f4-6b971d48d...@tnetconsulting.net> you write: >On 10/08/2017 08:29 PM, John Levine wrote: >> * There is a kludge called SRS that embeds the original bounce address >> in the forwarder's bounce address, but it doesn't help. > >Where can I find out more about how / why SRS does not help.
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. 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. So if you have to be prepared to ignore overenthusiastic SPF -all anyway, who needs SRS? 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. 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.) 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. 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. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc