David Woodhouse wrote:
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.
Insults will get you nowhere.
Especially as I have already stated that I reject based on SPF (as well
as other measures).
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.
I should perhaps rephrase this. If the receiver drops instead of
rejecting, they are taking full responsibility for the non-delivery
as no one else can know about it.
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.
Coal fired boilers with short stacks "worked fine" for decades. If you
were willing to ignore the choking smog.
Forgery contributes to spam. If we are able to lock down ONE header
that we can say "this is guaranteed to be valid", then we have a tool
of unbelievable utility for fixing the rest of e-mail.
It is time to clear the smog of spam from the internet, please consider
where you stand.
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>)?
Because it works, and it is widely enough deployed to help.
I would like more sites to reject on SPF failures, as there are still
some weaknesses in the system and that would shed more light on them.
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 do reject based on SPF. Dozens of messages a day.
I would like more sites to do the same. It would cut my
bogus e-mail load significantly.
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.
For me it is informative in that it gives me a pulse of
(malicious activity)/(SPF deployment). I'm not happy with the state of
receiver SPF deployment yet, but there is little I can do about it.
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_.
So why do we need an unimplemented alternative that only claims to do
the same thing?
--
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203