-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David
Woodhouse
Sent: Tuesday, December 07, 2004 1:19 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: RFC 2821 and responsibility for
forwarding
On Tue, 2004-12-07 at 12:46 -0500, terry(_at_)ashtonwoodshomes(_dot_)com
wrote:
Forget about SRS, there are some serious problems with it: even Meng
has admitted to such.
It doesn't matter if SRS is deprecated by Meng; the attacker can still
use something which looks like SRS in order to inject fake messages of
the type I showed, surely?
Provided that the receiving MTA is foolish enough to trust headers that can
obviously be forged.
Please refute the argument with more recent and seemingly better SES
solution.
I don't see SES documented on spf.pobox.com. Perhaps the council can
address that omission, if people really see SES as a successor to SRS?
And so it should. There are many things I think Meng should have done, that he
has not. But that's
no doubt because Meng does not appear to be a proponent of SPF (I don't think
Meng is intentionally
scuttling SPF with spf.pobox.com, its just Meng pushes Sender ID). The SPF
council should overcome
that, and we should be getting better official SPF info soon on an official SPF
website. Its
clearly needed.
Anyone can argue that an old solution is bad, but truly
one needs to
argue against the most recent version of the solution.
I'm was trying to avoid mentioning SES too much -- I've been
accused of
advocating that purely because it's based on my own idea. Not
that said
idea wasn't fairly obvious once I was looking at SPF and SRS together.
I don't see SES as a fix for SPF's forwarding problem though;
I see SES
more as an _alternative_ to SPF, just like DK, IIM and the others.
I say this because when used with SES, SPF is _purely_ an
optimisation.
A significant optimization, because:
1) SPF DNS queries are cached
2) SES requires building/tearing down a TCP/IP (or at least some form of)
connection to the
originating server for every email
You can do the IP-address-based checking and bypass the
actual SES check
for some mail, but for the 'suspect' mail you still have to do SES
checking.
But in general, no load of _valid_ mail is going to
constitute a denial
of service attack; it's the _invalid_ mail which is going to cause the
I think your hypothesis is incorrect. Servers that process gigabytes of legit
email (such as some
of mine) would be impacted by the overhead of SES that SPF does not cause and
SPF can handle. Not
to say they cannot handle it, but they would be a lot closer to needing more
hardware then without
doing SES on every message.
loads we care about. So to use SPF in addition would be optimising the
case we _don't_ care about, while leaving the real SES check
in the case
we _do_ care about. Using SPF with SES doesn't really buy you
much over
and above what you get from just using SES alone. And the SES check is
lightweight enough that it isn't a problem.
That is incorrect: SES is not lightweight enough (it requires a callback per
email).
I have considered it holistically, your simply wrong.
My simply?
I don't understand: Is that a question?
CSV only does HELO checking. SPF does Mail-From checking, with
optional HELO checking.
But because the forger _may_ pretend to be a forwarder using SRS, the
MAIL FROM checking doesn't actually achieve anything more than CSV's
HELO checking. It's _different_ from CSV, but it's not more useful to
the (potential) recipient in practice.
Your assuming SRS will be used. That's a big assumption, although I don't have
stats, I'll bet
deployment is limited, or at least less then SES (for those in the know).
(Unless you decide that SRS should be _banned_ and SRS-like addresses
should be rejected, of course :)
I see no reason why a receiving MTA couldn't say "SRS headers cannot be
trusted, I will ignore
them".
I hope that SRS dies a quick death. Soon. Before anyone else deploys it. It
was a good idea at
the time, but we have something better now.
Anyway, SPF is easier to deploy then CSV, and is more deployed then
CSV. That *alone* if one just considered using the HELO checking of
SPF makes SPF more userful then CSV.
SPF is only easier to deploy if you don't bother to actually
address the
forwarding problem. To deploy _competently_ you need to wait for the
world to do SRS, or implement SES. And if you implement SES
and SPF, it
can't really be any easier than implementing SES alone, surely?
Now please stop bashing products (SPF or CSV or whatever) and try be
constructive with your criticism (or at least show all the facts):
That's what I'm trying to do. That's why I came up with the idea that
became SES within weeks of realising what SPF and how broken it is.
So you are pushing pure SES. Cool. Go spread the good word by advocating SES
on SES lists. Don't
push SES by beating up SPF please. There ARE solutions to the forwarding
issues, you clearly
condone one of them: SES
Terry
--
dwmw2
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily
deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com