Moot points now that Meng refroze the v1 spec, but for what it's worth:
On Fri, 2004-01-23 at 15:53, tv+spf(_at_)duh(_dot_)org wrote:
On Fri, 23 Jan 2004, Mark Shewmaker wrote:
: 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.
The ones I mentioned in the first email of mine you responded to today,
keeping track of passed-envelope-check but failed-body-check forgeries,
to prevent infinite retries from buggy sending MTAs.
: 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!?
The tests discussed elsewhere on this list in the past week or so
discussing the possibility of neither header body Sender: nor From:
having anything to do with the MAIL FROM sender.
Granted, it's harder for a Spammer to forge emails that way, as they'll
be sending from easily-blackholable IPs, but it was a concern brought up
and discussed a good bit elsewhere on the list.
: 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.
But my understanding was, especially given other emails on this list
stating this in no certain terms, was that if an MTA considered that a
transient failure that that was a bug in that MTA--there was never any
debate about whether that was a bug, only concern that buggy MTAs were
out there.
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.
Again, at that point you have no choice but to receive that entire data
stream anyway, because you've *already done* the currently-spec'd
envelope spf check, that email passed them, and so you decided not to
reject before DATA for that email.
The greater expense would come not from larger body data streams but
because on the very small percentage of emails that make it past your
envelope tests but not the simple spf body tests: You'll have to
workaround buggy MTA's by keeping track of these past failures to reject
at envelope the second time around, or use some other expensive
workaround.
(I was surprised you didn't strenuously object to that on the first
email, as it would mean you'd have to set up a lightweight database that
your MTA would query at envelope-test time.)
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.
Honestly that doesn't make sense. I really don't follow the logic and I
don't understand what you mean by being lazy: I can't imagine that
anyone would ever want to skimp on the envelope checks for one, and the
header checks discussed elsewhere are about as clear as the envelope
ones.
As far as mail senders--I don't see how this means they'd want to change
their published SPF records either.
I simply don't follow. What would being lazy entail?
Please, before we fall into the DATA-phase trap, put it in an extension
document that is not attached to the core SPF spec.
Uhm, that's effectively the same thing I'm suggesting--I really can't
see the difference between a separate extension and mention of how to do
an additional check that people will surely be doing.
: 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-)
I understand, and I wasn't suggesting you were the Mystery Supporter,
nor that you wanted to throw XML everywhere.
(However it would make for a great April Fool's day SPF V2 spec to
rewrite everything possible in terms of XML, even though that wouldn't
be funny to anyone outside this list.)
: 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.
I'll look at the archives.
: 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.
That's fine then. Just don't handcuff the rest of us. :-)
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*.
I've never, ever objected to the earlier checks.
: 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.
You pointed out that that's impossible to do no matter what, and I
understand and agree, so there's no sense worrying about the cases that
can't be handled.
: > 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).
Without the possibility of doing rejects and without as much hard data
on small domains--but SPF will fortunately change the latter.
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.
I'd still like to do such body checks on my own machine, even if it
means I'll have to work around buggy MTA's. I'm probably not the only
one who wants this. (Assuredly not, since it's been discussed here.)
--
Mark Shewmaker
mark(_at_)primefactor(_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;±¤Ö¤Íµø?¡