Ask Slashdot: How Do You Handle SPF For Spam Filtering? 187
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?"
don't reject based solely on SPF (Score:5, Insightful)
Or anything else, for that matter--mark it as "spf failed" and score it as you feel appropriate for your filtering setup.
Re:don't reject based solely on SPF (Score:5, Insightful)
This.
If email filtering was as simple as dropping non-SPF approved mail, spam would not exist. There is no single silver bullet in the war against spam. And besides, when domains cost a couple of dollars to register, it's entirely possible to set up an SPF enabled domain and spam from that.
Re: (Score:2)
You're supposed to combine SPF with DKIM so that you know who is sending messages from where. The point isn't to kill spam completely, just to make it as inefficient as possible. If you make it inefficient enough that they're all losing money, they'll move onto another scam.
Re: (Score:3, Interesting)
When I worked at a spam company (I got hired to write software to handle 20 million mails per day on a single server - not proud of it, but I needed the job), we had SPF and DKIM on everything. Except the corporate exchange server, at least for a while. But the spam mails, having both SPF and DKIM on those was very important.
Ever since, I've considered blocking mails with SPF or DKIM headers. Only spammers care enough to set those up correctly. And a few of the big mail companies (like GMail and Hotmail), b
Re: (Score:2, Insightful)
And in the meantime SPF breaks mail for everyone whose email address is not hosted on the domain of the sending server. In other words, everyone who wants to send mail from their home PC with the From: address set to their webmail address through their ISPs mailserver.
If a technology breaks mail so fundamentally that an end user using best practices gets their email rejected, then the technology is broken.
Don't use SPF. It breaks mail.
Re: (Score:2)
What you describe is NOT best practice for email. Spoofing the sender address is not best practice.
Re: (Score:2)
you say it: best practice.
This means, there are other practices (for a reason). They might not be the best, but in some cases they are needed. strict SPF filtering breaks them.
Re: (Score:2)
Using your ISP mail server for outgoing mail is Best Practice.
SMTP is supposed to be agnostic as to the sender. This is not spoofing.
Re: (Score:2)
If a technology breaks mail so fundamentally that an end user using best practices gets their email rejected, then the technology is broken.
Don't use SPF. It breaks mail.
If a best practice turns out to be an impediment in solving one huge aspect of an enormous problem (namely joe jobs), then this practice has outlived its usefulness.
Do not spoof sender domains. It breaks mail.
Spamassassin (Score:5, Interesting)
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 [apache.org] 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.)
Re: (Score:3)
Yup. We run SpamAssassin along with ClamAV and postgrey on top of Postfix to filter all the incoming mail and it does a pretty good job. Here and there a spam will get through, but I can look at my logs to see all the rejections. It's not rocket science, and the solution has been tested and proven for over a decade now.
Re: (Score:3)
My personal experience was postgrey alone knocked out 99% of spam as the spam sender never retries regardless of error message type.
Re: (Score:2)
Just the default tools included with a big package like Zimbra have done a marvellous job stopping spam from reaching users on my server. After training them to mark spam in the webmail the filters have learned enough to outright reject nearly all spam, but you're right Postgrey can really help. I ran it when I used a simpler setup with Postgres, Dovecot and Roundcube, and we enjoyed a very long period of sweet, spamless service. Then more spam started slipping through at some point.
After I moved to Zimbra
Re: (Score:2)
I think this makes sense where your organization cannot devote additional resources. However it's important to work out how much staff time is wasted by your spam volume.
Personally I would reject if the sending server lacked a PTR record, or if the PTR record was invalid, or on SPF failure. I use templates to quickly reply where someone had trouble contacting us, directing them to contact their IT department and referencing RFCs where necessary. Even large ISPs would get it wrong sometimes, but invariably f
Use it for scoring, not blocking (Score:5, Informative)
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.
Re:Use it for scoring, not blocking (Score:5, Informative)
Re:Use it for scoring, not blocking (Score:4, Interesting)
Less expected by whom exactly? I was part of the major discussions a decade ago surrounding SPF and there was a large contingent of damned good mail admins and SMTP experts who said the whole thing was flawed.
Re: (Score:3)
After reading the comments here, it is obvious that there is one and only one significant issue with the SPF system: 95% of system administrators do not get it. I try to clean things up (therefore it will be long, and nobody will read it, but anyway...).
First of all, fortunately, SPF is very simple to implement it, so most admins do no harm, even if they do not understand it.
Nor they get SMTP. Specifically the most important promise of SMTP: Your mail will be either delivered, or you will get a notificat
Re: (Score:2)
SPF was broken from the start but it was a step towards a better solution.
I liked the idea of using dns or snmp to ask the server that should have sent the message "did you send message id foo_xyz? That alone would have fixed a massive amount of spam if you tie it back to mx records of what should be sending the messages.
Re: (Score:2)
MX are for inbound delivery. SPF are for outbound authentication so it is even a different concept. MX records are nearly required for mail yet SPF isn't and will never be so the only authoritative way to find out if a server is involved with mail at this point in time is to look at an MX record... which is pointless for any real verification of an outbound message.
The asymmetrical nature of email has always been the problem that will always allow spam. The only real fix is to force the inbound mail serv
Re: (Score:2)
The distributed authentication tools that use cryptography that would be required to be deployed are illegal in many parts of the world so I don't see that as a decent solution to the problem.
whitelist (Score:4, Insightful)
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.
Re: (Score:3)
We don't reject, but we send some "helpful info" (Score:4, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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 "
Re: (Score:2)
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.
Re: (Score:3)
Relying on any form of email for multi-million dollar tender delivery is the career limiting move here.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
In other words you're generating soft bounces and making your server vulnerable to being used as an attack vector.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:We don't reject, but we send some "helpful info (Score:5, Insightful)
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.
Re: (Score:2)
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.
Google does whatever it does (Score:2)
Thanks, Google!
I can't be bothered to run my own damn SMTP/IMAP/etc any more.
Re:Google does whatever it does (Score:4, Insightful)
Did you know? (Score:2, Funny)
DMARC (Score:4, Interesting)
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.
SPF is worthless, unfortunately (Score:2)
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,
Re: (Score:2)
I've been on the wrong end of a few of those since I have a mail server on an address that used to be a dynamic address something close to ten years before I got it and it gets blacklisted every now and again when people accidently dredge stuff out of old lists. To sum up those events, commercial rarely means "professionally-maintained" with spam blacklists.
Re: (Score:2)
I manage to cut over 75% of spam before it gets to content filtering by greylisting, and the spamhaus zen block list. The vast majority of spam doesn't even get to my content filter.
No, it's not perfect, but if your boss isn't willing to shell out for an ironport or you're trying to do it yourself, cutting 75% out before it even sends the content to your server is a win in my book.
Re: (Score:2)
> spamhaus
do not use them. they are making money with unblocking. so potential clients are not reachable, just because spamhaus blocked them and they do not even know it (or do not see the point in paying for the spamhaus blackmailing)
DMARC... (Score:2)
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).
Reject them immediately (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
This; a thousand times this.
If I issue a 250 Queued response, it means that the email coming in is actually going to be deposited in a user's mailbox, otherwise the sender is notified by some component of the sending mail system.
Not only does this make the failure message itself more reliable, but it makes the sending user more likely to complain to his/her own IT department, as that's where the bounce message will likely be sourced from.
Re: (Score:3)
When a forwarder - actually any SMTP server - accepts a mail, than that means that it accepts the responsibility of either
1) delivering it, or
2) notifying the original submitter about the failure.
If a server fails to fulfill such a basic requirement of the SMTP protocol, than it is not an SMTP server, and anybody who depend on it is in serious trouble. And this is completely independent of SPF.
Regarding getting complaints: we have phone numbers and HTML contact forms. Our postmaster account is monitore
Re: (Score:2)
Maybe you should read RFC 5321 more carefully:
"In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting
Re: (Score:2)
There is no guarantee that any bounce message will be received by the sending party.
No, there IS a guarantee that the bouncing message will receive the sending party. That is a basic requirement of the SMTP protocol.
Otherwise the sending domain in question has not only messed up its SPF records, but in addition it has a horribly broken mail system too. Maybe it worths keeping a safe distance from them. :)
Seriously, if we meet somebody with
1. broken SPF record and
2. broken mail system and
3. never noticed the above previously and
4. send us an important message and
5. negligent enoug
Re: (Score:2)
If you are talking about your customers, than you set their SPF record correctly, do you? So their mail will not bounced by others. If they want to use random email servers of the world, than you setup an "allow all" SPF record for them. Or you do not setup a record, but I think in this case you are doing a disservice to them, because their mail will be more suspicious. And no, if a domain has no SPF record, then its mails will not be rejected by any SPF compliant mail server.
Regarding spamassasin: that i
Try not to rely on true/false spam filtering (Score:2)
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 t
SPF Sucks (Score:2)
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.
Educate your users, and SPF mungers (Score:2)
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
Think of the senders! (Score:2)
SPF is designed to be implemented aggressively (Score:2)
Dont forget Microsoft's lame attempt (Score:2)
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.
Use SPF as a hint (Score:2)
SPF only a hint, graylisting a must (Score:2)
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
Yes, I do use use SPF and tumgreyspf even (Score:2)
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.
Standard practice. (Score:2)
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 th
More spam because of SPF (Score:3)
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".
Consequences vs. control... (Score:2)
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
Re: (Score:3, Insightful)
Some would say you are doing a disservice to your customers by continuing a practice that is hurting their business in an effort to promote a technology standard that is not working.
Re: (Score:2)
Some would say you are doing a disservice to your customers by continuing a practice that is hurting their business in an effort to promote a technology standard that is not working.
Others would say you are doing a disservice to your pocketbook by turning away mail just because your customers aren't always up to speed, or have contracted their mail handling to someone else.
Re: (Score:2)
Re:Do the right thing (Score:5, Insightful)
Anyone who understands SMTP and spam knew from the very moment that SPF and its cousins/descendants were proposed that it was a hopeless measure. That, after ten years, guys like me are still having to explain "setting your SMTP server to reject because of SPF" tells you just how badly SPF failed.
Re: (Score:2)
Some would say you are doing a disservice to your customers by continuing a practice that is hurting their business in an effort to promote a technology standard that is not working.
SPF not working? - Seriously?
If we didn't have the fail-open option of allowing mail from senders with no SPF, it would be a flawless system that would block all spam.
I do occasionally get spam through hacked gmail or yahoo mail accounts and while they pass the SPF check, they don't pass my spamassassin though, and I've added a penalty score to all mail from those and similar email providers. No enough to block all mail but if the mail posses other spam characteristics, it will be blocked. And no serious 'p
Re: (Score:2)
So if I am working from home, how do you propose I send mail using my corporate address? With strict SPF, the old Best Practice, handing it over to my ISP relay, breaks.
If your answer is to set up a VPN to work, I say fuck that shit. SPF is a broken solution searching for a problem.
Re: (Score:2)
It's called the submission in SMTP, your company has to setup a MTA to accept authenticated TLS connections on port 587 (or any other than 25) to relay "its email domains" to the outside world via a SPF allowed host. That is a one time setup for you corporate email profile/MUA.
Re: (Score:3)
Re: (Score:2)
This. If an admin like the GP is so high and mighty about DNS records meeting RFC compliance (You do listen for DNS on both UDP and TCP right? And you've signed your domain with DNSSEC?), you can at least do your SMTP services correctly too. Asking for an authed SMTP submission session for each domain is now the correct best practice. Unauthed SMTP relays are a dying breed.
You can also allow relaying by source IP. It might make sense in some setups. Given the choice SMTP AUTH is the right way to go though.
Re: (Score:2)
No, the answer is work sets up an authenticated SMTP server that you can tell your mail client to use for email for that particular account. It's not hard to do. I have it set up for my own mail system - whether I'm on a 3G network in Timbuktoo or at the office on my office PC, outgoing mail goes through an authenticating SMTP (SMTP+TLS, actually - sending credentials in plain text is not good practice) which I control, so the sending SMTP server is always allowed by my SPF record.
No need to set up a VPN.
If
Re: (Score:2)
So if I am working from home, how do you propose I send mail using my corporate address? With strict SPF, the old Best Practice, handing it over to my ISP relay, breaks.
If your answer is to set up a VPN to work, I say fuck that shit. SPF is a broken solution searching for a problem.
The 'right' way is to VPN to work or send it though your works mail server in some other way. Otherwise it's just mail with a faked sender that could be from anybody.
Or you could add your home IP to your work's SPF record but that's pretty ugly.
Re: (Score:2)
Congratulations, you just advocated breaking ISP mail relay.
Re: (Score:3, Insightful)
That works fine until the CEO misses an email from a prospective client.
Re:Forget about them (Score:4, Interesting)
The way I do is is that I send an NDR on rejected mail caused by bad SPF records (with some anti-flood limits). So far, as far as I know, bounced emails always eventually reached us. What happens is the person gets a NDR mail ("We have rejected your email due to bad SPF records"). The person getting the bounce forwards it to their IT dept, where it's usually taken care of rather quickly. If it's a small business without a dedicated IT staff, I'm sometimes asked to explain how this works, but usually, such companies do not have SPF records at all, which means the mail won't bounce.
Re: (Score:3)
you are destroying the sense of SPF.
consider someone spams you from a faked domain (the thing spf should prevent). Then you send backscatter-spam to the real domain.
fail.
Re:Forget about them (Score:5, Insightful)
That works fine until the CEO misses an email from a prospective client.
Unless you plan to profit from stupidity, that prospective client is worthless if they can't even set up a functional SPF record. Either you're too stupid to know about SPF or you do it right. Everything else is dumb beyond reason.
Lots of people are dumb as a brick when it comes to IT. Some of these people manage mail servers and DNS servers. Some of them want to buy stuff from your company. This makes their stupid misconfiguration your problem. Much though I'd enjoy burning these morons at the stake you can't burn your customers alive and expect them to keep buying from you. ( Unless you are Microsoft. )
Don't block on SPF - Use it as part of a spam scoring system.
Re:Forget about them (Score:4, Insightful)
If they are too stupid to set it up correctly, then they aren't the fools whom you are supposed to part with their money?!
"Too stupid" is exactly the kind of person I'm looking for!
It's the smart people I don't want to hear from. You know the people I'm talking about: the ones who are so smart that they don't have to work, they just program their botnet to send viagra spam and sit back and collect the money. I admire them, but they're useless to me.
Re: (Score:3)
Because of course SMTP administration competence of the company's (possibly hosted) email is directly proportional to competence in the field the company works in.
Pull your head out of your arse - in the real world, businesses need to communicate.
Re: (Score:2, Insightful)
Yup, pretty much. If you walk around - alone - wearing an "i'm with stupid" t-shirt, I don't care if you make Stephen Hawking look like Forest Gump, people will steer clear of you.
Pull your head out of your arse - in the real world, businesses need to communicate.
Yes. Yes, they very much do. And if they don't take that function serious
Re:Forget about them (Score:5, Funny)
If you walk around - alone - wearing an "i'm with stupid" t-shirt, I don't care if you make Stephen Hawking look like Forest Gump, ...
Oh come on! Forest Gump would run circles around Stephen Hawking, any day of the week!
Re:Forget about them (Score:5, Insightful)
Yes, people would steer clear of someone who looks superficially stupid, that is a given. That isn't a defense of why you should steer clear of such a person though, especially if their skills and services are of particular use, or if they are a potentially big customer. By rejecting providers, you are going to tend to pay more for services because now you only look at a subset of potential providers, or by rejecting customers, you are rejecting sources of income. Either way, there is a cost associated with that. If it turns out it only costs you a couple hundred dollars in the long run, then maybe it is worth the saved effort by your IT department. If it is going to cost you much more, is it really worth it? How many thousands of dollars in extra costs or lost revanue is acceptable because you don't feel like dealing with such people?
It reminds me of when a coworker once started up a simple online store in his free time and offered me a bit of money to look over the front and backends while he still learned web development. I found out his website redirected IE users to a page telling them to get Firefox and didn't let them get to the actual store. As this was around 2005 or 2006, the logs showed that 90% of his traffic was being redirected to that page, including cases of people trying multiple times to get back to the product list. His response, "I don't want to deal with people too stupid to use IE, and I would have to waste time to make my site work on IE too." My response, "First, if I copy-paste your pages, they completely functional in IE as is. Second... you sell hot sauce, what do you care what browser people use?" He just brushed it off, and continued to insist that he didn't want to bother with such people. Considering he was able to get a couple hundred dollars a month after a bit of local promotion, and assuming there isn't some massive correlation between browser use and hot sauce purchasing, he chose not to turn that into couple thousand dollars a month over such superficial, trival BS.
So, exactly how much money would you give up because you want to tell a customer, "Sorry, we don't want to accept your email," even if your business dealt with products that has nothing to do with email otherwise?
Re:Forget about them (Score:5, Insightful)
And meanwhile in the real world where nailing some important email because the sender was sending all his email through a local MTA because his ISP doesn't have an externally accessible MTA, your boss is right now handing you your walking papers.
The only sane way to use SPF is to drop a spam score of an email. Outright filtering on bad or missing SPF records is just a recipe for a large number of false positives.
Re: (Score:3)
This. SPF is fine as something you can use to tag messages and increase their filter score. If they lack a valid SPF there's a slightly higher risk it's spam. But to block based on SPF records is just goofy. It's a good idea, but nowhere near universally adopted and there's plenty of valid reasons why mail would go through a different source.
On my own mail server, I add 1 to the scoring, with tag at 3.5 and block at 5.5. Those have worked pretty well (I use Kerio Connect, which has a Spamassassin-based syst
Re: (Score:3)
Huh? SPF implementations do not filter on a missing SPF record. A missing SPF records just means that, the sending mail servers of the domain are not specified. It never meant that the domain must not send any mails from any servers.
Quote from openspf.org [openspf.org] :
"The domain does not have an SPF record or the SPF record does not evaluate to a result. Intended action: accept"
Re:Forget about them (Score:4, Informative)
I don't think you know what SPF is or how it works.
SPF specifies, by leveraging the DNS, which servers are allowed to send you mail from that domain. The problem it addresses is "spoofing" - I send an email to your servers claiming to be from you. If you have a SPF record, you can say servers x,y,z,a-c are allowed to send email claiming to be from foo.com.
There's three possibilities:
1) No SPF record - process normally
2) SPF record, sent from valid host - generally downweight spam score, since verifiably the server that sent the email was in that organization
3) SPF record, sent from invalid host - the subject of this Ask Slashdot. It should be "always bad" but Incompetent admins set up SPF, then get it wrong or don't update it and mail bounces. Hence the problems discussed here.
"sender was sending all his email through a local MTA because his ISP doesn't have an externally accessible MTA" - no problem if the SPF record is correct. Or if you can't be bothered to do that, just get rid of it.
Filtering on missing SPF records is stupid. Filtering on bad (i.e., sending host was marked as disallowed) SPF records should be 0% false positives, were it not for idiot admins - again, the subject of this AS
Re:Forget about them (Score:4, Interesting)
And meanwhile in the real world where nailing some important email because the sender was sending all his email through a local MTA because his ISP doesn't have an externally accessible MTA, your boss is right now handing you your walking papers.
The only sane way to use SPF is to drop a spam score of an email. Outright filtering on bad or missing SPF records is just a recipe for a large number of false positives.
You don't know how SPF works, right? - Because that would excuse your statement...
Basically, SPF is a fail-open system:
A) No SPF: Allow the mail (fail-open)
B) SPF present and the mail fails the check: Refuse the mail
C) SPF present and the mail passes the check: Allow the mail
Option B has an exception for 'soft-fail' if the SPF uses the ~all. It will allow all mail through but tags those that fail SPF.
There's absolutely no reason not to refuse mail if the SPF check fails.
Remember, an incorrect SPF will result in a lot of mail lost, and it won't take many minutes before this is noticed. The fastest way to fix it is not to contact every single communication peer and have them bypass their SPF check; it is of course to just fix the SPF record. A 10-second dialogue with a competent postmaster at just one of the failed recipients should yield the reason for the fail, like the missing mail source. All that's left is to fix the SPF by adding the relevant "a:xxxxx.xxx" or "ip4:xx.xx.xx.xx" to the record.
Re: (Score:2)
There's absolutely no reason not to refuse mail if the SPF check fails.
Yes there is. As other people have pointed out bad admins set it incorrectly every once in a while. Companies change their ISP and forget to update DNS, or alter their internal setup so the mail hits the internet from a different IP.
Re: (Score:2)
There's truth in that, sadly. The only rejected mail I've sent were spam reports via SpamCop to a notorious company, who rejected it because of SPF errors.
Re: (Score:2)
And meanwhile in the real world where nailing some important email because the sender was sending all his email through a local MTA because his ISP doesn't have an externally accessible MTA, your boss is right now handing you your walking papers.
Or you are handing your boss walking papers because that business you just missed out on was the difference between profit and going bust.
The only sane way to use SPF is to drop a spam score of an email. Outright filtering on bad or missing SPF records is just a recipe for a large number of false positives.
That's what I've said twice already in this thread. I don't think its a large number of false positives but there certainly are some.
Re: (Score:3)
SPF means the sender's domain admin EXPLICITLY configured their domain to advertise a "drop messages that didn't come through X MTA".
User of that domain should be informed of this, and if important emails are lost due to bad SPF records, then it's the admin (or part of the sending organization's) fault.
Re: (Score:2)
If they are too stupid to set it up correctly then they don't deserve to work with you.
100% right but still missing the point.
There are people running mail servers who should not be, they don't know what they are doing or they don't spend enough time getting it right. As a company you can't reject these mails because they could be worth real money. There are jokers in the world and us hard working people have to make allowances for them.
Just use SPF as part of a spam scoring system, but never to outright block mails.
Re: (Score:2)
Re: (Score:2)
Spam from Iran? Strange. I checked my last four spam mails: 1 China, 1 France, 2 USA.
OK, it is a pathetic statistics, but still... The country is based on IP address of the server which directly connected to our server, and I lookud up the IP address on ip2location.com.
Re: (Score:2)
Re: (Score:2)
Most spam I have to deal with comes from US, although Japan has increased its proportion of spam recently. I keep reading people complain about spam from China and eastern Europe, but I never receive much of it. I still think it's a case of racism causing blindness.
Re: (Score:2)
SPF means Sender Policy Framework [openspf.org]. It is a method to specify and check the precise list of servers which are allowed to send mails in the name of a domain.
Receiving servers use it to check the validity of the reverse-path of the mail. Reverse-path is the address to where bounce messages should be sent.
It is nothing more, nothing less. It causes great confusion because many thinks that it is intended to be a final SPAM prevention method, when it is clearly not.
Alone, it makes sending SPAM only a bit mo