spf-discuss
[Top] [All Lists]

Re: Electronic Frontier Foundation (EFF) Article OnAnti-Spam Technologies Mentions SPF

2004-11-23 09:47:02
On Tue, 2004-11-23 at 08:49 -0600, Daniel Taylor wrote:
I suspect that few are bright enough to reject instead of
bouncing or dropping. For any reason, let alone SPF.

True. And those who are lax enough in their thinking to have chosen SPF
instead of one of the many other options are going to tend to be the
lower end of the spectrum.

The
burden of 'blame' definitely does seem to have fallen on the recipient
for rejection of mail -- people publish '-all' but there are very few
(relevant) sites actually obeying it.

Blame is irrelevant, but I hold the receiver responsible
if they drop instead of rejecting.

With "-all" we at least have stated a firm policy that can be used
by ourselves and others as a definite rejection rule. If a site
rejects our mail based on that rule, then we are dealing with
either a forgery or a configuration error. 

Assuming your definition of either 'forgery' or 'configuration error' in
this context includes forwarding setups which have worked fine for
decades, yes.

I can deal with either
case appropriately. If they silently drop our mail for _any reason_
I cannot deal with that, as I do not know about it.

Indeed.

Heck, I see 2-3 "mail loops back to self" bounces a week just from
people signing up with us. E-mail is misconfigured, unreliable, and
generally a pain. SPF with "-all" at least relieves some of that pain
and moves more to where it can be dealt with.

Why so more than (<pick your second choice alternative>)?

Now that you're publishing '-all', how many bounces are you still
getting to mail which you didn't send?

Quite a few, mostly because SPF isn't that widespread on the receiving
end yet. Most of the ones we get are virus bounces, from sites that
really should know better.

SPF doesn't seem to be _getting_ very widespread? Has anyone actually
done any statistics on how many sites are actually rejecting for an SPF
failure? As Meng said, it's pointless unless you can actually _reject_
for it -- we have enough heuristics already.

I get almost none now that I use SES, and I can send to people who
forward their mail.

You get almost none, or you _accept_ almost none?

I accept none. Since I reject at RCPT TO not at DATA time, I can't tell
precisely how many of the connection attempts are SMTP callouts and how
many are 'genuine' attempts to deliver a bogus bounce. 

We still "get" quite a few "from self" spams, but we refuse to accept
delivery because they fail our -all rule. We could use SES in addition
to allow us to refuse bogus bounces as well, but we haven't yet.
Mostly because I still find them more informative than annoying.

I long ago gave up finding it informative that my addressees were being
spoofed. Now I find it convenient just to block out the bounces.

SES isn't really a direct replacement for SPF though -- it's somewhat
orthogonal. The one that really replaces SPF would be CSV. It's
unashamedly a hop-by-hop method which only claims to vouch for an
individual mail server, but in the presence of SRS, that's all that SPF
can actually achieve _anyway_. 

-- 
dwmw2


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