spf-discuss
[Top] [All Lists]

Re: Explain please

2005-07-07 00:56:17
On Wed, 2005-07-06 at 21:19 -0500, Scott Kitterman wrote:
Even if I did BATV w/callback support (and it's an intriguing idea, I'm 
going to look into it), there's no way I'm aware of to tell the world that 
I always do that so I'd like them to treat anything that passes CBV as 
authorized mail and anything that doesn't as a forgery.  I'd like to be 
able to do that.

Why? Almost all of the huge number of people who already bother with CBV
will already be treating the failures as 'forgery' by rejecting them.

So would I be right in thinking that the information you want to _add_
is purely to distinguish between the 'not necessarily fake' case and the
'definitely from me' case?

That sounds like what Stuart says -- he'd use BATV to give an 'unknown'
result but not a 'pass' result, because he "[wants his] PASS to be a
pretty strong assertion". 

The idea for both of you seems to be similar, AFAICT -- you seem to want
to not only make a distinction between clearly fake mail and the rest,
but _also_ to make a distinction between _definitely_ genuine mail and
the rest. Is that right?

Two things confuse me about that -- firstly that I'm not sure it's
particularly useful, and secondly that I'm not sure it's even possible.

Let's start with the first. Most people just want to get rid of a lot of
faked email -- what they need is like a high-pass filter, where the crap
can be thrown out at SMTP time but _without_ losing genuine mail. People
do this with tools like SpamAssassin all the time -- tuning the
rejection thresholds until their SMTP server accepts everything they
actually want, but throws away the _obvious_ crap. SPF, BATV, DKIM and
other proposals attempt to give a less fuzzy, more reliable and less
computationally expensive alternative to SpamAssassin and its like, but
the idea is still that you draw a line somewhere and anything on the
wrong side of it is rejected.

That's the _useful_ thing here. Once the SMTP server has decided that it
can't just reject the mail, and the mail has actually landed in the
user's inbox, these heuristics aren't particularly useful any more --
the user can decide for _herself_ whether the mail is spam or not, at a
glance, according to its content. And her time has already been wasted
by doing so; that's what we try to avoid by rejecting it in the first
place. It's only _really_ rejection which is the useful outcome in the
vast majority of cases. I don't see what more we gain by being able to
observe that a given mail is 'definitely valid' as opposed to just 'not
to be rejected because it's not necessarily fake'.

Secondly, we have to realise that in _general_, the recipients _can't_
make that kind of inference from the difference between a '+' and a '?'
in the SPF record of the sender. A PASS _isn't_, in general, a 'pretty
strong assertion'.

Even if _you_ have been ultra-strict and have have given a '+' _only_ to
those machines on which _no_ processes other than the MTA can make an
outgoing TCP connection, how can the recipient know that? That certainly
isn't the _common_ case. Although one or two domains may try to publish
records that way, you'll find that the _vast_ majority have also given a
'+' to boxes on which other people have accounts and can send unvetted
mail.

SPF has 'false acceptances' in that case, and in the case where you also
include your ISP's outgoing smarthosts in your record, and in the case
where the mail comes through a known forwarder or MX backup which
doesn't reject for SPF failure. That's not a _bad_ thing -- we _should_
be erring on the side of caution and accepting mail which isn't
definitely bad. SPF isn't designed to replace GPG when you send
instructions by email to your bank manager. 

(Now, all this is wrong if you have a plan which gives us a perfect 100%
reliable yes/no answer to the question of whether the mail actually
_did_ come from the person it claims to come from. _That_ kind of system
we _could_ perhaps use for both spam-rejection and banking at the same
time. But unfortunately nobody's come up with one so far -- so we have
to err on the side of caution when deciding which mail to throw away.)

-- 
dwmw2



<Prev in Thread] Current Thread [Next in Thread>