On Fri, 2004-01-23 at 11:23, tv+spf(_at_)duh(_dot_)org wrote:
On Fri, 23 Jan 2004, Mark Shewmaker wrote:
: > The decision at hand is:
: >
: > How important is it to reject forgeries before DATA vs after DATA at "."
time.
:
: Okay, I'm not an ISP, (IANAISP--or does IANANISP look better), but:
:
: Why not both?
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.
Okay.
So if you keep track of the triples I mentioned, (which requires a lot
of work of course), and you decide to do the black-holing of envelopes
corresponding to resent messages on the second delivery attempt, then
the bandwidth increase you'll see will be due to a doubling of email
messages in which:
1. The before-DATA test passed.
2. The mail is still a forgery according to debated-to-be-added SPF
heuristics.
3. The sender's machine chokes on rejects at "." time. (You say most
MTA's are like this.)
I suppose one question is what percentage of all received emails fit all
three requirements above?
A second question would be what percentage fit just 1 and 2? (That is,
how many emails *pass* spf envelope checks but would *fail* the proposed
body header checks?)
A third question is how would we interpret any percentage?
If the percentage is considered low, then there actually wouldn't be
much of a bandwidth problem. Spammers would be dissuaded from trying to
adapt-around spf restrictions on forgeries because spf has built-in
defenses to that and it would get them nowhere. (Sending
non-forged-envelopes from probably-blackholed IPs with
would-fail-spf-check body headers won't get them far in a world where
spf is being more and more widely deployed.) So, I expect that the
result would be that this percentage would stay low, and get lower as
MTAs are very slowly updated.
If the percentage is high, then that means that SPF isn't going to be
very effective at preventing forgeries from just envelope data in the
first place, and we'd really need to add in header checks for it to be
at all workable.
(As an aside, a spammer would probably want to send email from a MTA
that handles at-"."-rejects properly, as otherwise they'll be wastfully
resending to places they'll never get their mail to anyway. Strange to
think of something as possibly being useful because of its advantage for
spammers though!)
There's another, legal, problem with
rejecting after DATA; see below for more explanation.
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.
Sure, go ahead and provide *suggestions* on how to implement filtering using
SPF and DATA-phase headers. PLEASE DO NOT MAKE THIS A "MUST" OR "SHOULD" IN
A RFC-TARGETED SPEC. Doing so will seriously degrade the feasibility of SPF
(even if dubbed "v2") implementation in most large ISPs.
The draft in progress says what you MUST do if you decide to have an SPF
client (that checks on the basis of envelope data and DNS queries.)
I would suggest that the draft in progress could reasonably specify what
you MUST do if your SPF client is also to do spf-tests on the body.
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.
However, I do have a question: What would you think of a requirement
that your authorized outgoing MTA machines according to your published
SPF records SHOULD properly handle rejects-at-"."?
<decloak style="frosted-glass">
I happen to know the internal folks of one such large ISP, and why they will
not implement SPF if it requires body checks.
</decloak>
This is the Mystery Supporter argument in another form.
In any event, if body checks are really to everyones advantage, then
those who don't do them will simply be at a disadvantage. If they are
far more trouble that they're worth, then people simply won't adopt that
section. Just like spf as a whole really.
I believe they'll be useful, and I want to deploy something like what's
been discussed at some point. Before then of course, you may have
persuaded me of the error of my ways.
ISPs can also get into legal trouble in some jurisdictions because only
rejection at RCPT TO time can provide each end-user the ability to choose
whether or not to use a given type of filter. Rejection at both MAIL FROM
and DATA have the effect of rejecting all recipients in a multi-recipient
mail.
Thanks. I didn't think about that difference.
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.
If less than all have done so, the mail can be accepted and headers
added for any users who did.
(There is a privacy issue here in that if you selected this filtering
and received an email like that, you would know that at least one of the
other recipients didn't select the same filtering. If that's not a
problem that can be solved contractually, then that ISP could simply
merely add headers for all filtered-at-body emails. The proposal would
have to account for this potential snag.)
: In any event, I'm guessing that spf2 will probably contain functionality
: that would require tests of the whole message anyway.
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.
--
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;±¤Ö¤Íµø?¡