On Tue, 2004-06-08 at 18:28, administrator(_at_)yellowhead(_dot_)com wrote:
The SUBMITTER document was even more informative. It doesn't say you have
to process the RFC 2822 From: (I am dead set against processing anything
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
after DATA), although in early implementations you would probably have to
^^^^^^^^^^^
just to get the information at times.
I do not understand *universal* objections to after-DATA processing. I
do not think it is entirely rational.
In the case of new-SPF in after-flag-day-world, you simply have to
verify that SUBMITTER matched the PRA--and the only way to do that is
after DATA.
But before you've gotten to that point, you've already done the major
SPF checks and so you're already obligated to receive the DATA section
anyway. Checking to see if the sending MTA lied to you with the
SUBMITTER sneak-peek at the PRA doesn't cost you any extra bandwidth,
and only a tiny amount of cpu.
Once you've done all the pre-DATA checks possible, you no longer have
any reason left to object to receiving DATA. In other words, you've
committed to receiving it--you're going to agree to accept it and you'll
get that message.
At that point, you have the message available, right then and there, for
any other test that you might want to apply.
No arguments against after-DATA tests that are based on wasted bandwidth
can now apply. Arguments about cpu usage can make sense, but not for
something as simple as a PRA==SUBMITTER verification. Arguments about
wall-clock time can sort of make sense, such as if your additional tests
require additional DNS queries, and thus delays in hearing the
responses, but even that is stretching things a little bit.
At the very least, no one who does heavy-horsepower content-based
checks, such as any virus checks of incoming&outgoing emails, can IMHO
really complain about additional something so small as after-DATA checks
such as PRA==SUBMITTER verification.
Side note:
----------
Even if (*GASP*), SPF were to require after-data checks for every single
thing it looked at, now and forever more, that isn't quite as bad as it
sounds..
SPF is designed to stop forgeries. (The new and old ones stopping
different types of forgeries.)
As it becomes widely implemented, say by most of the large ISPs, and
forgeries of the type it stops by definition stop getting through,
then...there will be less and less benefit for the scammers/forgers to
continue forging/scamming in such a detectable way. and they'll have to
switch to other methods--even in their hoards of taken-over cable&dsl
machines.
(As an aside, IPs that are the source of large amounts of SPF-determined
forgeries can simply be IP blacklisted, at least temporarily, even more
easily than they're blacklisted today.)
All this implies that the number of sent forgeries should radically
decrease, as there's little point in new forgers using these strategies,
and old, taken-over machines that continue to spew forgeries will get
stopped even more efficiently by blacklists.
If you start with a situation where a large number of incoming messages
are forgeries, then yes, having to wait until after DATA to even hope to
have the opportunity to reject is annoying. But if you expect to end up
six months later with a situation where 95% of incoming messages are
SPF_PASS, then the situation isn't as clear-cut.
Lowering incoming bandwidth by that last 5% probably isn't worth
worrying about. Instead, what's more important is whether the test is
even testing what you really want to test to begin with.
So, my take on the various types of objections to the new SPF:
o XML objections: Okay, those make sense.
But in the long term, no admin in their right mind
will do XML-based testing of incoming messages, no
matter what the RFC says.
The people who publish XML records will surely
realize that and also publish non-XML records
if they want all the benefits SPF provides them.
So I'm not really worried on the XML issue.
o After-DATA objections: They don't *always* make sense. If the
test is actually sane, and it can't be
done in before-DATA ways, then this isn't
necessarily a reason to object, even though
any sane techie type is just itching to
find a valid reason to object on these
grounds.
o PRA-versus-old-just-MAILFROM: This is the only argument that can
IMHO potentially make sense. (though
I have not been swayed by the don't-
like-new-spf-algorithm folks
personally, yet at least.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com