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?
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?
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.
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
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.
I have considered it holistically, your simply wrong.
My simply?
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.
(Unless you decide that SRS should be _banned_ and SRS-like addresses
should be rejected, of course :)
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.
--
dwmw2