Slashdot Mirror
Ask Slashdot: How Do You Handle SPF For Spam Filtering?
An anonymous reader writes "Our organization had had a decent SPF record of our own for a long time. Recently, we decided to try using SPF for filtering inbound mail. On the up side, a lot of bad mail was being caught. On the down side, it seems like there is always a 'very important' message being caught in the filter because the sender has failed to consider all mail sources in writing their record. At first, I tried to assist sending parties with correcting their records out of hope that it was isolated. This quickly started to consume far too much time. I'm learning that many have set up inaccurate but syntactically valid SPF records and forgotten about them, which is probably the worst outcome for SPF as a standard. Are you using SPF? How are you handling false positives caused by inaccurate SPF records?"
If they are too stupid to set it up correctly then they don't deserve to work with you.
We're experiencing the identical problem, but keep on doing what you're doing. It is scary to see 'valid' mail from Fortune 500 companies who can't keep track of their own SPF records being dropped by Postini, but it is happening on a regular basis. We're doing what we can to help out those who are affected and eventually we will help reduce spam and get everyone into the 21st century with their outbound mail and SPF records.
Or anything else, for that matter--mark it as "spf failed" and score it as you feel appropriate for your filtering setup.
Spamassassin handles SPF, reasonably intelligently, that is, not trusting it completely, not giving it more weight than it deserves.
Hanging your spam fighting hat on any single hook is problematic. and SA uses a wealth of tools with constantly updating itself via
scripts. Its been largely trouble free, and we have it set up so that it will learn false positives and false negatives when users
move these to the corresponding folders.
I've been well served by Spamassassin for some time now, it runs quietly
on our mail server. SA does not block mail. It flags it. Our mail server will evaluate these flags and trash outright the most
egregious spam, but we have the limits set low enough such that we will allow the questionable things through.
We error on the side of caution, but we still dump a lot of mail right after SA flags it. (Our business can do that, your business
may not be able to do that.)
Sig Battery depleted. Reverting to safe mode.
Too many users are still careless with it. This is because it was proposed as a DNS standard, but was poisoned by Microsoft cluttering it with the entirely distinct "DomainKeys" project, then deliberately mislabeled the SPF version that they use. (See the history at spf.pobix.bom)
The result is that SPF has been less useful than expected. Also, SPF does not work well over mail relays unless they're configured to to indexing and re-writing of the "From " field, and pass the bounces through the relay server on its way back to the original sender. But it has been enormously effective to add to spam *scores*, to give anything with a bad SPF result a much lower score as a potentially valid email message.
The best mail filtering is based on geographic region of the envelope IP address. Most spam comes from countries without any proper anti-spam legislation, so simply junk them all until they get their act together.
Use SPF as part of a whitelist/blacklist scheme.
For sources that have their shit together, trust their SPF records as an absolute metric.
SPF does work if set up correctly.
We had the same problem.
Our solution: if the message makes it past all our spam filters and the only problem is that the sender's client isn't allowed by their SPF record, we send a friendly, plain-english informational message back to the sender, then deliver their message to our users.
"Please tell your company's IT staff that your mail server isn't set up correctly. This may cause your messages to be rejected or classified as spam. Please forward the following information to your system administrator: [SPF record] [sender's IP]. Thank you!"
Usually the issue is that the sender has set up GMail to send "from" their company email without sending through the company SMTP servers, usually without authorization.
We do the same thing with broken DKIM signatures.
This has worked well for us, since senders get tired of the message and seem to get things dealt with. We considered adding a "threat" saying that if the problem wasn't fixed, we'd block the sender, but that was rightfully shot down as pretty mean.
We actually mark on SPF checks on the outside but accept them. They then pass through a spam quarantine system which if they are SPF-FAIL or SPF-SOFTFAIL they are quarantined. Users can release them if they want to but they have to check their "Junk" reports to look for them or go to the portal itself. They have up to 15 days to release them or they are gone. However since these are a policy based rule, they can't white list senders that are messed up. Doesn't take long for a major vendor to learn they need to do email right.
Biggest problem is people with SPF records ending with ~ALL which basically means here is where we think our mail is coming from but if it is from somewhere else don't block it. Kind of stupid to not know where your email is being sent from. Especially annoying when a known company is setup like that that gets used as a phishing attack which is why we now quarantine SPF-SOFTFAIL now.
Thanks, Google!
I can't be bothered to run my own damn SMTP/IMAP/etc any more.
You can't fix everyone else's mail server and you can't fix everyone else's SPF records. SPF was a poorly thought out idea with a poor implementation, and it's never ever going to become relevant. The only thing it's good for is wasting your time like this.
If you have allo day to spend on this, you might try fixing the world's HELO responses too. You can catch tons of spam this way. And put your users out of business by blocking their essential mail coming from incompetently run mail servers.
Here is how I increased my SPF using one weird trick!
Silence is a state of mime.
Give sender a check box to manually block it.
Automatically add all receivers to the SPF.
If it's going to be hazy out I prefer SPF 25. If it's full on sun I prefer SPF 40 or above.
That's what DMARC is for. It let's companies specify exactly how to handle their SPF (and DKIM) rules based on how thoroughly they have covered their bases. The company I work for deals with a ton of phishing against our user base and implemented SPF, DKIM, and DMARC with great success.
Google has excellent documentation on the protocol.
"Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
We just get Google to worry about spam for us.
We use Postini for archiving
We have low TTL MX records and a back up provider in case we have to worry about Google (again)
We have an account with Socket labs, in case Google screws up sending mail.
We have too few legitimate origins for maintaining SPF to be a problem
This works, is robust, piss easy to manage and dirt cheap. 150 - 200 employee company.
You CAN'T reject based on SPF, as you have learned. You'll lose too much valid mail.
So the best you can do is use it as part of a spam-scoring system, like SpamAssassin. Unfortunately, anti-spam systems that try to assign a "score", or try to analyze mail content, are ALSO worthless. Spammers have *completely* figured out how to get past any anti-spam system that analyzes content.
The sad fact is that the only way to effectively stop spam is to pay for an anti-spam service like Postini (which is going away, I hear), or buy something like an IronPort.
Basically, professionally-maintained, commercial blacklists are the ONLY really effective anti-spam system. If you are doing anything else, you aren't doing enough.
Add DMARC to your processing (http://www.dmarc.org/). It's a 'yes, I really meant it' notification for senders to communicate to receivers.
Other than that, the other suggestions already posted are about as good as it gets: use SPF as one element in scoring a message. Mark the message if your e-mail system allows it (e.g. label:authenticated in green, or label:authfail in yellow).
Let us live so that when we come to die, even the undertaker will be sorry -- Mark Twain
We had the same problem.
Our solution: if the message makes it past all our spam filters and the only problem is that the sender's client isn't allowed by their SPF record, we send a friendly, plain-english informational message back to the sender, then deliver their message to our users.
"Please tell your company's IT staff that your mail server isn't set up correctly. This may cause your messages to be rejected or classified as spam. Please forward the following information to your system administrator: [SPF record] [sender's IP]. Thank you!"
That's nice if you don't rely on email for communication with your customers. Generally, customers (and potential customers) don't respond well to nagging -- especially if whatever you're asking is outside of their control. They may be too small to have anyone to complain to (and no idea how to fix it themselves), or they may complain to the corporate helpdesk who says "Nope, our server is set up the way we want it".
If I got an email like that from a vendor I was trying to reach, I wouldn't be doing service with that vendor.
One vendor that we were paying support to was trapping our entire domain's email in a spam filter - none of our emails could go through, we ended up faxing problem reports to them. This went on for 2 months before they finally admitted that there was a problem in their (outsourced) email spam filter, they ended up crediting us 2 months of our monthly support contract because their SLA promised 24 hour response to emailed support requests, and we didn't get any response at all.
Hells yes. I use postifx and reject connections that fail SPF with a 500 error. For example..
"550 5.7.1 : Sender address rejected: Please see http://www.openspf.org/Why?id=dassergey%40tadka.com&ip=103.22.182.230&receiver=mail.server.com%20:%20Reason:%20mechanism"
I have found that most senders just forward the bounce message to their administrator who (you would hope) have the skills to rectify the problem.
I also use DKIM http://www.dkim.org/ and DMARC http://www.dmarc.org/. They're worth checking out too.
We reject mails which fail the SPF check immediately within the mail session. That is the only safe way, because then the sender will receive a bounce message from his own mail server.
We never received complaints regarding SPF rejects, but maybe because we do not have large incoming mail traffic.
Even if there were false positives, it would not hurt anybody, because the sender is guaranteed to be immediately notified that his message had not reached its recipient. He could contact us using a different method, not mail - in addition to complaining to his (so called) system administrators.
Of limited usefulness. MD walks in "i'm expecting this email for a potential tender, the client tells me we are rejecting their email, and submissions close today!".
The MD receiving the odd spam is not a career limiting prospect. Missing a multi-million dollar contract due to non-delivery of business correspondence (or that reason being used as a scapegoat by your company's tendering department) potentially is.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
If a site publishes an SPF record, they have requested that you take the record into account when accepting mail from their domain. Especially if they publish it as hardfail, you should definitely bounce any hardfail. If their SPF record is broken, the onus is on their site to deal with it, so bounce at the MX.
Of course SPF filtering is not perfect; no one filter method ever is, thanks to all the badly configured mail servers out there. So, try not to build mail servers that reject incoming mail based on any one test, like one for SPF, or else you'll probably end up maintaining a lengthy whilelist, which will not only make you unpopular with the users, but is also a waste of time.
Instead, I built a mail system, using Exim (an extremely flexible MTA), that keeps track of a total number of 'strikes', as I call them, for positive scores for a number of filter categories, e.g. broken reverse lookup, bad HELO response, bad sender domain, blacklisted domain, no callout response, etc. Most of my filters are applied during the recipient phase of the delivery, before the MTA agrees to receive the message body (the data phase). If a message gets at least a certain number of strikes (in my case 3), it's rejected. If only 1 or 2, it ends up in the spambox of the intended recipient. These filter tests are separate from the ClamAV and spamassassin tests, both of which can still lead to an outright rejection.
In my experience, this method of counting strikes and using spamboxes to route messages to if they have only failed one or two filter categories has proved to be highly reliable and virtually maintenance free.
In other words you're generating soft bounces and making your server vulnerable to being used as an attack vector.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The idea is good, but in practice it's horrible. Here's what we do:
We never give a bonus to anything scoring SPF "pass" unless its from one of a few large domains that we know have good SPF records.
We add a small score (1 SpamAssassin point) for SPF softfail.
We add a moderate score in most cases for SPF fail.
For specific, often-phished domains like paypal.com and ebay.com, we add lots of points for SPF fail and softfail.
The only "false positives" is accepting SPF -all when that is the policy the domain holder has in place. If you're going to check the records, do it right and reject at SMTP time.
We use it - blocking on 'fail' and 'softfail'. We use ORF, and the SMTP response explicitly includes "Contact postmaster@mydomain for help if needed" (and we've configured ORF to always whitelist emails to that address irrespective of SPF status.)
Yes, the spec is a bit broken (softfail?) but it's wider accepted than DKIM.
We use Postini (now Google message security), and we turned on their SPF checks. Unfortunately, there are no knobs for this, so SPF pass is "good", SPF softfail is "bad", and SFP fail is "always quarantine, even if the address is whitelisted".
Despite some high-profile mail getting snagged by this, we educated our users and let them know that while we're more stringent with SPF than most places, it's not "our fault" that other people can't configure their domains correctly. After an initial spate of 10 or so messages where we had to call other IT departments to set them straight, it's more or less died down now and our users know how the problems get resolved.
We also created this page to send to the e-mail originator, so we didn't have to craft well-thought-out e-mail responses each time:
http://web.suffieldacademy.org/~jhealy/spf.html
All of this makes for a little more work for us, but it has cut down on spam. Also, it makes the internet a little better of a place as we slowly drag other domains into compliance by catching their mistakes. ;-)
For the past year, one of our business domains has been a patsy for a continual bombardment of spam against the internet. Typically our catch-all account would receive at least 200 bounce back failures a day. Since then, we enabled SPF on our domain and it drastically increased the amount of bounce-backs considerably... which is good, as it means less people are seeing our domain in a malicious light as they're immediately denying the spam as it's caught by an SPF filter before it goes through other filters.
I encourage all mail server admins to enable SPF to hamper the ability of spammers to hit their targets.
Please don't do this. One of the problems SPF solves is that spammers pick some random domain then spoof emails from that domain to send to millions of people. If you happen to be one of the unlucky people whose domain is targeted, you get a million bounces in your inbox.
The whole point of SPF is that if an email fails an SPF check, the email may not have come from the purported sender, and you should not treat it as genuine. You're completely undermining what SPF is for by doing this.
Bogtha Bogtha Bogtha
I find that usually Aveeno works the best, although Burt's Beeswax has some more natural ones that are better for the skin.
For those of us in the rest of the universe, what the H* is "SPF"? Sounds like some kind of inaccurate Spam Filter. ("FPS" is First Person Shooter games where you shoot at the enemy; maybe "SPF" is where the enemy shoots at you?)
SPF's great benefit is protecting your users against phishing attacks. Common phishing targets such as Paypal, eBay and Gmail, as well as banks and other finance organisations have very well managed SPF records. The onus for ensuring SPF records are correct falls on the sender, not the recipient. If someone inputs an SPF record for their server, then sends an e-mail via a different server you're doing exactly as requested by blocking the message. Problems of misconfigured SPF records will ease once more organizations implement it aggressively so that administrators will not be able to assume their mail is flowing correctly when delivery is initially successful to a few lax servers.
Relying on any form of email for multi-million dollar tender delivery is the career limiting move here.
Patent litigation: A doctrine of Mutually Assured Destruction... in which everyone seems willing to push the button
I havent seen it in a while, but for a while we kept having issues with some implementations of Exchange refusing email based on our perfectly valid SPF records. The problem only occurred if we had both SPF AND SenderID (M$' so called "SPF 2.0") records for our domain. If we deleted our SPF records and only left the SenderID record, the mail would be delivered.
Way to go Microsoft in taking a perfectly good standard and deciding its not QUITE good enough and muddying the waters with your own crap.
You can use SPF as a hint. A bad SPF record could trigger longer greylisting delay, therefore lowering the ability of a spammer to reach destination before been known by blacklists. milter-greylist allows such setup.
Something to keep in mind is that SPF isn't intended as an anti-spam technology, it's intended as an anti-spoofing technology, and it only really applies to the email envelope HELO/EHLO and MAIL FROM fields. The idea behind SPF is that if you have a valid SPF record, some third party shouldn't be permitted to send mail that claims to be you at the envelope level. However, that doesn't prevent someone from claiming to be you in the FROM field which normally isn't validated by SPF. In addition, there's nothing preventing a bad actor from setting up his own spam domain with a perfectly valid SPF record and spamming the heck out of you, and all their spam will pass SPF just fine. DKIM isn't much help either because that just validates that the mail hasn't been modified since it was originally sent, it makes no judgement about the quality of the content. DMARC is actually your best bet as an anti-spoofing technology, as it's designed to validate the authenticity of the email address' domain displayed to the user in the FROM field using SPF and/or DKIM, but again, it says nothing about the quality of the content. Even so, DMARC runs into issues because it can't validate the sender information that most email clients readily display, the so called from or pretty name. We get mail all the time from a major ISP's mail server that passes the various authentication acronyms, yet the pretty name claims to be another company's billing department. Also, many many forwarders, mailing lists, and social group services will break/violate one or more of these various schemes - so you need to keep that in mind as well. I can tell you from personal experience that SEVP's don't like their Facebook mail being dropped on the floor because they're using an imperfect forwarding service. "But Sir, Facebook says to reject it based on their DMARC policy!" doesn't work as a get out of jail card :-)
Email is normally considered more reliable than fax or mail, and it's much faster too. We typically sign things and run them through our copier, which emails out a scanned image of the document that we can forward on. As a bonus we can make sure that the signature was visible and the text legible.
The point is that it has to be that reliable because there is an expectation of reliability for a tool that people use more often than the telephone.
Sure. But shit rolls down-hill, and it's not the MD who's going to get fired.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Put it this way - in an ideal world, I agree with your premise. But the reality is that people expect email to work, and don't care WHY it failed. The fact that you bounced their legitimate correspondence is unacceptable to the business side of the company. The one that brings IN money.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
In other words you're generating soft bounces and making your server vulnerable to being used as an attack vector.
Nope, we do limits - one message per week per sender. So no effective attack vector.
The whole point of SPF is that if an email fails an SPF check, the email may not have come from the purported sender, and you should not treat it as genuine. You're completely undermining what SPF is for by doing this.
Yeah, if everyone did this it would be bad - zillions of polite informational messages. You make a good point.
On one hand we're a small shop with a low-traffic email server. We've had good success getting sending domains to fix their record. On the other hand, perhaps we should go back to passive mode. I'll mention it to the system administrators.
If I got an email like that from a vendor I was trying to reach, I wouldn't be doing service with that vendor.
One vendor that we were paying support to was trapping our entire domain's email in a spam filter - none of our emails could go through...
I see what you're saying. Just wanted to emphasize that email messages are never dropped in our system, they are always delivered. The SPF check is still part of the spam checks, but by the time we get to the "send informational message" stage we've already decided the message isn't spam. We also check the sending IP against the Backscatterer RBL, which hopefully keeps us from sending to domains that have been hijacked.
The informational message is only sent once per week to any given sender. We do have an "don't email me about this again" link in the email. Finally, we don't send the message to anyone sending from a rather large commercially-maintained list of known webmail address and ISP mail servers, which exempts a large portion of senders from ever seeing the message (these users can't do anything to fix a broken spf record).
SFP is not an approved RFC so you don't implement it in a production environment.
It is better to reject it at SMTP level and let the sender know about the fact immediately, instead of scoring the message low and lost in the spam folder, and the sender has no idea if it reached the recipient.
So you get hit with a 10.000 address spam run.
Are you still contending that you are not a nuisance?
Shut. that. system. down.
"I know I will be modded down for this": where's the option '-1, Asking for it'?
So, basically you admit to spamming people.
That's what I thought... Only spammers like SPF, because they can get their spam messages whitelisted on their own control. (I used to work at a spam company, and we had SPF and DKIM on every spam mail we sent out).
Except that email is commonly used for such. I have negotiated contracts worth hundreds of thousands of dollars by email. (not yet multi-million, but well on my way, nonetheless)
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Antispam measures are effective only when methods are combined, with no single method being more important than everything else.
Also, graylisting in front of your mail server is one of most effective methods to defend. Legitimate mail infrastructure will rarely (if ever) use different IP address for every delivery tried.
Graylisting, combined with RBL, combined with spamassassin (with SPF and most other methods used through it)... And you have decent solution. What remains is to define your policies and your spam problems are terminated, for looong time.
http://opencm3.net, http://www.nongnu.org/gm2/
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(X) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
(X) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
(X) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
(X) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
(X) Countermeasures must work if phased in gradually
( ) Sending email should be free
(X) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
(X) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Not only I use SPF, but I also maintain the tumgreyspf package in Debian, which does both SPF and greylisting.
And for those who have bad SPF records, and send email from the wrong IP? Well too bad, they wont be able to write to me. But as well to so many other persons (gmail, hotmail, etc.) that it's not really a huge concern, and that I don't feel like I should be the one having to spend the time explaining how to configure things.
Is the sender IP whitelisted? Allow.
Is the sender IP not presenting a valid reverse DNS name? Block.
Is the sender IP listed on SpamHaus? Block.
Does the sender IP not match the domain SPF record (even soft-fail is a fail)? Block.
Is the sender IP not retrying after being told to try again in five minutes (greylisting)? Block.
And then you can do things to do with the actual message itself, like DKIM signing, spam-detection, etc.
Instantly cut out 99.9% of your spam, and at the same time anyone who fails those tests isn't running a mail server worthy of the name in this day and age. If your ISP even ALLOWS you to send email from an address without a valid reverse-DNS, for example, I'd question what the hell they are doing with their systems or why they expect customers to be able to email at all without being blacklisted by someone.
Anyone who can't pass those tests isn't going to be able to send email to anyone else anyway. It won't just be your company, but almost everyone they communicate with (Google, etc. pretty much do the same run of tests on your name, if not more strict!). And if they aren't bothering to keep their SPF records up to date, I'm surprised that they get mail sent at all.
But don't, under any circumstances, accept the mail for later delivery. Reject it there and then. Don't faff about wasting resources, providing "proof" that the email was received to the sender, or storing things up that you then aren't sure you should deliver.
In the small businesses I've set up with email, this literally cuts 99.9% of all spam, and the number of false positives is effectively zero (and usually, as you say, due to idiots not setting / updating their email / domain properly). And when one of those botnets gets hold of your domain and tries to spam you with hundreds of connections a second, you can work through them easily without having to worry about them ending up in mailboxes.
This is the default setup for things like Postfix on most Linux distros, for example. I fail to believe that those defaults are changed by everyone who sets up a mailserver, or that setups that DON'T confirm to those tests actually send much email to anyone without having problems.
And, if you really, really, really are a small business that has problems that you can't get around by just using your ISP's recommended method, sticking Google Apps on a domain, or renting a £10/month VPS that does it all for you - WITH THOSE DEFAULTS, and more - is literally chicken-feed for communicating with customers and suppliers.
If they are idiots, that's their problem. If you want to accept and deliver email that's quite obviously spoofed because you're afraid of catching up their emails by mistake, that's your problem. Only one of those types of problems can be fixed.
If it comes to it, and you hear complaints from those companies, just whitelist their domains if their business is that important to you. But if they can't even be bothered to work out why, I would guess, at least 10-50% of their email just bounces or never gets to the other end, there's nothing you can do about that.
I've got a spam filter with a relatively high reject score on my incoming mail server. It rejects the most blatant spam with a reply note. All the clients have a spam filter with a much lower reject score, filtering spam and possible spam into spam and quarantine folders. This leaves it up to the user to accept or reject. This seems to have worked very well over the last couple of years.
If you have correct SPF, you will most likely get more spam. Why? Someone spams mailservers with your domainname, then it bounces because of failed SPF, and many mailservers are configured wrong, so you will get backscatter spam.
The irony of this is, that SPF says "it wasn't me" and the wrong configured mailservers then send YOU an answer saying "hey, we're not accepting your mail, because your SPF says it is not your mail".
If the problem, as the original poster put it, is that many legitimate senders have not configured their SPF records properly, (or maybe they did, but then circumstances changed and the SPF record was not updated,) then it seems to me the most sensible fix is for *sending* mail transfer agents to double-check SPF records before sending mail. This could be very low-impact, since most mail servers only *legitimately* originate mail for a handful of domains, and they would only need to verify the SPF records infrequently (once and hour? once a day?) If only a handful of common mail servers were modified this way, most of these configuration problems would be self-corrected at the source, almost immediately.
On the server side, if you are asked to send mail from bob@example.com, you lookup the SPF record for example.com and see if you are allowed to send this mail. Then, what you do with this information is up to the admin who installed the mail server, but some options could range from:
* Brute force: Reject the mail, bounce it back to user with explanation
* Accept the mail but reply to the user with an annoying message letting them know that their mail server is misconfigured and the recipient might not get it, and suggest they get their mail administrator to fix the problem. [you could even include helpful links to some SPF-help websites right in the mail to reduce the activation energy for the sysadmin] -- this could be done for every bad message, or maybe for every N bad messages for each domain.
* Same as above, but also rate-limit any outbound mail that fails the SPF check, which might also reduce SPAM you are unintentionally forwarding and make you useless to spammers.
* NAG the admin: Log the error or email to postmaster@yourdomain, or post to his facebook account explaining to the world what a moron he is. :^)
*
In a world where all the legitimate mail senders automatically verify their SPF records from time to time, it seems to me that pretty soon you *could* move to a model where you drop all non-SPF conforming mail, and miss out on very little.
Here's the problem, and it's a fundamental problem with the SPF framework, as a business process. The consequences of error should reside with the entity that has the most direct control over what causes or prevents that error. What is happening here is that Entity A has their SPF set up wrong, but potentially all the impact could land on Entity B. SPF isn't rocket science, but it's the kind of thing that needs to be checked periodically and tied tightly into change control processes...in other words, a perfect example of a system that will have issues, in modern IT environments. I don't really have a suggestion, other than a standardized process for detecting events like this and reporting them to the sending organization. But it's hard to notify a company to let them know that their website has been hacked; I imagine it must be horrendously hard to find whomever is in charge of their mail infrastructure to point out to him that he's doing SPF wrong.
For your security, this post has been encrypted with ROT-13, twice.
That is what we do. Everyone knows they also need to check that folder for legitimate email - by doing this, the bulk of the spam doesn't get in the way of real work that makes it to their inboxes. The subject line of all SPF failed messages has "SPAM message - no or invalid SPF" appended, so that when the user replies to the sender, they get an indirect but nice hint that they look like a spammer.
Since I'm in IT, and most of my correspondence is with IT folks, I'll often send an extra nice email like "oh and by the way, your SPF is wrong so you look like a spammer". Most people get the hint. :)
Ha ha. Try telling that to the VP who does exactly that. Your career is limited.
Please, please don't do this. You take SPF, designed as a defensive shield for you, turn it into an offensive weapon and unleash it on an innocent victim every time you send out a "friendly" message like this. Please turn this off now and then Google "joe job" to learn how you are making the problem worse, rather than addressing it in any meaningful way.
Ignore SPF if you like, but don't use it as an method to select targets to attack with "friendly fire."
definately a +1
nosig today
The short answer is: If you tell us that an e-mail from you is not to be trusted, we will honor that request. But if our system falsely catches an e-mail from you, say because of a bad SPF record, we will whitelist that sender.
We have a custom system I built and haven't yet had time to polish for a open source project (and it needs it before it could be publicly released). It has an awesome feature though...
Messages are rejected at the SMTP level, for things like SPF, greylisting, and SpamAssassin. The bounce message has a URL that the sender can visit to release the message. I was anticipating this might get abused and have to have a captcha on it, but so far it has not. Actually, it's worse than that, 99+% of people who get this message don't read any further than the subject, which is generated by their mail server, so they usually contact us some other way saying "Your mail server is broken".
BUT, the killer feature is that our users can go to a website and see the messages sent to them, and "release" them. So if you are looking for an important message no problem! You go to that page, type Control-F and the sender name or subject you are expecting, and click a button, and you have the message. It's kind of like a quarantine, but it's controlled by the sender AND the recipient.
Now, as far as what we do about senders that have broken SPF... We add them to a whitelist and tell them "You've been whitelisted, but your domain is publishing a notification that says this e-mail is invalid, you probably want your mail server admin to fix this because other places are honoring this as well."
No big deal, not ideological stands, we just deal with it and report it on.
Because that's the crucial thing: Your domain is telling me that this e-mail is not to be trusted. The CEO of our company understands that yelling "You can never have a false positive" means that they are going to have to deal with an inbox full of sewage -- they understand what false negatives are.
Sean