Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Does SPF Really Help Curtail Forged Email Headers?

Cliff posted more than 7 years ago | from the keeping-your-domain-out-of-spam-headers dept.

Communications 90

Intelopment asks: "My Domain name has recently been used a lot in the 'Reply' field by some inconsiderate spammer, and my ISP has suggested that I consider using the Open SPF service as a way to stop spammers from using my domain name for in their mail headers field. From what I can tell, it requires the receiving mail server to actually participate in the SPF service, which is where I have my doubts. Does anyone have any experience with this service? Does it work? Are many ISPs using Open SFP?"

Sorry! There are no comments related to the filter you selected.

Gigantic black penis (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19614791)

In your butt. [goatse.cz]

Re:Gigantic black penis (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19615399)

black penis is so 2006. This is the year of the horsecock.

Some do (2, Informative)

Asgard (60200) | more than 7 years ago | (#19614861)

I know of at least one ISP that checks SPF records. SPF costs very little to implement in most cases and does not break email for someone who is not using it. Based on that there is really no reason *not* to implement it. It won't completely solve the problem, but it does enable someone who is SPF-aware to filter those emails.

Re:Some do (2, Informative)

Mr. Slippery (47854) | more than 7 years ago | (#19616035)

SPF costs very little to implement in most cases and does not break email for someone who is not using it.

SPF breaks forwarding [woodhou.se] . It is a badly brain-damaged scheme.

A few years back it was alleged that more spam than valid e-mail was being sent using SPF. [theregister.co.uk]

SPF is bad, mkay? It should have been taken out behind the barn and put out of our misery a long time ago. Don't use it, and don't encourage it.

DomainKeys is a much smarter scheme. Use and encourage it instead.

Re:Some do (1)

MarsDefenseMinister (738128) | more than 7 years ago | (#19616225)

SPF isn't supposed to do anything like what you claim. SPF is supposed to help with Joe Jobs. Do you know what that is?

Re:Some do (1)

Mr. Slippery (47854) | more than 7 years ago | (#19616287)

SPF isn't supposed to do anything like what you claim

Odd. I made no claims about what SPF is "supposed" to do, only noted that it 1) breaks forwarding, and 2) doesn't prevent spam.

As for preventing forgeries like joe jobs, read the page I so conveniently linked to [woodhou.se] :

Some people claim that SPF directly combats spam. It doesn't. SPF attempts to address forgery. In fact, a large amount of spam rates an SPF 'pass' result, because spammers have rapidly adopted SPF for themselves.

You still need a blacklist or other kind of trust database, to tell you which domains are trustworthy and which are not. But we already have lots of blacklists; it's just that we list the IP address instead of the domain name, to tell you which hosts are trustworthy and which are not. We don't need to break email and force everyone to upgrade to some bizarre new scheme just for that.

Cryptographic signatures are the solution to preventing forgeries. Until we get them into wide use on the user level, DomainKeys is a fairly good solution. SFP is a poor one.

Re:Some do (1)

MarsDefenseMinister (738128) | more than 7 years ago | (#19616323)

1) forwarding sucks. Why? I don't know. But if I can't tell if it's coming from a legitimate server, it sucks.
2) Chapstick doesn't prevent spam either. Why didn't you mention that?

Re:Some do (1)

walt-sjc (145127) | more than 7 years ago | (#19618543)

1) forwarding sucks. Why? I don't know.

On the contrary, forwarding is Very Very useful. I have somewhere around a dozen different accounts on email servers that I don't control that forward to a couple accounts that I DO control. With so many accounts, fetchmail isn't viable (especially with "expiring" passwords to deal with) and some forwarding accounts don't even allow logins fr various reasons.

The SPF "solution" is SRS (Sender Rewriting Scheme).

Unfortunately, SRS ALSO sucks. Instead of a huge long post here, I'll just refer to this post [gossamer-threads.com] , but the gist of it is that SRS creates a fundamental gaping hole in the utility of SPF.

SRS isn't even supported on most of the servers that I have forwarding accounts on anyway, so it's a non-"solution" from the start.

Re:Some do (1)

TheRaven64 (641858) | more than 7 years ago | (#19618783)

Surely the simpler solution to this is to configure your mail servers to not check SPF for mail coming from the dozen servers are allowed to forward to you, and not anyone else? I agree with the grandparent; although I use forwarding to move mail between a couple of accounts, it should not be allowed in the general case.

Re:Some do (1)

beavis88 (25983) | more than 7 years ago | (#19627689)

You've hit the nail on the head here. The poster apparently wants to make SPF totally useless for the rest of the internet, to avoid reconfiguring his mail server (either to ignore SPF on forwards from "vanity domains" or to, oh I don't know, ignore SPF altogether). It's interesting that the best complaint people can come up for an optional scheme is that it breaks something they have full control over if they choose to use it...

Re:Some do (1)

Mr. Slippery (47854) | more than 7 years ago | (#19619431)

1) forwarding sucks. Why? I don't know. But if I can't tell if it's coming from a legitimate server, it sucks.

See, SPF sucks so bad that it's confused you about forwarding.

The question is not if it comes to me from a legitimate server; it's if it *originated* from a legitimate server. DomainKeys allows this without crazy-ass rewriting.

2) Chapstick doesn't prevent spam either. Why didn't you mention that?

The only reason that people might want to check SPF headers on the receiving end is to prevent spam from reaching them. Once they figure out it doesn't, they don't have much motivation.

Do I, running the server for a small company, care if you get Joe jobbed? Sorry, but not really. So why am I going to bother to have my mail server spent cycles and bandwidth checking SPF headers?

Re:Some do (1)

DrZaius (6588) | more than 7 years ago | (#19640935)

Spammers interested in using SPF will also implement DKIM. SPF and DKIM aren't about preventing spam, they are about authenticating the sender and using that to build a reputation.

Re:Some do (1)

grahamm (8844) | more than 7 years ago | (#19661307)

Cryptographic signatures are the solution to preventing forgeries. Until we get them into wide use on the user level, DomainKeys is a fairly good solution. SFP is a poor one.
I use SPF, SRS, DomainKeys and DKIM (both setting in outgoing mail, and checking on incoming). I see far more 'false positives' where legitimate incoming mail fails the checks from DomainKeys and DKIM than I do from SPF. For example since collecting DKIM statistics on the mail server here, of mails from gmail.com 50 had DKIM signatures which validate correctly but 1179 had signatures which failed DKIM validation. The only case of valid mails failing SPF that I have seen (as the postmaster) was where a company was taken over by another and their outgoing mail was routed via the new companies servers but the SPF record for the domain had not been updated to reflect this.

Re:Some do (2, Informative)

Bert64 (520050) | more than 7 years ago | (#19618587)

SPF breaks "vanity forwarding" as described in that site, but surely if *you* set up a forwarding service you can whitelist or special case that service, since the forwarding service will only be sending mail to you. If you configure it as a forwarding service on your mailserver, and you trust that service, then your mailserver can compare the spf records against the headers added by the forwarding service instead of the actual address the connection came from.

Now i run an ISP with a large number of customer domains, so it's in my interest to minimise the number of forgeries.

SPF may have its flaws, but its easy to implement for your domain and significantly cuts down on the forged mail purporting to come from your domain.

Domainkeys on the other hand, requires you to append a signature to every outbound mail in order to be effective. This would require me to modify my outbound mailserver, in itself not a serious problem. I would also need a patch that supports multiple private keys, since my outbound servers support multiple domains.
Then we have users who sometimes use other servers for sending mail, for instance i have several hosting customers who use their own isp's local server to send mail because their isp blocks outbound port 25 connections (to prevent spam drones). The only way i could get round this, is to run an smtp server on a nonstandard port for them to use, but try explaining that to end users.
Then you have things like blackberry users, who use their telco's blackberry service to send mail from their domain. I doubt it will be easy to get their telco to add domainkeys support and their own private key to their outbound mail servers.

Re:Some do (1)

Greg Couch (544551) | more than 7 years ago | (#19638739)

Using the alternative SMTP submission port, 587, as detailed in RFC 2476, is what is needed for users that have port 25 blocked by their ISP so that SPF works simply for their domain. Email client support for alternative ports was not common when the RFC was written in 1998, but every client has support for it today, so there is no excuse. The great advantage of configuring your laptop to always use port 587, is that you can plug the laptop in anywhere on the Internet and your email just works.

Re:Some do (1)

Bert64 (520050) | more than 7 years ago | (#19646485)

And then having to explain that to end users..
It also doesn't help users of mobile devices who have to use the telco's outbound mailserver, with SPF i can add the telco's mailserver to the allowed list easily.

It does help, but... (4, Informative)

Meostro (788797) | more than 7 years ago | (#19614873)

... but only if you use it.

Add SPF to your domain, and whatever subset of ISPs / mailservers that use it probably won't bug you. The only downside of using SPF is that you may have to change your DNS records if you want to use a new mailserver, but most people that I know only use one or two servers for outgoing mail for any one domain.

One DNS line to potentially stop a joejob against you - it's a no-brainer, even if you "have [your] dobuts". Go to the SPF Setup Wizard [openspf.org] , fill in your servers and copy the IN TXT line.

See if it works, and proceed from there. If it doesn't, go back to the ISP and complain.

Re:It does help, but... (1)

MichaelSmith (789609) | more than 7 years ago | (#19614953)

I am going to have a look at this because I get about 50 bounces per day from spam sent with my domain name as the sender. Yesterday I got 500 bounces. There must be a push on somewhere.

The main problem for me is that my outgoing mail currently goes through a server operated by my cable provider. I wonder, though, if I can get around this by setting From: to be from a different domain I have and Reply-To: to the the domain with the SPF records.

Re:It does help, but... (3, Informative)

djmurdoch (306849) | more than 7 years ago | (#19615127)

The main problem for me is that my outgoing mail currently goes through a server operated by my cable provider.

Why is this a problem? Does your cable provider not provide an SPF record? If they do, one of the variations on the SPF record ("include:") for your domain is basically a pointer to theirs.

Re:It does help, but... (1)

MichaelSmith (789609) | more than 7 years ago | (#19615265)

Why is this a problem? Does your cable provider not provide an SPF record? If they do, one of the variations on the SPF record ("include:") for your domain is basically a pointer to theirs.

Yeah I just found that in the wizard. The only problem is that the spam can still be sent from my cable providers domain, but reading the other replies it looks like this is really going to put a dent in my problem.

Re:It does help, but... (1)

walt-sjc (145127) | more than 7 years ago | (#19618595)

reading the other replies it looks like this is really going to put a dent in my problem.

Not really. Very few site implement SPF in a way that would reject forged mail. Look, if they are not smart enough to reject outright and instead scan later and bounce (which is the cause of the collateral damage to begin with), what makes you think that YOU implementing SPF is going to help? It won't. Not one bit.

The easiest way to deal with backscatter bounce spam is to reject it. Scan for the common bounce messages, such as the brilliant "You have sent a message with a virus" type generated by poorly designed "security" software (such as the shit from "Declude", which is obviously means "we have no clue") and reject such bounces with a message that points them to a web page that explains the problem. This creates a double bounce, which puts the problem right back on the incompetent email admin that accepted the forged spam or virus laden mail to begin with!

Re:It does help, but... (1)

djmurdoch (306849) | more than 7 years ago | (#19627039)

This creates a double bounce, which puts the problem right back on the incompetent email admin that accepted the forged spam or virus laden mail to begin with!

As long as you reject at the RCPT stage (before you can see the body) it's okay to refuse, but if you're basing the bounce on the headers put together by an incompetent email admin, you're just adding to the problem: you may not be bouncing to the right place. Just send it into a black hole, don't bounce.

Re:It does help, but... (1)

walt-sjc (145127) | more than 7 years ago | (#19650173)

This is why I explicitly said "reject" and not "bounce." In order to do this scanning, it MUST be done at the DATA phase and not at the RCPT. You don't have the content to scan yet at RCPT! Any totally broken host that ignores the 5xx error and attempts redelivery of the same message (keyed off the Message-ID) get's firewalled for 1 hour. There are a number of totally broken MTA's out there that warrant limited-time firewalling for bad aggressive behavior.

Just a few years ago, you could get by with a fairly simple ACL in your MTA. Now the ACL is an entire application that links to multiple content scanners, and is quite complex. It needs to be in order for email to remain viable - especially for those of us with email addresses that haven't changed in 10 - 15 years. We are on every spammers list.

doesn't really help (1)

ArbitraryConstant (763964) | more than 7 years ago | (#19615803)

Certain major western Canadian cable ISPs who shall remain nameless have been known to silently trap SMTP connections, and then forward the messages on to the destination.

Now, that's all fine and good if you're willing to "include:" their SPF records... but unfortunately this steadfastly anonymous western Canadian cable ISP also happens to be one of the most prolific botnet havens in the world, so you're not really cutting down the number of people that can claim to be you by a useful amount.

Your best bet is to run a VPS mail server, choose a different port for your client to connect to, and use SSL. Alternatively, you can outsource your mail service to someone like Google (who provides SPF guidance).

Re:doesn't really help (1)

djmurdoch (306849) | more than 7 years ago | (#19616199)

If you have ssh access to a reliable server, you can also tunnel to them for outgoing mail.

Re:It does help, but... (3, Informative)

Meostro (788797) | more than 7 years ago | (#19615185)

The main problem for me is that my outgoing mail currently goes through a server operated by my cable provider. I wonder, though, if I can get around this by setting From: to be from a different domain I have and Reply-To: to the the domain with the SPF records
You shouldn't have to do anything that fancy.

Go to the SPF wizard page, tell it what your mailservers are (even if they aren't your domain MX records) and it will tell you what to use. If your outgoing mail is set up as someguy@mycableprovider.com then you'll have to worry about them getting the records right, but if you're sending form someguy@mydomain.com you just have to worry about telling SPF which servers you send mail through.

Re:It does help, but... (1)

MichaelSmith (789609) | more than 7 years ago | (#19615335)

just have to worry about telling SPF which servers you send mail through.

Yes. I have been through the wizard and I got my SPF records set up. I will start looking for ways to integrate it with qmail now.

Re:It does help, but... (0, Flamebait)

MarsDefenseMinister (738128) | more than 7 years ago | (#19616191)

The increase in bounces started a bit more than a week ago. I've noticed it at my domains too.

The problem now isn't the spam, it's the morons who send bounce notifications to forged e-mail addresses. It's the morons who set vacation autoresponders. It's the morons who ask for human confirmation that the mail isn't spam. It's the virus scanners that send their crap to forged e-mail addresses.

Why don't people realize that the word "Symantec" in an e-mail is for me a 100% indication that the mail is from a Russian cocksucker? Or a "Macaffe" in the header is probably from some slant-eye who can't administer his windows box on a giant Korean spam network conduit? Talk about fucking a brand name. Just hearing the word "Symantec" gives me hives these days.

Mod parent up. (1)

hedwards (940851) | more than 7 years ago | (#19625311)

I have no idea why you were modded flaimbait, because you are largely correct.

With the current epidemic of joe jobs going on, it makes absolutely no sense to bounce emails back when they are not coming from an SPF or domainkeys server. Even when they are it doesn't make a whole lot of sense.

Both of my email providers use SPF, and one of them uses domain keys as well, but as you so aptly stated, if the other servers are ignoring the additional information, the benefit in that area is small.

Even in those cases, the benefit to one more server using SPF or domainkeys does exist, it is one more server that represents a microscopic move towards the newer authentication methods, and one less domain which will have messages trash canned for not having the information.

Huge black penis (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#19614881)

In your butt. [goatse.cz]

Some ISPs do, some don't.. but what's it cost you? (5, Informative)

mkettler (6309) | more than 7 years ago | (#19614885)

Several ISPs use SPF, for example, AOL does.
http://www.postmaster.aol.com/spf/ [aol.com]

Several ISPs don't.. For example, yahoo is busy pushing the competing standard of domainkeys.

Many open source spam scanners use it, ie: SpamAssassin.

However, even if not everyone supports SPF, at least some folks do, and that means if and when your domain does get forged by a spammer, there will be fewer folks receiving it, fewer mailservers accepting it and fewer bounces/complaints heading your way.

And of course, SPF is more-or-less cost free.. All you have to do is add a TXT record to your DNS, which probably won't cost you anything unless your DNS is hosted on some oddly billed 3rd party service.

I'd say the ROI on it is pretty good.

Many folks will immediately bash SPF as a poor spam control technology. Well, they're right, but that's not the point, and it's not what SPF is for, and it's not what your trying to get out of SPF.

SPF isn't a "cure-all" for spam that some folks think it is and others bash it for not being, but SPF IS a reasonable start at controlling forgery, and it's quite effective at it.

Re:Some ISPs do, some don't.. but what's it cost y (2, Interesting)

Aladrin (926209) | more than 7 years ago | (#19615011)

I was initially like 'Why do I care?' but once I finally realized that it could help prevent people from using my domain name to spam -with- (rather than -to-), I was all for it. Especially since, as you note, it costs me nothing but a bit of time to set up. (And not much, since I use Google's mail servers, and they practically push the information on you.)

It may not have a huge effect, but as a domain owner, I have had my domain 'used' a few times as the return address. It hasn't happened since I set up the SPF record. (Likely spammers don't think I'm as nice a target now.)

Re:Some ISPs do, some don't.. but what's it cost y (1)

CliffSpradlin (243679) | more than 7 years ago | (#19615993)

It should be noted that the SPF settings that Gmail for Domains provides uses ~all instead of -all. What this means in layman's terms is that an anti-spam filter is supposed to use the SPF record as a hint, rather than a requirement. Gmail does this most likely so that people who use their ISP's SMTP server to send out mail will still have their mail go through.

The point is, if you exclusively use Gmail for SMTP, you should change the record to -all for better protection.

Re:Some ISPs do, some don't.. but what's it cost y (1)

hedwards (940851) | more than 7 years ago | (#19625357)

Does this then apply just to SMTP? Or is it applicable to the webbased email as well?
On the bright side, last time I checked gmail also supported domainkeys.

Re:Some ISPs do, some don't.. but what's it cost y (1)

tepples (727027) | more than 7 years ago | (#19615617)

All you have to do is add a TXT record to your DNS, which probably won't cost you anything unless your DNS is hosted on some oddly billed 3rd party service.
Unfortunately, a lot of domains are on cheap shared web hosting, which is often "oddly billed" by your definition.

Re:Some ISPs do, some don't.. but what's it cost y (1)

mkettler (6309) | more than 7 years ago | (#19616635)

Agreed.. I didn't mean to imply "odd" was particularly rare.. Just odd.

"We'll provide you 50MB of webhosting for $10/month.. Oh, you wanna add another 60 bytes to your zonefile for another DNS entry.. sure thing, that'll be another $2.50/month".

Re:Some ISPs do, some don't.. but what's it cost y (1)

Al Al Cool J (234559) | more than 7 years ago | (#19617549)

SPF is cost-free as long as the SPF records remain accurate for your domain. The problem is that things change, servers get moved, new websites get created, and if the SPF records aren't updated to reflect those changes, then some emails are going to go missing. A problem like that could go undetected for months, and that bears a cost.

The fact is, in larger companies the left hand doesn't alway know what the right hand is doing, while in smaller companies IT can get farmed out to multiple providers who can be blissfully unaware of what is happening in the big picture.

SPF can be an effective technology for companies that have their IT act together. But it can be a source of headaches for everyone else, which I expect is the majority.

Re:Some ISPs do, some don't.. but what's it cost y (1)

itwerx (165526) | more than 7 years ago | (#19617845)

The problem is that things change, servers get moved, new websites get created, and if the SPF records aren't updated to reflect those changes...
Yes, it's possible that all the other DNS records could get updated and just that one be ignored but it's pretty unlikely.

...then some emails are going to go missing. A problem like that could go undetected for months, and that bears a cost.
Having had occasion to mistype an IP in an SPF record once or twice I can assure you that it does not go undetected for months. A few hours perhaps, (pft, more like minutes). There are enough ISP's and private spam filters using SPF now that if there's a glitch it shows up pretty damn quick in the form of an irate user, "I was able to email this person yesterday, ZOMGWTFBBQ?!?"

Re:Some ISPs do, some don't.. but what's it cost y (1)

Al Al Cool J (234559) | more than 7 years ago | (#19617965)

I've seen it happen it twice. In both cases you had company.com with SPF on its domain running a website alternatebranding.com on a colocated server, but which sent out automated emails using @company.com From addresses. When the server was moved to a different IP, the DNS on alternatebranding.com was changed, but the company.com SPF wasn't, and emails started to go missing. In one case it went undetected for over a month, and in the other it was well over a year.

Re:Some ISPs do, some don't.. but what's it cost y (1)

itwerx (165526) | more than 7 years ago | (#19627961)

Companies have websites with dead links that don't get caught for years too. People make mistakes under any/all circumstances, not just involving SPF records. Sounds like these guys weren't exactl on the ball though, any automated system should have some sort of reporting/monitoring with a live human on the other end.

Re:Some ISPs do, some don't.. but what's it cost y (1)

Bert64 (520050) | more than 7 years ago | (#19618491)

Well, as new sites and servers are created you'd assume that new dns records would be created for them too, so while your there editing your dns records you can update the spf too.

Re:Some ISPs do, some don't.. but what's it cost y (1)

Kiaser Wilhelm II (902309) | more than 7 years ago | (#19618633)

Its part of the game. You either have your act together or you don't. If you don't have your act together, then you can only blame yourself.

Re:Some ISPs do, some don't.. but what's it cost y (1)

mkettler (6309) | more than 7 years ago | (#19619107)

The fact is, in larger companies the left hand doesn't alway know what the right hand is doing, while in smaller companies IT can get farmed out to multiple providers who can be blissfully unaware of what is happening in the big picture.

This is true, as I am all to personally familiar with the situation.

However, such organizations are going to have dozens of other problems causing loss of mail, network outages, etc.

An IT team that does not properly communicate and/or oversee its own networks is a disaster waiting to happen. SPF might exacerbate this problem, but it's hardly a root cause.

So, I'll agree with you. If your network is poorly managed, don't bite off more by adding SPF to the mix. First spend time getting your existing network under control.

In my professional opinion (-1, Offtopic)

earnest murderer (888716) | more than 7 years ago | (#19614899)

The Stile Project Forum [stileproject.com] does not in fact have any effect, good or bad, on forged e-mail headers.

But if you want a video of a guy nailing his prick to a board and imagine that is a spammer, the SPF is the place to go to make yourself feel better.

Re:In my professional opinion (0)

Anonymous Coward | more than 7 years ago | (#19616381)

Well, I found it funny!

Re:In my professional opinion (1)

earnest murderer (888716) | more than 7 years ago | (#19617815)

And closer to being on topic tham many +5 insightful comments seen around here.

Since we're on the subject... I think the system could use a -1 metadiscussion moderation to boot.

SPF 30 (5, Funny)

RealGrouchy (943109) | more than 7 years ago | (#19614929)

Some can, but be sure to make sure that it blocks both UVA and UVB spam.

- RG>

Re:SPF 30 (1)

Tumbleweed (3706) | more than 7 years ago | (#19615939)

My congratulations on a truly stellar joke!

drastically reduced mail server bounces (4, Interesting)

SkunkPussy (85271) | more than 7 years ago | (#19614961)

I used to receive 30 bouncebacks a day due to spam. I switched to SPF, and it didnt immediately make a difference. After several weeks I noticed I was receiving maybe 1 or 2 bouncebacks a day.

I cannot be certain whether this is due to the spammer observing my implementation of SPF and no longer using my domain as a return address, or whether the spammer still uses my domain but mail servers have stopped sending me the bouncebacks.

Either way I+internet won, spammer lost.

Yes, it does work. (2, Informative)

parrini (840878) | more than 7 years ago | (#19615021)

Yes, it does work. I started using SPF and almost immediately stopped receiving spam backscatter. Besides that, I activated SPF check in my SMTP server and since then, we drop a lot of forged mail headers too. Its ridiculous easy to implement, consumes nothing more than a DNS record and can be fine tuned. Besides that, every single big mailer is already using it.

Not worth the complaints (3, Interesting)

braddeicide (570889) | more than 7 years ago | (#19615061)

We checked SPF on all incoming mail to our ISP, it worked for a while, but eventually it wasn't worth the effort of dealing with legit mis-configured companies. Not to mention the fact customers wouldn't believe it wasn't our fault. Yes even banks make mistakes.

It Improves Your Fun (3, Interesting)

chromatic (9471) | more than 7 years ago | (#19615065)

The best part of using SPF, for me, is responding to automated mailers that send me messages saying "Your message to us failed an SPF check!" I always have great fun explaining that failing an SPF check means that they would have a better chance of reaching the person who actually sent the message by picking a random address on a random other domain.

Re:It Improves Your Fun (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19615291)

I'm sure the automated mailer on the other end has great fun diacarding your mails... :)

Re:It Improves Your Fun (1)

chromatic (9471) | more than 7 years ago | (#19618305)

postmaster@ doesn't. At least it shouldn't.

It worked for me! (4, Interesting)

mophab (137737) | more than 7 years ago | (#19615069)

I think the spammers check the SPF records, and if there is one they don't forge your address.
I had lots of problems with my e-mail address being forged by spammers.
When I put in an SPF record, it stopped immediatly.

Re:It worked for me! (1)

ivan256 (17499) | more than 7 years ago | (#19615167)

I'll second this.

I added SPF records for my domains in the hopes that I could get maybe a 20% reduction in bounces, and I got a 100% reduction. I know that 100% of ISPs aren't checking SPF records, so I can only assume that spammers have made a point to check for SPF and not use my domains in their headers.

Re:It worked for me! (1)

BobPaul (710574) | more than 7 years ago | (#19615311)

I think this is very true. I had my SPF record setup to use my DNS service's smtp servers. I use mydomain.org, which is free and hence easy to get at the SMTP servers for. Everything was great until about a year ago, and the bounces kept on coming. Finally I switched my SMTP server and SPF records to point to my company SMTP server, which requires an employee login. The bounces dried up in about a week or two. In this case, I believe they targeted my domain to take advantage of my SPF record.

Re:It worked for me! (1)

MarsDefenseMinister (738128) | more than 7 years ago | (#19616205)

False. I have had SPF records for years, and got about 5000 bounces last week from forgeries.

Please do - it costs nothing to publish, and .... (3, Informative)

GuruBuckaroo (833982) | more than 7 years ago | (#19615161)

... little to filter incoming mail. To protect your outgoing mail, all you have to do is publish a special DNS record - that's it, done, no need to change it as long as your MX servers don't change. It's That Simple.

On the incoming side, a lot of ISPs are using it - and a great number of corporations are using it, even if they don't realize it. Spam Filter boxes like those from Barracuda (Can't recommend these guys enough), or software like SpamAssassin, can easily check SPF records. I think Barracuda's do by default, but I could be wrong - it's been a few years since we installed our Barracuda.

Granted, it's only one part of a good anti-spam system. I use SPF, DomainKeys/DKIM, SpamAssassin, and a nifty little feature of Sendmail called "greet_pause" (check it out if you use Sendmail for inbound email). It's cut down on my junk mail by an ungodly amount.

Re:Please do - it costs nothing to publish, and .. (2, Interesting)

6Yankee (597075) | more than 7 years ago | (#19615287)

Barracuda (Can't recommend these guys enough)

Recommend? Those bastards, their asshat defaults, and their RTFM-impaired users are responsible for some 40% of the shite in my mailbox right now (though that is unusually high, I grant you). It is NOT acceptable to bounce "back" to an innocent victim. It is NOT acceptable to advertise the piece of shit responsible in the subject header either - though I like to imagine competent sysadmins the world over vowing not to buy the product as a direct result.

If everyone set up a rule to forward anything with "Message you sent blocked by Barracuda" to sales@barracuda.com with a "please fix your defaults", would that constitute a DDoS or just a mass appeal? (Yeah, I posted an email address. I figure they should be able to handle it, no?)

Re:Please do - it costs nothing to publish, and .. (1)

itwerx (165526) | more than 7 years ago | (#19617871)

are responsible for some 40% of the shite in my mailbox

For what it's worth one of the updates recently disables bouncebacks triggered by SPF check. They heard that complaint from a lot of folks and finally got around to fixing it.

Re:Please do - it costs nothing to publish, and .. (1)

walt-sjc (145127) | more than 7 years ago | (#19618615)

I reject such bounce-backs at SMTP time. Any email server / software that accepts virus / spam laden mail and then later bounces it is the cause of all collateral damage. Incompetent sites that operate such servers should be blacklisted.

Re:Please do - it costs nothing to publish, and .. (1)

itwerx (165526) | more than 7 years ago | (#19627969)

I reject such bounce-backs at SMTP time.

So how do you know when it's a legitimate bounce-back? Or do you just reject all bounce-backs out of hand? (Sure hope that's a home network! :)

Re:Please do - it costs nothing to publish, and .. (1)

walt-sjc (145127) | more than 7 years ago | (#19649955)

Content scanning. I maintain a regex blacklist of known collateral damage "notifications".

Re:Please do - it costs nothing to publish, and .. (1)

TheRaven64 (641858) | more than 7 years ago | (#19618855)

Can you clarify something, since I've not had one of these bounces? Do they:
  1. Perform an SPF check, and know to a reasonable certainty that you are not the sender of the message, and then
  2. Send you a mail containing an advert for their product?
If they do, then the first part should be enough to show that they don't have prior business relationship with you (and are aware of this fact) and the second part shows that they are sending commercial email to you. I am not a lawyer, but it sounds like they are quite nicely fitting the description of unsolicited commercial email as defined by a number of laws worldwide, and could probably be sued quite easily if you had a chat with a lawyer.

Re:Please do - it costs nothing to publish, and .. (0)

Anonymous Coward | more than 7 years ago | (#19656667)

I'm not saying that their default settings are right, but the product doesn't magically work out-of-the-box. The system administrator has to go into the config and set it up--if some no-talent ass-clown doesn't properly set the bounce settings (aka backscatter), then it's the no-talent ass-clown's fault. The same's true elsewhere: Smith & Wesson sells guns that will shoot bullets, but you have to put the bullets into the gun before it can do anything. If you fail to set the safety after putting in the bullets, is it your fault or Smith & Wesson's when you shoot yourself in the foot?

Blame incompetent mail server admins for not researching best practices, not Barracuda (who make a powerful anti-spam appliance for those of us who know what we're doing).

How I implemented SPF in an Exchange environment (2, Interesting)

adminstring (608310) | more than 7 years ago | (#19615181)

For several years I've been running LogSat Software's Spam Filter ISP [logsat.com] in front of my Exchange server. It uses SPF, blacklists, and Bayesian filtering to keep spam out, and between SPF and the blacklists, about 97% of the incoming spam connections I used to get are now disconnected immediately. The savings in bandwidth (and in processing power and storage space on my mail server) has been enormous.

It allows me to set up a whitelist of the legitimate email addresses in my domain, and if an email tries to come in to an address that isn't on the whitelist, the connection is immediately dropped. So no more endless stream of "abernathy@mydomain.com,abraham@mydomain.com..." spam clogging up my badmail folder. YMMV, but I tried a number of different antispam products before settling on this one, and I'm a very happy camper.

Why not just try it? (1)

Vellmont (569020) | more than 7 years ago | (#19615221)

It took me maybe an hour to fully implement it a few years ago (most of which was just reading), so why WOULDN'T you try it? There's really no downside other than having to maintain a list of outgoing mail servers. And unlike something like domainkeys, you don't have to go around messing with your mailserver configuration. If it gives you some kind of problem, it only takes a few minutes to disable it.

TROLL, PLEASE!!! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19615397)

TROLL, PLEASE!!!

AOL DOES NOT SUPPORT SPF in a way that will help. (1)

elvey (86546) | more than 7 years ago | (#19615521)

I got a couple hundred bouncebacks yesterday, despite having an SPF record. They don't seem to help much.

There are quite a few domains that have SPF records, like AOL, but having a record, and bit bucketing mail that SPF says is forged, are two very different things. Very, very few domains do the latter. It would be nice if more did. Does AOL? Well...
I'm still getting hammered.

One spam I received yesterday suggests:

A spammer tried to send spam
From: @elvey.com
To:@aol.com

AOL's response was:
554-: (ISP:B2) http://postmaster.info.aol.com/errors/554ispb2.htm l [aol.com]
554 TRANSACTION FAILED

The spam was transmitted from/via mail2.infoquesthosting.net [65.61.1.49], a Barracuda Spam Firewall 3, which is broken by design.
You thought Barracuda was helping FIX email? They're making the problems worse! But let's keep on topic...

So, the Barracuda takes the spam and sends it to @elvey.com, the innocent victim forged in the From:, despite the elvey.com SPF record.

This is typical. Like I said, a couple hundred bounces yesterday...

If the server of a so-called leader in the antispam arena is sending me spam despite appropriate SPF records, what does that say?

Re:AOL DOES NOT SUPPORT SPF in a way that will hel (1)

mkettler (6309) | more than 7 years ago | (#19616781)

Hey, at least AOL is rejecting it at SMTP delivery time.. If they were queuing it, then post delivery bouncing, I'd call them evil, but right now they're doing the right thing.

After all, if the recipient didn't exist, they'd issue a 5xx error too. Nearly every sane domain will do that. This isn't really any worse for you. Or do you expect them to accept delivery of and swallow those too?

Quite frankly, this still makes your life *MUCH* easier when compared to the post-delivery bounce case.

All you have to do now is blacklist the servers that are being used *sources* and *relays*, as opposed to all the servers that are *destinations*. And quite frankly, the server that's acting as a spam source or relay deserves to be blacklisted anyway.

What could be a DDoS (backscatter from many servers) is in this case, just a single source DoS that can be handled by blacklisting a single IP address.

What's even better, is if you blacklist 65.61.1.49 at the SMTP layer, those spam messages will double-bounce and end up in infoquesthosting's postmaster mailbox. Seeing as it's their spam problem in the first place, it should be fitting that they end up with it.

So do yourself a favor and add 65.61.1.49 to your SMTP access list today. :)

Re:AOL DOES NOT SUPPORT SPF in a way that will hel (1)

elvey (86546) | more than 7 years ago | (#19624945)

Yes, the 5xx is a big improvement, you're right. What we need is a Blacklist that ... well, backscatterers.com is up, but doesn't seem to be operational. It should be easy to drop all mail from from IPs in such a BL, while treating the rest normally.

Re:AOL DOES NOT SUPPORT SPF in a way that will hel (1)

itwerx (165526) | more than 7 years ago | (#19617883)

Interesting to hear that AOL is using Barracudas now, I knew they were switching but didn't know who won the contract.
      FYI - see my post above regarding Barracuda's SPF bouncebacks, that's been taken care of recently.

Re:AOL DOES NOT SUPPORT SPF in a way that will hel (1)

awdau (1108639) | more than 7 years ago | (#19618359)

Its possible the spams originated from inside the 'trusted network(s)' that the barracuda mailserver allows relays from.
i.e. a webserver that has/had an exploitable site or a internal machine infected with some malware.

I have it, apparently nobody notices (1)

rfc1394 (155777) | more than 7 years ago | (#19615697)

I routinely get bounce headers (for invalid destination addresses) from places where they are receiving mail which has been forged under one of the domain names I own (I happen to own over 20 domains and only about 2 or 3 of them would ever send any mail). All of the domains that I would send mail from have three IP addresses listed in the SPF records in the DNS: the fixed IP address that I get DSL supplied from Cavalier Telephone (for mail sent by my computer); the IP address of Cavalier Telephone's mail server (for mail my computer sends through them); the IP address of the webserver that holds my blog (when it sends out mail messages). No other IP address should be considered authentic and my SPF records indicate this. Yet I routinely get bounce messages from places sending bounces to me for spam which has been joe jobbed by someone else using one of my domain names. Maybe some places are rejecting forged mail from other places, but I still see places that apparently don't bother to check SPF records when they do exist.

Paul Robinson — My Blog [paul-robinson.us]

Re:I have it, apparently nobody notices (0)

Anonymous Coward | more than 7 years ago | (#19615909)

Me too, I'm assuming you use -all? The backscatter would be far worse without SPF records.

it helps (2, Informative)

ArbitraryConstant (763964) | more than 7 years ago | (#19615877)

Supporting SPF doesn't put an end to spam, but it's one of those best-practices things that can really make your life simpler down the road.

For outgoing mail service:

-It becomes immediately apparent when "surprise" mail servers pop up. This can be a web server that's sending outgoing mail directly, or someone sending mail through their ISP's mail servers when they should be connecting and authenticating to your servers, etc. Tracking down mail problems in these situations can be very frustrating.

-It helps prevent forged messages claiming to be from your domain. Not all recipients support this, but even after the fact it's helpful to be able to have an answer for what can be done about it that doesn't get any blame on you.

For incoming service:

-Even a moderately strict SPF policy can help prevent bounce-spam from being sent via your servers.

-It helps protect your users from scams.

It's not a perfect solution, but it puts your network in a better defined state. And that helps keep things running smoothly.

Re:it helps (1)

aviators99 (895782) | more than 7 years ago | (#19679617)

> -It helps protect your users from scams.

This is my problem with some of the SPF evangelism. It *does not* help protect your users from scams. SPF has been touted as the solution to phishing (by Microsoft, among others), but in reality it cannot help there. Phishing largely relies upon the "pretty name" in the e-mail header (e.g. "Bank of America Customer Service <custsrv@bankfromamerica.net>"), and many (perhaps most) e-mail clients only show the pretty name in the summary view.

As others have said here, SPF does help with Joe Jobs (spammers using your e-mail address as a bounce address). This is indeed a useful feature, and I use it myself. But the public press about SPF is largely incorrect, and even the title of this topic is misleading. I guess it can curtail forged e-mail headers, but the net effect is not a curtailing of spam (and especially not scams).

Nothing to do with mail headers (0)

Anonymous Coward | more than 7 years ago | (#19615879)

SPF operates on SMTP MAIL FROM and HELO domain names, potentially allowing receivers to reject before DATA which may contain arbitrary headers. The Microsoft PRA nonsense abuses SPF records for mail headers.

Log data... (2, Interesting)

rthille (8526) | more than 7 years ago | (#19615933)

Since Mar 26th 2007 I've gotten dns requests for SPF (type 99) records 35 times, and text records (possibly/probably? for SPF) 692 times.

So, someone is checking.

Consider Gmail for your Domain (2, Insightful)

SoopahMan (706062) | more than 7 years ago | (#19615989)

Consider migrating your mail servers to Gmail for your Domain:
https://www.google.com/a/cpanel/domain/new [google.com]

I had these sorts of "Joe Jobs" against my domain for 2 years. The last straw was when I actually had a client upset at me over spam sent on my behalf from a different server. I explored a lot of different ways of stopping it, and ultimately arrived at moving my MX records to Google servers as part of the above Google Apps for your Domain. It uses SPF, and presumably Google's other tools they use to protect core Gmail users. The Joe Job emails stopped (I'd repeatedly get emails about send failures sent to me in regards to the Joe Jobs prior, and the occasional complaint). Not 1 more complaint or send failure notification.

Re:Consider Gmail for your Domain (0)

Anonymous Coward | more than 7 years ago | (#19618601)

Or just spend 5 minutes and put the SPF records in your own domains.

strong authentication an important building block (5, Informative)

Thede (745407) | more than 7 years ago | (#19616577)

SPF is easy for sending domains to implement, which is one of the reasons it's becoming popular. During the last six months we've seen a major increase in the number of domains that use SPF (including many of the big ones) as well as an increase in the percentage of messages we receive from an SPF-protected domain.

As far as its effectiveness goes, in one analysis where we sampled a set of messages in which the purported sender's domain was that of a major ISP, we found that if the SPF authentication check returned 'softfail', the probability of the message being junk was near 100%. When we checked our MTAs "Received" headers, they indicated that the messages were being sent from IP addresses in different countries and domains (as one would expect). Of those messages that passed, only about 30% of the messages were junk. Clearly there is 'signal' in the SPF score.

Interestingly, of those messages that passed and yet were junk (those that composed the 30%), all appeared to be sent by a legitimately registered user at the ISP. This is the double-edged sword of authenticating your messages if you are an ISP: if your own user base is sending junk, other ISPs and recipients will be able to figure it out. And you might be perceived poorly.

Yet this is exactly what should happen; it's the point of authentication. There should be motivation for ISPs, either financial or brand-related (which ends up being financial), to establish and operate procedures that screen members or deter them from sending unwanted messages. Reputation (or concern of damage to it) is a great motivation.

The real promise in sender-authentication though is DKIM. While SPF is easier to implement for senders than DKIM, SPF is rather fragile; it doesn't survive forwarding without re-writing the envelope-from. Too few systems are set up to do this (list management software is the exception), and although changing the behavior of MTAs is just software, doing so will effect the efficiency of status (bounced mail) reporting. Messages that would be delivered 'point to point' in the past end up being 'source routed' with many unnecessary hops, increasing the odds of failure. DKIM is a little more involved to set up, but doesn't have these fragility issues (setting up checks when receiving is about the same level of difficulty for SPF and DKIM).

At Boxbe, we check both DKIM and SPF. The reason is that strong sender identity gives a pre-approval policy its teeth. We quarantine messages which fail EITHER form of authentication, but because DKIM is "forward-friendly" and SPF is not, if a message passes a DKIM check but fails an SPF check, we let the message pass (according to our member's preferences). Using both has merit as each type is a little different. Gmail has been signing/authenticating with both DKIM and SPF for quite some time. We also use both forms of authentication when we send out messages or forward messages to our members.

As other organizations adopt sender authentication (Comcast has announced [emailexperience.org] it is implementing DKIM by year end) it will become a very effective tool.

--
Thede Loder
E: thede@boxbe.com

SPF and DNS amplification (2, Insightful)

EricFenderson (64220) | more than 7 years ago | (#19617007)

This issue gets bandied about at work (a hosting company) quite frequently. In my eyes, there are three major issues with SPF that make it more or less worthless:

1) People typically don't have a good idea of all of the IPs that originate email for their domain. Sometimes they are overly restrictive, causing blocks to their legitimate mail. Sometimes they're overly permissive and indicate that lots of the internet can email as them. This is like having a firewall with policies that unintentionally permit and/or block traffic.

2) SPF is a pretty poorly designed framework. RFC4408 is almost comical in how many times it says "You should never do this, it's terrible. Here's how to do it..." If the designers realized what a bad idea the PTR check is, why did they include it? I now have thousands of useless reverse DNS queries per second, sent only because someone didn't understand what they were talking about and didn't read the author's warnings.

3) Finally, TXT records make for a fabulous DoS attack tool. Since they are typically larger than other RRs, adding TXT records to your DNS reflection attacks can amplify the amount of generated traffic with very little effort on the part of the attacker. Interesting paper on this at http://www.isotf.org/news/DNS-Amplification-Attack s.pdf [isotf.org]

So all in all, I say that the payoff is very little for high costs. If you are going to publish an SPF record, and you aren't 110% sure what you are doing and what you want, just publish "v=spf1 ?all" and get on with doing better things.

Re:SPF and DNS amplification (0)

Anonymous Coward | more than 7 years ago | (#19618417)

People typically don't have a good idea of all of the IPs that originate email for their domain. Sometimes they are overly restrictive, causing blocks to their legitimate mail. Sometimes they're overly permissive and indicate that lots of the internet can email as them. This is like having a firewall with policies that unintentionally permit and/or block traffic.
Are firewalls also worthless in your eyes? No offense but of all the arguments I've heard against SPF that's the most specious. You need the relevant information in order to publish SPF records, just as you need details of network topology to author an effective firewall ruleset.

SPF is a pretty poorly designed framework. RFC4408 is almost comical in how many times it says "You should never do this, it's terrible. Here's how to do it..." If the designers realized what a bad idea the PTR check is, why did they include it? I now have thousands of useless reverse DNS queries per second, sent only because someone didn't understand what they were talking about and didn't read the author's warnings.
PTR checks are not entirely worthless. They're a simple way to authorize hosts across a domain, unfortunately it enables a 3rd party with control over their own RDNS to send mail that passes SPF. The first mitigating factors here is that most spam is sent via zombies where the spammers do not have control over the PTR for the sending host. The second is that bounces will not be sent from hosts with a PTR falling under the SPF record publishers domain. That's a fair result and is why PTR was deemed worth including in the spec.

Finally, TXT records make for a fabulous DoS attack tool. Since they are typically larger than other RRs, adding TXT records to your DNS reflection attacks can amplify the amount of generated traffic with very little effort on the part of the attacker.
Really? [openspf.org]

Re:SPF and DNS amplification (1)

EricFenderson (64220) | more than 7 years ago | (#19619997)

Are firewalls also worthless in your eyes? No offense but of all the arguments I've heard against SPF that's the most specious. You need the relevant information in order to publish SPF records, just as you need details of network topology to author an effective firewall ruleset.

If someone configures a firewall with policies that unintentionally permit traffic, then I'd consider that a major flaw in the deployment. I agree with you that one needs all the requisite information to craft an SPF record. A major problem is dnstools.com saying "Uh uh, no SPF record!" to a user that doesn't even have a basic understanding of the issue, let alone all the information required. I'm mostly saying that it's usually a very error-prone process.

PTR checks are not entirely worthless. They're a simple way to authorize hosts across a domain, unfortunately it enables a 3rd party with control over their own RDNS to send mail that passes SPF.

Thus circumventing the control SPF alleges to enable?

That's a fair result and is why PTR was deemed worth including in the spec.

Right, but at what cost? Tons of our customers put ptr:hostingcompany.com in their SPF because they think that says "authorize anything from my hosting company". So mail servers all over the internet that are checking SPF are sending tons of unnecessary RDNS traffic to us. And it is unnecessary because that SPF cannot possibly be correct. Maybe this comes back to my point above about it being too error-prone, but I want to highlight the burden this will put on the DNS infrastructure. Our DNS is authoritative for somewhere around 100,000 zones. Every single customer of ours with such a misguided SPF record directs tons of mail servers around the internet to hit our DNS for those RDNS entries. And think of the root - everyone with these SPF records that are incorrect are going to be hitting the root.

http://www.openspf.org/draft-otis-spf-dos-exploit_ Analysis

It's an interesting rebuttal, but it totally misses the point. Yes, NS and MX are exploitable in a similar way as SPF TXT records. Unlike SPF, we simply cannot live without NS and MX. So we take the good with the bad. But SPF? Hardly necessary. Also, it doesn't begin to address the fact that legit TXT records simply make better sources of traffic for reflection than other types. A simple way to use this amplification is to reflect TXT answers at your target instead of some other smaller query type. Bingo, more traffic at the target sourced from innocent third parties.

If you've never had a major attack on your DNS infrastructure, or had your DNS infrastructure used in reflection, I can see how you might not think this is a big deal. Relatively small amounts DNS traffic is easily crippling if that traffic is chosen well, and the attack is executed decently. What's worse is that it's not particularly difficult to execute such an attack. And if the attack is done well, there's more or less nothing you can do but try to grow your DNS servers fast enough to handle the queries. Protecting the DNS infrastructure of the internet is far more important than protecting people from unsolicited email. I don't mean to be diminutive of the spam problem - it's huge. But DNS is just so much more critical it's not worth the risk.

Yes they work - kind of (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19617669)

I work at a hosting company, which means I deal with people frustrated over email forgery all the time.

SPF records are in no way a perfect solution (though if everyone implemented it it'd be good enough), however it is pretty much the ONLY solution that is effective at all at this point. They cost nothing and they benefit you and the millions of people who will not be receiving the SPAM because of the SPF records. Do it, do it now, and tell everyone else you know to do it too. The more people that use them, the more likely the providers are to implement it.

e-commerce provider mandates all customers use SPF (2, Interesting)

gru3hunt3r (782984) | more than 7 years ago | (#19622197)

http://www.zoovy.com/ [zoovy.com] Zoovy.com is an e-commerce provider that requires all customers using their mail service to use restricted SPF records for their domains. This has cut down on our SPAM being sent both to and more importantly *from* our domains by spammers considerably.

The problem is most ISP's and other hosting providers don't control the entire e-mail application stack enough to implement it without an army of technical support people, it's just not economical. That and diagnosing mail problems is too freaking difficult for low level helpdesk people.

It's like credit card fraud, the entire system will need to be retrofitted before it can be significantly reduced or even eliminated, but the short term of cost of dealing with fraud outweights the long term upfront cost of retrofitting billions of dollars worth of swipes, magstrip readers, and point of sale systems.

Eventually the problem will get bad enough and/or a big mail provider (hotmail, gmail, yahoo) will grow a pair and start flagging email that arrives at domains without SPF as spam. Either that or something like Y2K will happen again and require everybody to update to stuff that supports SPF, this could be as soon as 2010 when we run out of IP addresses.

Wouldn't hold my breath though ... my prediction is it will probably happen sometime after IPv6 is rolled out.

SPF is broken by design (2, Interesting)

eneville (745111) | more than 7 years ago | (#19623291)

Consider the following:

S: 200 happy to meet you sir
C: helo example.com
S: 220 happy to meet you
C: mail from:
S: 220 ok
C: rcpt to:
S: 220 ok
C: data
S: 220 begin
C: Subject: v1ag7a
C: From: customersupport@ebay.com
C: To: you@yourdomain.com
C:
C: message body
C: .

You see how the mail from envelope can be manipulated to hold a domain that differs from the message body headers. This is ok for SPF since otherwise it would break email lists.

What it might do is help prevent back scatter spam from hitting your domain if the original recipient's mail server DOES check the SPF for the mail from... that is all.

Sunburn (1)

dg41 (743918) | more than 7 years ago | (#19700135)

No, but it does help protect against sunburn.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?