User: Password:
Subscribe / Log in / New account

Backscatter increase clogs inboxes

Backscatter increase clogs inboxes

Posted Apr 10, 2008 4:40 UTC (Thu) by dlang (subscriber, #313)
Parent article: Backscatter increase clogs inboxes

I thought I read that the most extensive use of SPF was spammers domains.

on the other hand if you do have a SPF definition and the mail server does check it when it
receives the mail, it won't send it on to the second-level process that's eventually bouncing
the message.

(Log in to post comments)

Backscatter increase clogs inboxes

Posted Apr 10, 2008 4:49 UTC (Thu) by zlynx (subscriber, #2285) [Link]

In the early days of SPF some sites were configured to give bonus points or whitelist source
domains with SPF.

The right way to use SPF is negative scoring only.  If email doesn't match its domain SPF then
give it spam points ... whatever you happen to think it's worth.

what is SPF good for ?

Posted Apr 10, 2008 16:50 UTC (Thu) by copsewood (subscriber, #199) [Link]

Personally, having implemented it and then given up, I think the only useful application for
SPF is whitelisting. If you score based on SPF pass or fail and this increases your false
positives/negatives there is no point using it in this way, unless your objective is to punish
people for incorrect or unmaintained SPF setups. However, if you have whitelisted the domain
as having a well-managed mail system then SPF can give you some confidence a message from a
particular IP address is from that domain.

what is SPF good for ?

Posted Apr 10, 2008 17:10 UTC (Thu) by zlynx (subscriber, #2285) [Link]

That's another good use of it.  I don't whitelist at the mail server level so I didn't think
of it.

As for punishing people with bad setups.  Yes!

Admins are already punished for running open relays, not having reverse DNS records, firewall
blocking their sending SMTP servers and many other things.  If they publish a SPF record, it
had better be correct.

what is SPF good for ?

Posted Apr 11, 2008 15:53 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

"As for punishing people with bad setups. Yes!"

If only there were some way to do that without punishing the sender and recipient of the mail more.

I have often seen instances of mail recipients rejecting my mail out of spite, based on an opinion of how the mail system should work. In every instance, the recipient would have enjoyed receiving my mail more than I would have enjoyed him receiving it. In most cases, it was a reply to an email he sent me.

If SPF is too complex try CSV/CSA

Posted Apr 10, 2008 18:03 UTC (Thu) by copsewood (subscriber, #199) [Link]

I think there are 2 reasons SPF hasn't delivered much help in practice.

  1. Not much use other than to help with whitelisting known good domains. It pushes the problem back from knowing what the good and bad IP addresses are to knowing what the good and bad domains are, but only helps here for known good domains with SPF records consistent with email envelopes.
  2. It tries to go too far and ends up too complex and difficult to maintain. (I've implemented SPF and believe me, it's a mess). If there is any regular change in where your domain email users want to send their mail from, maintaining a useful SPF DNS record becomes unlikely.

Knowing which domain is responsible for a sending MTA is likely to be easier than knowing which addresses an envelope From: (not the header From) can reasonably be sent from. The Microsoft take on SPF, SenderID is even worse because it tries to validate the header From and related headers.

If it is more easy to know good from bad domains than good from bad addresses, CSV-CSA provides a much simpler check of the domain responsible for the sending MTA and doesn't care about any envelope or body headers beyond the HELO/EHLO greeting. Presumably if the MTA is run from a well managed and reputable domain, the rest of the message is more likely to be authentic. For those particularly interested in message authenticity (useful if you want to know a message claiming to be from your bank is actually from your bank) then DomainKeys can be used to give stronger assurances. However, DomainKeys isn't reliable for mail going through mailing lists or other gateways that mangle the body or headers of the message.

If SPF is too complex try CSV/CSA

Posted Apr 12, 2008 19:46 UTC (Sat) by kevinbsmith (guest, #4778) [Link]

For those of you who don't naturally think in RFC-speak, here is a gentler introduction to

It's still not quite as "plain English" as I would prefer, but it's not bad. I would be
interested to hear other opinions about a) how much good for individuals who adopt it
tomorrow, b) the likelihood of it being widely adopted, and c) how much good it could do if
widely adopted.

I'm still sad about SPF. The worst part was when I set up both email hosting and outgoing smtp
services at (who themselves were among the SPF originators), and was still unable to
find or get a simple recipe for configuring SPF.

If SPF is too complex try CSV/CSA

Posted Apr 17, 2008 11:07 UTC (Thu) by copsewood (subscriber, #199) [Link]

Good article thanks. I think that SPF is probably redundant, because if you want to know the
sending MTA is responsibly managed CSV/CSA together with a domain reputation system is
probably better. If you want to know the message is authentic, Domainkeys offers a better
solution. I don't think there is much overlap in function between Domainkeys and CSV/CSA but
SPF tries to overlap both and does neither job well.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds