On Fri, 23 Jan 2004, Mark Shewmaker wrote:
: > Because DATA can be arbitrarily large, and requires consumption of the
: > entire message. Most MTAs will choke if the DATA phase terminates abruptly
: > without consuming all data, and will turn around and send the message again.
: > This is a bandwidth waste problem.
: So if you keep track of the triples I mentioned,
Keep track of what triples? SPF's purpose is to verify that the sender of a
mail is plausible--nothing more.
: 2. The mail is still a forgery according to debated-to-be-added SPF
: heuristics.
Stopping forgery at the MAIL FROM sender level is pretty cut and dry. I
don't see how you could then additionally consider the mail to be a
"forgery". Exactly what additional information are you trying to check!?
: 3. The sender's machine chokes on rejects at "." time. (You say most
: MTA's are like this.)
I didn't mean that. What I said (explained here in further detail) is that
rejection at DATA requires consuming the whole message, whereas dropping the
TCP connection is equivalent to a transient failure that will cause the
remote MTA to retry. So any check that is at DATA is inherently more
expensive by several orders of magnitude, as the entire data stream must be
received before the 5xx can be sent.
: > Thus, reliable, well-deployed mail rejections must happen before DATA.
: > Sending a 5xx after DATA is "filtering", not "rejection", because the SMTP
: > agent had to accept the data before sending the 5xx!
:
: Given the possibility of saving the spf-rejected triples, I don't see
: that that argument follows.
Huh? The only difference between reject-after-DATA and a filter program is
the 5xx result code. It doesn't matter what you do with the data after that
point; it's been consumed.
And we all know that common forgers don't give a damn about 5xx results and
will keep on sending anyway. So such reject-after-DATA collapses right back
to filtering.
: But I would not suggest that the draft say that clients that do envelope
: checking, (the only kind currently listed), MUST also do any other sort
: of tests as well. (With obvious exceptions for changes that may become
: necessary for v2 that we don't currently don't realize are or will be
: important.)
:
: I believe that addresses this concern of yours.
No. I'd like to see the DATA-phase loophole closed now, before we fall into
that trap. The point of SPF was to make use of SMTP transaction information
to provide a *lightweight* authentication mechanism.
Adding a bunch of DATA phase check possibilities to the core spec encourages
too many mail senders (you know, the ones who create the SPF records in DNS)
to be lazy. This defeats the lightweight check purpose of SPF, which I
believe will lead to too many "unknown" results in the wild due to low
adoption rate.
Please, before we fall into the DATA-phase trap, put it in an extension
document that is not attached to the core SPF spec.
: This is the Mystery Supporter argument in another form.
I have to stay cloaked on mailing lists for contractual reasons, sorry. I
can talk more about that offlist only. Let's just say here that my employer
is not based in the state of Washington, and its core products are
bandwidth, not software. I also only use XML for exporting or importing
data, and rarely that if I can avoid it. 8-)
: In any event, if body checks are really to everyones advantage,
You've never spent much time in anti-spam mailing lists, I presume. It's an
established fact that body checks are *bad* and something we want to
eliminate as much as possible, not integrate further.
Join SPAM-L(_at_)PEACH(_dot_)EASE(_dot_)LSOFT(_dot_)COM and
SPAMTOOLS(_at_)ABUSE(_dot_)NET(_dot_) There's lots of
folks there who can educate you with statistics relating to the high expense
of rejecting at DATA rather than MAIL FROM or RCPT TO. I've been a regular
on both for several years.
: However, you can still get partway there imperfectly by simply only
: doing a reject at "." if all end-users have chosen to use SPF body
: "filtering", as you call it.
Not likely to happen. Many customers want to receive everything unfiltered
just to avoid even the narrowest possibility of a false positive.
Besides, this would only be useful in some cases. There's far more
effective after-DATA checks that attempt to fix the Spam Problem, which
already fix the forgery problem as a side effect (SpamAssassin is a
semi-decent example). We want something that happens *earlier*.
: If less than all have done so, the mail can be accepted and headers
: added for any users who did.
But then the recipients who wanted to reject never got the chance to do so.
: > I sure hope not. I might as well pack up on the SPF idea and go home if it
: > turns into just another "filtering" scheme, because it'll end up being no
: > more useful than all the other filtering I have to do today.
:
: That's not a valid comparison. The normal current filtering schemes
: can't do sender-permitted checks as spf can.
Actually, there's a motherlode of "mail for foo.dom.ain comes from these
networks" data out there, particularly for such folks as AOL. Filtering
software can already make use of this (SpamAssassin does).
My point, however, is that SPF-checking after DATA is no better at stopping
the *entry* of forgeries into the system than all kinds of other heuristics
on the message header and body which are already done. Doing SPF-on-body
just adds another sieve layer to the already too big body filter mix.
I honestly believe that encouraging implementation of SMTP protocol level
changes (such as SRS) would do much, much more than body checks to make SPF
not just feasible, but very convenient. Even new ESMTP extensions are
probably more likely to be widely adopted than specialized body checks.
--
-- Todd Vierling <tv(_at_)duh(_dot_)org> <tv(_at_)pobox(_dot_)com>
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡