On Wed, 2004-01-21 at 15:53, Meng Weng Wong 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?
First do the envelope-based tests in the current specification, then do
the currently-debated tests on the message body.
First pass: I would suspect that most current mail forgeries could be
rejected before DATA. For these rejected emails, no additional
bandwidth, cpu, or network latencies need occur.
Second pass: For connections that are not rejected at this point, the
additional tests in debate (and continually submitted) could be
performed at "." time. For this second pass at testing, you'll have to
incur the following costs:
1. The bandwidth cost of receiving the full email. This is not an
issue, because if you *didn't* do this second test, you'll have
to get the body of the mail just the same as if you did.
2. CPU usage. This is CPU usage that would otherwise likely occur
at some other point anyway, (ISP-level filtering outside of the
MX machines, or client-level filtering). The issue is not so much
whether it be done, but where it should be done.
My bias is that I'd be rather put-off by an ISP pushing
deterministic anti-forgery tests onto me because they didn't want to
spend the CPU to do it themselves at the get-go and generate a
proper reject when the opportunity existed.
3. Network latency. Some of the proposed tests could require
additional (also proposed) spf-type DNS queries. This means
additional MTA-processes out there waiting on DNS responses.
4. The nuisance of technical incompatibilities. MTA's that don't
understand reject-after-data have to be worked around in some
manner.
The problem of MTA's that consider a permanent failure reject at
this point to be a transient failure instead is the one that comes
to mind.
How to handle this particular nuisance would unquestionably be
an item for debate here.
IMO, this is broken behavior that should be fixed; meaning that I
would prefer rather harsh responses that mean people tend to
immediately recognize that their systems are broken and quickly fix
them, rather than have the proposed-additions-to-the-standard
modified in ways that may inadvertently break it or allow more
forgeries to get through. (Granted, this non-accepting behavior
is very un-RFC-like.)
(I'm partial to some sort of automated black-holing of
folks sending forged emails with broken software--the receiving
MTA keeping track of triples of sending-ip, envelope data,
checksums of body data for a few days, and after receiving some
number of duplicate sending-ip and envelope body
checksums, "black-holing" that envelope-sender/ip combination for
a few days by sending permanent rejects to all connections, with
appropriate error messages. However, this is an
off-the-top-of-my-head response, so it probably contains a lot of
fundamental problems.)
Also, there *could* be an addition to the spec so that
a domain can publish in their SPF records the fact that their MTA
or mail sending programs (I hesitate to say MUAs as that sounds like
it doesn't include programs that include their own code to send out
emails themselves directly) are broken in this way. (I'd rather
there not be such an addition but that the would-be publisher fixes
his software first.)
5. MTA's that require a lot of rewriting to test the body of emails
this way will be locked out of being able to quickly run these
tests.
Well, I suppose those MTA's can just ignore the full-body
tests, or push them off to other machines or the users.
Until the MTA's are rewritten, or they switch to another, these
people will receive more forgeries than people with more adaptable
MTA's, but there's no sense in everyone being held back because a
few find life difficult with their current software.
Note this is also in keeping with the notion of making every step
of SPF deployment advantageous to all parties: These people will
gain advantages by publishing SPF records, by filtering on the
envelope, and by filtering on the body.
In any event, #4 above is the only argument I can see as truly valid for
rejecting (haha) the idea of "."-time rejects, and it's not enough to
sway me really, (for what that's worth.)
As an aside, IMO sending a reject is friendly behavior to the
inadvertent forger. Delaying these tests and thus pushing them off to
the end-users who potentially run their own anti-spam and forgery
testing code means that either these users:
1. Don't run such programs and get more forgeries and forged spam, or
2. Do run such programs which either:
A. send bounces themselves, (unlikely, but still scary to think
about),
B. delete the emails unread, (meaning the hapless inadvertent-
forger doesn't realize he has a problem and his mails aren't
being read), or
C. The mails are marked as "probably-a-forgery", and the end
user gets a bad taste in his mouth about the whole procedure,
as spf doesn't seem to be working as advertised. (Remember,
the end user will *NOT* see the reject-before data emails,
rather he'll be judging SPF's effectiveness mostly on the basis
of the forgeries that do get through. I'm wondering if from
the end-user point of view, if it will look like these are
emails that should never have even made it *to* his spam
filter. As an aside, I guess this means that ISP's will
want to publicize to their users the average number of spams
per user blocked every week by SPF!)
To me it just makes sense to do tests at both places.
In any event, I'm guessing that spf2 will probably contain functionality
that would require tests of the whole message anyway. If that's
generally considered to be the case, then to me it makes sense to have
the spec to go ahead and force the issue now instead of later.
So again, to me it just makes sense to do tests at both places.
--
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;±¤Ö¤Íµø?¡