Seth Goodman wrote:
When you mention that SRS solves this problem, it only does so if _all_
forwarders implement SRS. Until that happens, and from a practical
standpoint, it is extremely unlikely that everyone will implement anything,
you still have to whitelist some forwarders and you will receive forged
bounce spam through those channels.
If my forwarder doesn't implement SRS, as a SPF filtering recipient, I won't
get any forwards from them. If I send to someone who is an SPF filtering
recipient through a forwarder, I'll get a bounce from an email I sent. I
certainly won't receive "forged bounce spam".
You are also forgetting the response to
Meng's question about dropping SRS. There was an immediate, resounding
affirmative response. The comments made it clear that most people
considered SRS as overly complicated, too different from existing practice
and a hindrance to adoption.
Don't be silly. The only reason we (myself included) said we wanted to drop SRS
is because no one likes email address munging. The implication was that there
was a good alternative to SRS that was just as secure. The alternative proposed
was SUBMITTER, which would help protect from phishing. Unfortunately, SUBMITTER
is very exploitable (forged bounces), and it has questionable usefulness for
protecting from phishing.
I argue that the SES+SUBMITTER (or better yet, SES+reverse source route) is
an equivalent solution that is much simpler, is interoperable with legacy
systems and doesn't require the whole world to cooperate.
How could SES possibly be better or more popular than SRS? It involves email
address munging (which everyone hates), AND it requires modification to all
originators, not just the forwarders!
SES+SUBMITTER? This is laughable. Great, let's add email address munging and
SMTP extensions! This will require major modifications to originators,
forwarders, and receivers! Plus, we will STILL be vulnerable to bounce forging!
SES+RSR? This is barely better. You can pretend that because RSR is depreciated
that it isn't a modification to SMTP, but unless you implement RSR very
uniformly (which it isn't), it will be vulnerable to forged mail injection. At
least it doesn't require major modifications to the receiver... Of course,
since SPF is required on the receiver, that's one of the best places to include
modifications. Oh, and lest I forget, we will STILL be vulnerable to bounce
forging!
Michael R. Brumm