Hhow many of you are planning on implementing SPF records?
August 3, 2004 8:39 AM Subscribe
With Microsoft poised to start using the new Sender Policy Framework with Hotmail in October and AOL "not far" behind, how many of you are planning on implementing SPF records over the next few months?
SPF is a novel way to help mail servers identify each other as legitimate or illegitimate; it's described here. It's trivial to implement, more difficult to circumvent (if it's being used), and interesting to say the least. I'll probably implement it in the next few days... but I have to admit that it's this thread that made me start thinking about it again!
posted by delfuego at 9:12 AM on August 3, 2004
posted by delfuego at 9:12 AM on August 3, 2004
This post is geek push polling.
SPF probably won't do anything to stop spam, since the spammers can just start checking for SPF records and send spam claiming to be from domains that lack them (and there will alway be domains lacking them). However, getting only spam beats getting both spam and bounced spam forged from your domain, so it's probably still an overall win to implement SPF records if they're going to be widely supported in mail agents.
The big problem is, the efficacy of implementing either half of the equation, publishing SPF records in DNS and checking them in the SMTP server, depends on widespread adoption of the other half, which makes this technology quite likely to be wait-and-see'd to death.
Me, I'm planning to wait-and-see ;)
posted by boaz at 9:39 AM on August 3, 2004
SPF probably won't do anything to stop spam, since the spammers can just start checking for SPF records and send spam claiming to be from domains that lack them (and there will alway be domains lacking them). However, getting only spam beats getting both spam and bounced spam forged from your domain, so it's probably still an overall win to implement SPF records if they're going to be widely supported in mail agents.
The big problem is, the efficacy of implementing either half of the equation, publishing SPF records in DNS and checking them in the SMTP server, depends on widespread adoption of the other half, which makes this technology quite likely to be wait-and-see'd to death.
Me, I'm planning to wait-and-see ;)
posted by boaz at 9:39 AM on August 3, 2004
Response by poster: It's definitely a geek poll, but I'm not pushing one agenda or the other. Microsoft has announced their intent to start checking spf records and possibly using them as a weight in their spam filters, and AOL looks like they're getting ready to do something with SPF.
I'm curious to see how many of the mefi-admins think this is enough to justify setting up needed DNS records, or if they'll be with boaz in the wait and see lounge.
posted by alana at 9:57 AM on August 3, 2004
I'm curious to see how many of the mefi-admins think this is enough to justify setting up needed DNS records, or if they'll be with boaz in the wait and see lounge.
posted by alana at 9:57 AM on August 3, 2004
i'm with senor fuego on this one: easy to implement, no reason not to do it.
posted by judith at 11:10 AM on August 3, 2004
posted by judith at 11:10 AM on August 3, 2004
"Does SPF break email forwarding?
Yes, it does."
I think I'm going to be taking a pass on this, thanks. Get back to me when the proposal of the hour is less half-assed.
posted by majick at 12:34 PM on August 3, 2004
Yes, it does."
I think I'm going to be taking a pass on this, thanks. Get back to me when the proposal of the hour is less half-assed.
posted by majick at 12:34 PM on August 3, 2004
The good things about SPF:
- it's harder to send spam as if it's from your domain name
- viruses can't be sent using your domain name so you'll get fewer of those stupid virus warnings
- spammers can't send spam to you spoofing your own address
- it's really easy to implement
- for 99% of people it won't break anything*
The problem is that it isn't widely implemented but I reckon that'll change in the next couple of years. I've already set it up on my domain and will be pushing to implement it at work in the next six months.
* OK, that statistic is made up but there's a 99%* chance it's true
posted by dodgygeezer at 12:45 PM on August 3, 2004
- it's harder to send spam as if it's from your domain name
- viruses can't be sent using your domain name so you'll get fewer of those stupid virus warnings
- spammers can't send spam to you spoofing your own address
- it's really easy to implement
- for 99% of people it won't break anything*
The problem is that it isn't widely implemented but I reckon that'll change in the next couple of years. I've already set it up on my domain and will be pushing to implement it at work in the next six months.
* OK, that statistic is made up but there's a 99%* chance it's true
posted by dodgygeezer at 12:45 PM on August 3, 2004
Majick, the "forwarding" that they're talking about is using a .forward file, not receiving an email, thinking that a friend should read it, and forwarding it along to them. It's an important distinction, for two reasons:
1. Far fewer people use the former than the latter, which means far fewer people are affected.
2. In order for SPF to be implemented at the receiving end of a mail transaction -- at the MTA (e.g., sendmail), that MTA has to be rewritten to understand SPF... and it can just as easily be rewritten to understand how to handle .forward files in an SPF-friendly manner.
posted by delfuego at 12:47 PM on August 3, 2004
1. Far fewer people use the former than the latter, which means far fewer people are affected.
2. In order for SPF to be implemented at the receiving end of a mail transaction -- at the MTA (e.g., sendmail), that MTA has to be rewritten to understand SPF... and it can just as easily be rewritten to understand how to handle .forward files in an SPF-friendly manner.
posted by delfuego at 12:47 PM on August 3, 2004
"Majick, the "forwarding" that they're talking about is using a .forward file"
Right. And several users on my machines use .forward. In fact, the default skel for users on my machines includes a .forward file.
My verdict: not mature, breaks legitimate assumptions about the way mail works, doesn't do anything that a high quality RBL -- rare that such a thing truly is -- can't do. Good luck to folks implementing it, but I don't think I care to participate at this point.
posted by majick at 1:02 PM on August 3, 2004
Right. And several users on my machines use .forward. In fact, the default skel for users on my machines includes a .forward file.
My verdict: not mature, breaks legitimate assumptions about the way mail works, doesn't do anything that a high quality RBL -- rare that such a thing truly is -- can't do. Good luck to folks implementing it, but I don't think I care to participate at this point.
posted by majick at 1:02 PM on August 3, 2004
I use .forward. This is going to be a major pain.
posted by i_am_joe's_spleen at 2:27 PM on August 3, 2004
posted by i_am_joe's_spleen at 2:27 PM on August 3, 2004
Curious, majick and joe's_reticuloendothelial_organ: what's the downside to switching to either the procmail solution or the altered .forward file, at least until the world jumps onto the SPF bandwagon? Honestly, I'm curious, because I host an odd domain or dozen, and will inevitably have to deal with this from other users' perspectives.
posted by delfuego at 6:47 PM on August 3, 2004
posted by delfuego at 6:47 PM on August 3, 2004
I have a hosting provider for my vanity domain/website. They allow me to set up various accounts, and I control their forwarding via .forward files to various other accounts at my regular ISP.
Now, as you noted above, a clueful provider should be able to cope. However, as with any site with a reasonable server-side investment, changing providers will be annoying.
*whoops*
OK, I read more on the FAQ. I think in my case an altered .forward file will work fine. I misread comments above to infer that .forward would not work at all, which is clearly not the case.
posted by i_am_joe's_spleen at 7:26 PM on August 3, 2004
Now, as you noted above, a clueful provider should be able to cope. However, as with any site with a reasonable server-side investment, changing providers will be annoying.
*whoops*
OK, I read more on the FAQ. I think in my case an altered .forward file will work fine. I misread comments above to infer that .forward would not work at all, which is clearly not the case.
posted by i_am_joe's_spleen at 7:26 PM on August 3, 2004
I'll admit I don't quite have my head around it 100%, but I'll definitely take a look at it. If it's really just a matter of publishing an extra set of records to your DNS server and then adding a line to one's Postfix config, then I'm interested, but I'm definitely going to wait for the side effects to be better known*.
* Like how do mailing lists work in this system? Mailing list messages are usually From: the original authors but they're received from the listserver's IP address. It sounds like if the sender's domain and receiver's MTA were both SPF-enabled, then those messages should get rejected. But if SPF breaks mailing lists, that's gonna be a deal-breaker for a lot of people, myself definitely included. Then again, I haven't really looked at it, so maybe they've already thought of this.
posted by boaz at 8:01 PM on August 3, 2004
* Like how do mailing lists work in this system? Mailing list messages are usually From: the original authors but they're received from the listserver's IP address. It sounds like if the sender's domain and receiver's MTA were both SPF-enabled, then those messages should get rejected. But if SPF breaks mailing lists, that's gonna be a deal-breaker for a lot of people, myself definitely included. Then again, I haven't really looked at it, so maybe they've already thought of this.
posted by boaz at 8:01 PM on August 3, 2004
"...what's the downside to switching to either the procmail solution or the altered .forward file...?"
I don't want to wade through several machines' worth of this:
$ grep -v /bin/false /etc/passwd | wc -l
60
and that's just at home, just because someone thinks authentication belongs in DNS and that mail addresses should correspond to network location. I consider both of these basic assumptions to be bad ideas, and in fact the whole enterprise strikes me as wrongheaded. Certainly I'm not going to wade through and fix even this handful of users and write the Exim ACLs to take advantage of it.
The problem with schemes like SPF is that they tend to assume that mail is only used, delivered, and routed in a certain subset of common ways. It isn't.
Placing the burden of authentication on the receiver is the wrong approach. It might intuitively seem like a good idea, but I believe the correct solution to spam is to prevent it from being sent, not to prevent it from being delivered. One doesn't go around breaking the internet just because some folks think it's a good idea to allow poorly-administered, defective, or malicious hosts on their network in exchange for money.
posted by majick at 9:15 PM on August 3, 2004
I don't want to wade through several machines' worth of this:
$ grep -v /bin/false /etc/passwd | wc -l
60
and that's just at home, just because someone thinks authentication belongs in DNS and that mail addresses should correspond to network location. I consider both of these basic assumptions to be bad ideas, and in fact the whole enterprise strikes me as wrongheaded. Certainly I'm not going to wade through and fix even this handful of users and write the Exim ACLs to take advantage of it.
The problem with schemes like SPF is that they tend to assume that mail is only used, delivered, and routed in a certain subset of common ways. It isn't.
Placing the burden of authentication on the receiver is the wrong approach. It might intuitively seem like a good idea, but I believe the correct solution to spam is to prevent it from being sent, not to prevent it from being delivered. One doesn't go around breaking the internet just because some folks think it's a good idea to allow poorly-administered, defective, or malicious hosts on their network in exchange for money.
posted by majick at 9:15 PM on August 3, 2004
Placing the burden of authentication on the receiver is the wrong approach. It might intuitively seem like a good idea, but I believe the correct solution to spam is to prevent it from being sent, not to prevent it from being delivered.
Yeah, well, good freakin' luck with that. There's no way to stop it from being sent.
posted by kindall at 8:52 AM on August 4, 2004
Yeah, well, good freakin' luck with that. There's no way to stop it from being sent.
posted by kindall at 8:52 AM on August 4, 2004
This thread is closed to new comments.
posted by mischief at 9:05 AM on August 3, 2004