From: Michael R. Brumm
Sent: Sunday, June 06, 2004 4:04 PM
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".
Here is a forged bounce spam that your SPF compliant MTA will accept as long
the sending machine's HELO FQDN passes SPF:
MAIL FROM:<>
RCPT TO:<me(_at_)michaelbrumm(_dot_)com>
This could come from the spammer directly, or result from sending mail to a
non-existent user at another domain.
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.
There were a lot of more potent reasons for people to be so delighted with
the opportunity to drop SRS. It required adoption at all forwarders to be
useful. If you wanted to use a forwarder that did not do SRS, you would
have to whitelist them and produce an open spam channel. The likelihood of
getting all major forwarders to do this seemed slim. And even if they did,
no one would get protection from the forged bounce spam that I showed you
above.
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!
It's hard to imagine anything more unpopular than SRS. Not everyone hates
adding something to email addresses, especially if they are only in the
return path where nobody sees them. No one is forcing any originator to
adopt SES. They should only do so if they want to reject forged bounce spam
before DATA.
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!
You can forge a forwarded mail from a bogus originator that will pass
through either an SPF+SES system or an SPF+SRS system. In both cases, you
will have to use a machine that passes SPF tests, which means a registered
domain and a published SPF record. Similarly, you can spam directly from
that domain with either system. SPF doesn't stop you from creating forged
forwards or from direct spamming. It just makes your identity verifiable so
you can be held accountable.
--
Seth Goodman