Meng Weng Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> wrote:
On Thu, Jun 24, 2004 at 12:58:41AM +0100, Roy Badami wrote:
|
| CSV/CSA takes a very different approach, and is also of benefit.
| Whilst it would be possible to validate the HELO identity using an SPF
| or XML syntax, the requirements of CSV's problem space make that
| overkill.
"Overkill" is relative --- if the evalute_spf function is
already available, might as well apply it to the HELO name
and get back something useful.
The problem with this approach is subtle.
Indeed, for a receiving SMTP server which already incorporates SPF,
the additional coding to call the subroutine one more time is trivial.
But that has little to do with whether it's "overkill", and even less
to do with whether it's the right tool for the job.
Throughout the SPF design process, there has been a conscious choice
to load processing tasks onto the receiving SMTP server in order to make
the process of advertising SPF records as simple as possible. (This is
based on a belief that it will be easier to convince a few dozen coders
of MTA software than to convince millions of domain owners.)
Missing from this analysis is the question of convincing hundreds of
thousands of MTA managers to enable the SPF function (already programmed)
on each MTA. Perhaps I'm more paranoid than I need to be about what the
spammers will do. Or perhaps I'm not paranoid enough...
But I definitely see spammers upping the ante: they have available
millions of zombie computers on "fast" connections, and the managers
of those "fast" connections seem determined to do nothing to stop this:
merely to limit (some of) these computers to 500 emails per day.
Thus, I believe we need a truly "lightweight" mechanism to separate
whether we're dealing with an unauthorized zombie computer. SPF is
simply _not_ lightweight enough.
Please understand: for what it sets out to do, one could argue that
SPF _is_ "lightweight". But it sets out to do so much that we cannot
place upper bounds on the processing that might be required.
If we reach a situation where turning on the SPF feature brings
each MTA to its knees, the feature _will_ be turned off quickly. And
the management of that MTA won't be inclined to turn it on again. And
the word will get out.
For our own interests, we want to guard against something like this.
We want to protect ourselves from a ten-times increase in activity by
zombie computers. For this we need a tool whose processing load is
bounded. This is specifically what CSV was designed for.
To tackle the RFC2822 header issues, we need the complexity of SPF;
to screen out zombie computers, we don't.
I have been calling this approach "Unified SPF" --- it
embraces the CSV and the MTAMark/SS semantics using the SPF
syntax and lookup, just as SPF has embraced the CallerID
semantics with SenderID.
There's another issue I suppose deserves mention yet again: that
reaching consensus in the MARID WG is just one step towards an IETF
standard. (I'll let others judge how close we are to consensus.)
SPF is (IMHO) absolutely dependent on the use of TXT records in areas
of the DNS tree where other TXT records are likely to be found. We
_know_ we're going to face a lot of flak from DNS experts over this
issue. This cannot fail (IMHO) to slow down the process of becoming
an IETF standard.
People have been mentioning Unified SPF on-list a little bit
lately but I thought I should probably put it forward
officially and see what people think.
I think, frankly, that SPF has to stop changing if there's ever to
be any hope of progressing to an IETF standard.
(It's possible, I suppose, for it to achieve "market-share" without
settling down; but that's not what the MARID WG is for.)
| The two approaches seem complementary to me; is there any reason why
| this WG can't advance both to PS?
I explain in more detail at
http://spf.pobox.com/slides/unified%20spf/
Here, Meng advises folks to not worry about the difference between
HELO and RFC2822. Inevitably, that will lead to a large number of
domains advertising relatively open SPF records, and those relatively
open records being used to "authenticate" HELOs of MTAs which the actual
domain never had the slightest intent of trying to control. And, since
all of this is publicly available in DNS, spammers will quickly compile
a list of these.
But it gets worse: Meng actually advises bypassing further checks
if the HELO passes SPF checking and the domain passes reputation checks.
(Think about it, Meng: I'm sure you'll relent.)
Whereas CSV is designed for exactly the purpose of authenticating
and authorizing MTAs: there will be no confusion whether we're talking
about taking responsibility for the actions of the MTA or trying to
control the path which may be used to send email from the domain.
Think it through, Meng: ease of advertising should never be sought
at the expense of _accuracy_ of advertising.
--
John Leslie <john(_at_)jlc(_dot_)net>