spf-discuss
[Top] [All Lists]

RE: RE: SPF: Not just a clever idea

2004-06-09 03:22:46
(Skip if you're not interested in reading an "Even expensive after-DATA
tests aren't *always* bad" argument.)

On Tue, 2004-06-08 at 20:54, Seth Goodman wrote:
From: Mark Shewmaker
Sent: Tuesday, June 08, 2004 7:12 PM

I do not understand *universal* objections to after-DATA processing.  I
do not think it is entirely rational.

I want to second Mark's position on this.  A more reasonable requirement is
to avoid doing _any_ expensive tests during the SMTP session, whether before
or after DATA.

Uh-oh.  Even after all those nice words, I'll have to say that I don't
quite agree with that claim.  :-)  

While we want to reject everything possible before DATA,
adding an inexpensive test after DATA that permits rejection at the end of
DATA is worthwhile.

Yes.

If you have the DATA, there's no real reason to object to an inexpensive
test.

However, I would go further and say that there's not always and
universally reason to object to expensive tests if you're going to do
them later anyway.

- Any policy engine that operates after the end of DATA is largely a waste
of effort.  Existing post-acceptance message filtering tools are extremely
effective.  If we discover a forgery after accepting a message, we can't
send a DSN since the return-path is dubious so we are forced to null route
the message.  Though this is clearly the lesser of two evils, it highly
undesirable.

- Once a message passes 2821 tests and we allow the SMTP-client to proceed
to DATA, it is to our advantage to identify any _inexpensive_ tests that can
be done that permit us to reject at the end of DATA.  We should look for
these opportunities because it is better to reject at the end of DATA than
to discover the problem later and silently drop the message.

For me personally, *if* I'm also going to be running more expensive
tests, I'd prefer to somehow do those tests at SMTP time instead of
later if at all possible.  (ie, if I have enough spare horsepower and
low enough incoming mail load on the servers accepting mail.)

I want to do these tests at SMTP time because I want legitimate senders
to have the greatest chance possible to be immediately notified of any
delivery problems, and rejects do that.  Bounces, silent deletions, and
moving messages to probably_spam folders don't.  Also, I don't want
recipients to be put in the position of having to automatically delete
incoming messages unread.  It's just asking for trouble.

(If a customer's email fails some mail validity check, I'd prefer they
get a reject and know there's a problem, and hopefully call me--but at
least *know* that there's an email problem going on, than for my tool to
put it in a folder where I'm quite likely to not notice the mail in
manual periodic checks, and the customer then ends up thinking I've
ignoring him.  I'm more likely to miss the valid-mail needle in the
haystack than a sender is to miss a reject sent within moments of his
attempt to mail me.  In any event I'd rather pay for a slightly beefer
mail server that can handle these tests then and there, than pay for
pissed off customers who think I'm not paying attention to them.)

If you reject non-passing messages at SMTP time, then you've done the
most you can possibly do to notify legitimate senders of the problem.

If you delay any test until after SMTP time, legitimate senders can be
unaware that their mail is consistently or randomly thrown away, and
recipients might be unaware that they're throwing mail away.

I want problems to be known, visible, and debug-able, not hidden under
the carpet.

Even the most effective post-acceptance tools will end up hiding
problems from you far more than an equivalent pre-acceptance tool.

Fortunately, I can personally mostly do expensive SMTP-time tests--I
even do incoming and ougoing virus checks at SMTP time, as I don't have
zillions of emails an hour to go through.

And fortunately for SPF, none of the proposed after-data checks are near
the order of magnitude of, err, heaviness (?) of virus-checking--not
even the SES checksum tests really.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com