Slashdot Mirror
Microsoft to Deploy SPF for Hotmail Users
wayne writes "In a show of just how much Microsoft wants to put an end to email forgery, Hotmail, MSN and Microsoft.com will start enforcing Sender ID checks by Oct 1. In late May, MicroSoft announced that they would be adopting the Open Source SPF anti-forgery system (with a slight modification to make it Sender ID) and they have been working together with the IETF MARID working group to help create an RFC to define the Sender ID standard. Already tens of thousands of domain owners, such as AOL, Earthlink, and Gmail, have published SPF records, and thousands of systems are already checking SPF records. Publishing SPF records is easy, as is checking SPF records."
Why not just use PGP or GPG? I for one, would like to see greater implementation (read: any implementation whatsoever) of these systems in the more common web-based/free email systems such as Yahoo and Hotmail.
The old Lie: Dulce et decorum est Pro patria mori
To me this sounds like a positive step. I'm just wondering what the Microsoft haters will post about it to make it sound like a bad thing...
Ok.. Let me make sure I understand this correctly..
I maintain a few domains, such as a Sq7.org, from which I send e-mail.. I send it from home, from my girlfriends house, from wherever I happen to be.. But I send it by connecting through the sq7.org server, and forwarding mail through there.
The way I understand SPF, I just need to publish that the IP sq7.org runs on is authorized to send Sq7.org's mail, and NOT the IP for my home, office, etc, since I don't send directly from the local computer.
If I did send directly from the local computer, without going through the external server, I'd need to add my local IP to the SQ7.org DNS records.
As it is, though, I'll need to avoid using my ISP's SMTP servers if mine go down, or add them to the domain.
Am I understanding this right?
-Colin
Colin Davis
Damn, now I have to read the article.
If noone rtfa, then what's the slashdot effect?
Wait a second. Microsoft is willingly employing open source market software? (looks at calendar).. hmm.. it's not early april. It's either armageddon, or old dogs can be taught new tricks!
pm
** "It's not my job to stand between the people talking to me, and the ones listening to me." -- Pego the Jerk
they'd shut down hotmail, buy aol and shut it down too.
Let's hope this method of reducing spam will work. I have noticed that less spam I receive comes from Hotmail, Yahoo, etc. type e-mails, but hopefully this will help more. I am curious just how much work is involved in publishing these lists, and more importantly, how often are they updated? If they don't get real time or near-real time updates, they aren't going to be very useful.
Does this mean that if my email doesnt ( or cant, as i admit i dont know enough about SPF to know ) comply to what they feel is the 'answer', i can no longer send email to hotmail users?
While I'm also against spam, is allowing a large monoply to force the use of a particular method the proper route to take?
---- Booth was a patriot ----
Umm... damn, I just saw a pig flying by my office window.
"Glory is fleeting but obscurity is forever" - Napoleon Bonapart.
Microsoft to Deploy SPF for Hotmail Users
So, now that Microsoft already dominates the OS and free e-mail markets, it's trying to get into the sunscreen market as well?
I don't know which is worse, the cure or the disease.
"Have confidence that mail that SAYS it's coming from your bank, your credit card company, or the government really is!"
The problem arises though when the phisher/spammer uses a domain which is fairly similar to your bank or credit cards website, for example www.XYZCapitol.com instead of www.XYZCapital.com.
I sig, therefore I was.
Next year MSFT will release SPF15 for those needing additional protection. SPF 30 and 45 to follow for those extremely pale nerds who never go in the sun
Messages that fail the check will not be rejected, but will be further scrutinized and filtered, said Craig Spiezle
A failed PRA check will be a "factor" that Microsoft's SmartFilter technology will use to determine whether a given message is spam, according to George Webb
Microsoft has no problem using open source software. The surprise is them admitting it.
Will the mentioned "slight modifications" made by Microsoft to create the Sender ID standard also make it different enough from the OS SPF to call it proprietary?
For woe be the day MS openly embraces a developing standard not of its own design!
A psychopath can't tell the difference between right and wrong. A sociopath knows the difference - he just doesn't care.
Hey, Microsoft willingly employs HTTP as well! Maybe this open-source thing isn't so bad after all!
(sound of head beating against wall here)
The World Wide Web is dying. Soon, we shall have only the Internet.
I always get a cold chill when I read a phrase like this:
"In late May, MicroSoft announced that they would be adopting the Open Source SPF anti-forgery system (with a slight modification to make it Sender ID)" [added emphasis]
After all, their Kerberos change for Active Directory was only slight as well, and *that* didn't cause any problems, did it? Anyone have any details on these new 'slight changes'?
Is there a easy guide to deploying SPF on Windows 2000's DNS Service? Something that I can give the MCSEs who run our IS team and get their attention would be appreciated.
Go somewhere random
*hot*mail. I'll start using SPF-90 sunscreen while handling hotmail.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Okay, all I know is that SPF is a good deal simpler than SenderID and much more popular, due to the simple text format verses the use of XML.
However can somebody please clearly explain what (if any) differences there are between what they do. I mean after the data is decoded, is one of the superior to the other, or a superset of the other? Or are they totally independent checks, or are they slightly intersecting checks?
Honestly I can say I am extremely happy to see Microsoft adopting a standard that was not proposed by them. They should learn from this, the amount of good feelings they engender by doing this and resulting increses in sales of their other products and increased cooperation by other programmers probably outweighs any monetary gain from a proprietary solution by a hundred fold or more.
Publishing SPF records is easy, as is checking SPF records."
Only if you can edit your own DNS records, most management tools only allow modification of A, MX, and CNAME records. For this to really take off the tools need to add support for TXT records.
Generally, I like this idea, especially from the perspective of controlling misdirected bounces.
Where it seems to be a problem though (someone correct me if I'm wrong), is in a case where someone, for example is doing web hosting and controls a domain, and the customer wants to configure his e-mail client to send mail "from" the domain through a local ISP. The way SPF works, the authorized hosts from which mail with that domain in the header must be defined in the DNS records. This means that if the hosting company isn't the customer's ISP or mail relay, he needs to keep track of what mail relays the customers use. If a customer changes ISPs and doesn't have the DNS info updated, then their mail may suddenly be rejected by SPF servers?
This seems to be good for ISPs and services like Hotmail and gMail, which endeavor to have exclusive control of incoming and outgoing mail under their domains, but for smaller ISPs or scenarios where one person may be managing the domain, with the customer using a local ISP/mail relay, it seems to be a big pain in the butt.
They are making all kinds of changes lately-- and they are not bothering to send anything to their users. I've been an MSN customer since just after they started up the service. Last week Outlook couldn't pull my email from their pop3 server any more. I sent in a help ticket. The reply I got said it was a problem they were fixing- and gave me instructions to set up Outlook Express to pull web mail from an http server.
I responded that I don't use Outlook Express, I use Outlook 2000 and it will only pull Email from pop or imap servers. Their response, upgrade to Outlook 2002 (or above) or just use the hotmail interface. Of course using hotmail means no more hot syncing to my palm and I have to start manually sifting through spam again (my filter I use is an Outlook plug in)
I had been thinking about changing my ISP but now I don't even have a choice.
What ticks me off most is there was no advance notice of these changes- and it took multiple emails to MSN support to find out what was really going on.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
That Microsoft is taking part is to their credit. Finally the Internet at large is going to actually try to apply a solution to spam at the source. Although the unsolicited commercial email problem is largely one of perception (as with violent computer games, smoking in public, or 'indecent' radio broadcasting) perhaps the solution will have less of a negative impact on society. One can only hope.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
No, you missed the part about "(with a slight modification to make it Sender ID)".
Standard Microsoft "embrace and extend" technique.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
I have a couple of domains registered and pointed at a cheap shared host. I generally send mail using either Mutt over ssh or Mozilla via several different SMTP servers (cablem modem ISP, web host ISP, work SMTP server) and I routinely edit my from address to use whatever userid and whichever of my domains is relevant.
I guess this change means that hotmail users won't be able to receive mail from me unless I read up on SPF and figure out how to get the appropriate configurations into my bargain basement DNS and hosting configs. I hope this doesn't require any administrative privliges since I don't run my own DNS or mail servers for my domains. You can't do that sort of thing for less than $20/month.
Now if only our anti-spam group would add SPF records. They're deep in the Redmond camp, so the phrase "Microsoft is doing it" should convince them.
This is very nice comparing to what others do: nothing.
The SMTP protocol have sucked for ages, and we applaud any action taken to improve it.
No they don't. If they did, the Browser Wars would be largely irrelevant, and people could pick what they liked instead of being forced by 'this site best view with...' requirements. Spoofing the user agent never would have needed to be invented.
The living have better things to do than to continue hating the dead.
it will make it more harder for guys like me to run an SMTP server on their own Linux box from a dynamic IP address. And it will do pretty much nothing to prevent spam.
Um. . .isn't that the point of open source?
I think I'll stop here.
It was just yesterday I think, that someone on here was saying that it would take MS, Yahoo, or AOL to start using SPF to drag the rest of the world onto it. I have looked at it, but I haven't started using it. Once a few sites start rejecting me for not using it, I guess I'll have to add the records. There was a wizard somewhere for generating the SPF records you would need for your domain. Time to look it up, I think.
Get your own free personal location tracker
Okay, now we can verify that a mail server that says it is someserver.com is really someserver.com. Back when the big problem was open SMTP relays that sure would have been helpful.
But now that the problem is spam zombies on millions of user PCs, how will this put a dent in the problem? Sure they won't be able to connect directly to Hotmail to say they're someserver.com, but it won't stop them from sending spam through their own ISP's mail server. Since the key to spam zombies is having a lot of PCs that send relatively few spams per PC, it will be very difficult for each ISP to track down and stop each zombie.
I refuse to buy a handheld/laptop/desktop with MS software - such is my hate. Nonetheless, this is a great thing:
- They are going about it the right way (IETF rfc as an open standard, open source system)
- They have a lot of weight to actually make it happen
- This is something that should have been done a long time ago.
If they modified things from other proposals, I don't care. This is just something that simply has to happen!
So despite coming from microsoft, this is great news.
Will it be SPF 15 or SPF 30?
But they were registered using GoDaddy, with Hostway nameservers. For this to really get off the ground, the regular hosting companies have to support it as well. The only registrar that offers spf is (that I'm aware of) PairNIC
.
What scares me is that this could be the first step to controlling email via certain companies.
What if BIG CORPORATION A decides to sell its assets running the SPF machines to BIG CORPORATION B and BIG CORPORATION B combines As and Bs machines. Eventually one BIG CORPORATION will own all the SPF machines or a very large portion there-of. Then what?
What about all the little upstarts who don't want to be bothered with figuring out SPF or understanding people's desire to use it? What if a time sensitive e-mail (yeah, yeah, e-mail should not be used for critical info..blah blah blah) is slowed from getting from its origin to its destination? How could this system be abused - aside from the computing end of things?
E-Mail tax? You know, the tax that could be enacted to pay for the cost of running the system should GOVT n decide to use it? See where I'm going?
Maybe my fears are unfounded.
{Don's asbestos suit.}
That would be Despite. Just had to correct myself before someone else does.
So umm, a service that MS wants every email server on earth to access, gets slashdotted?
Yeah this will work...
I have a couple domains that I host myself, but those don't even have MX records, and I never use them for email.
:).
On the other hand, the first domains I purchased were with register.com. As far as I can tell, there is no way to include SPF records using their web forms. In theory I could use my own DNS servers, but theirs are obviously more reliable
In my view, for this to take off, hosted DNS providers really need to get behind it.
autopr0n is like, down and stuff.
I am unconvinced this scheme will make much of a difference in the spam epidemic.
If anything, the SPF idea primarily favors the big ISPs and consolidated mail services. Microsoft and others aren't doing the industry a favor at all by adopting this standard. It clearly benefits them more than it does small and medium-sized Internet hosts. I am under the impression that for any Internet operation that doesn't control all the inbound and outbound mail for domains they manage will have a much higher administrative burden than the big guys. So this scheme makes sense for large ISPs and costs more time and money for smaller ones.
And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant. Until the lion's share of systems adopt SPF, no ISP can afford to arbitrarily reject non-compliant systems.
This scheme seems to heavily favor the "all-in-one" Internet companies, who manage both sending and receiving. If you're having one company manage your domain and using a local ISP for SMTP, then you run into problems. As an owner of a hosting company, if this scheme were adopted, I'd probably get several phone calls a day from customers freaking out that their mail bounced, and even if I had an automated system where they could specify authorized smtp hosts, I'd still have to waste a bunch of time explaining to them that if they configure their local client to be "from" their domain, and they change ISPs, they need to update these records as well.
Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.
I send mail from my home server through my ISP as a smarthost. DNS is managed by another company (easyDNS). I assume that I would have to have my DNS provider enter the SPF information, since I don't manage it myself. Do most DNS providers allow the user to enter data like this in the TXT record?
You are correct. Although, you could add those other IPs if you wanted to, and send directly from those machines.
autopr0n is like, down and stuff.
Good point. This has certainly happened in the past. The XML standards is one counterexample but there aren't that many of them. I can only hope that they won't "extend" a broken supposed standard and wind up falling short of the mark.
Can the pebbles still vote, or has the avalanche has already started?
-- less is better.
SPF requires that you know every mail server that will ever relay mail for your domain. This is unknowable. I manage 40 domains, people using these domains for email regularly travel to branch offices where they change their outgoing smtp server to whatever server is local to that office... I'm talking about a rotating list of around 1000 smtp servers that have to be on all 40 of these domains... That is the most unmanagable hack I've ever seen. This is not one company I manage small domains for contractors that need to be able to have 1 email address, but that are constantly moving to different physical locations, and using many smtp servers. Furthermore, VPN is not a solution as most of the time they are on heavily firewalled and NATed networks where VPN does not work reliably. Also, I work for a small ISP and many of our users use our outgoing smtp server to relay mail for their work accounts that don't have VPN set up for them. All of this email will now be summarily rejected.... whoever came up with SPF is an idiot, thanks for breaking email, this is the death of it.
Is SPF validation done against the hostname of the originating SMTP submission PC, the SMTP relay, or the hostname as indicated in the "from" or "reply-to" address of the mail header?
Ah yes, an twist on the old profit algorithm ... ....)
1. Embrace
2. Extend
3.
4. Profit!!
This is the same company that puts wierd ascii shit in my pine terminal when the email comes from an outlook client. They will fuck with this standard (as they did with OpenGL, Networking stacks, Internet Browsers
me> Guess who has been in the Committee designing the RFC.
stoopid_us_boi> *looks* uh im juss a stoopid us-boi hwo shud i now tihs???! w00t!!
me> It's Microsoft.
They adopted that, a while ago.
emt 377 emt 4
What we'd really need is a completely new email system. The system right now is very complicated, both for "tech people" and for end users. We've got POP, SMTP, IMAP, you name it. Sometimes, SMTP requires login, sometimes not. There's a myriad of old protocols and standards out there that needs to be replaced with new technology.
:-)
What we need is ONE protocol for sending and receiving mail. Let's call it UMP, Universal Mail Protocol. Each domain has one (or several) UMP servers, and a DNS record for looking up the IP number of that server.
When sending email, your domain's UMP server makes a DNS lookup on the recipient's domain and contacts that server. The receiving server looks up your domain's UMP IP number (based on the From-address) and compares it to the machine it's connected to. If they match, the receiver can be sure that it's really sent by the sender.
This would make setup very convenient for the end user!
The only thing to be filled in is: a) email address, b) password.
There's only one server to deal with, which is resolved from the email address.
Of course, this is hard to implement because of lack of backward compatibility, but I think it's worth it.
Just my two bits. Flame on!
Sig Nature
Are we shure this is compatible with plain old spf? Didnt like the 'modification' bit
NO SIG
...that both the DNS server and the mail server for my personal domain reside on machine happily humming away in my basement.
It's nice to be able to have truly full control over how my email is handled. Here's another reason:
>uptime
11:01am up 251 days, 11:23, 1 user, load average: 0.05, 0.01, 0.00
Which is basically since I performed the last OS upgrade. It runs nice'n'stable Linux and since it only handles email for a few email accounts as well as being the file and print and database server for my home network it's hardly stressed at all (as indicated by the load average). Plus the way it is set up I can accept 32MB attachments and a mail quota of 10 Gigs, both of which I can change any time.
Sometimes it's good to be a geek...
From the article: Messages that fail the check will not be rejected, but will be further scrutinized and filtered
No gain without pain. Spam is pain in the butt to everyone. No anti-spam measure has no collateral damage at all, but where the gain outweights the pain, it's worth doing.
autopr0n is like, down and stuff.
SPF is good, but what about the ability to forge email from user@localhost, undisclosed.recipients@yourdomain.com, etc). These are security holes large enough in the SMTP protocol to drive a truck through... Most people run on the default Sendmail rulesets. If they can't send but from your domain, they will forge their way though with the broken rulesets and other hacks...
Someone needs to make a new "secure" SMTP protocol... We can't use this public/broken one and keep adding on to it when there are so many other problems...
SPF should be used with a PGP public key database which can be queried by SMTP along with ordb.org and the usual access lists.
Spammers start forging email headers using the hotmale.com domain...
... ebay.com, which appears not to be publishing spf or CallerID/SenderID secords. Way to go Ebay.
lets say one is:
example.com
I currently use Eudora to send email from my primary ISP (earthlink) , but if I want the mail to "appear" as though it is coming from
me@example.com
all I have to do is create a "personality" in Eudora. I use Earthlink's smtp and the only thing I see in the headers is this:
X-Sender: me@example.com (Unverified)
Date: Fri, 23 Jul 2004 12:08:28 -0500
To: user@earthlink.net
From: Microcars (me@example.com)
Subject: test
there is just this (Unverified) line in the X-Sender line, does this mean I will no longer be able to use this function of Eudora?
I can set up POP mail accounts for these domains, but I have to use the WEBMAIL feature of my domain's host because Earthlink blocks port 25 and will not allow me to use another SMTP server (can't use .Mac at home either because of this)
I like microcars
I use a forwarding address from my alma-mater as my main personal email address (me@alumni.XXX.edu). They offer a webmail interface, but it sucks eggs. So I subscribe to Yahoo Mail Plus which allows me to send mail "from" any of my accounts (they verify the account before letting me do this), and I can also consolidate several accounts there in one nice interface. When I send email from Yahoo "from" my alumni.XXX.edu address, it comes from Yahoo's outgoing server, and the SPF record from alumni.XXX.edu wouldn't match (if it's there at all).
Is there any mechanism in SPF (or Sender ID) for this email setup?
Try the story blurb.
So now spammers need to forge the envelope as well as the sender field. No big deal. This will neither destroy annomymity nor stop spam. It just won't work.
You are right, keeping the From: and changing Reply-To would work. Also, the change that MS proposed will check "Sender:" before checking "From:"... so you can actually keep From: as your permanent address and set Sender: to your mobile address. ISPs and corporate IS folks should also provide SMTP AUTH servers, so that remote/mobile users can use the same server they would normally use. This is not new (RFC2476 is 5.5 years old) but SPF will put more pressure on folks to follow the SMTP AUTH scheme.
It is; provided that you share the changes you make.
UNIX/Linux Consulting
'Enforce' SPF so that you cannot send to hotmail at all if you dont 'have' an SPF record.
NO SIG
The primary difference between SPF and Sender ID is that Sender ID also has the ablility to check the RFC2822 From: email header in addition to the RFC2821 envelope from value. This is something that most of the people in the SPF community wanted to do all along, but it would require changes in end-user mail systems, such as outlook, to do right. Without the support from MicroSoft, this couldn't really be done.
(Yes, I posted this once but it appears to need repeating.)
SPF support for most open source mail servers can be found at libspf2.
This problem has another form, too. More of an extension of it, I guess. I have a domain hosted in the fashion you mentioned; however, due to restrictions on accounts provided by Earthlink, the ISP I am currently forced to use (only thing really available in my area), I *must* use their SMTP servers, their filtering technologies prevent me from using the SMTP server provided by my domain hoster. So, in short, wide acceptance of SPF will screw me from being able to send emails *from* my hosted email addresses.
I have discovered a truly remarkable sig which this margin is too small to contain.
They generally extend it in such a way as to make you reliant upon Microsoft products. Take Internet Explorer, for instance. It is infamous for having more features than any other browser -- most of which go unused, many of which have created large security holes and other unwanted annoyances, few of which actually work according to spec -- but by being the first to market with new features, people found they could have fancier websites by using IE. Hence the masses adopted the pretty interface and they took over the browser market with a product that is inferior in many ways. People are afraid of Microsoft repeating this pattern in such a way as to privatize software and protocols that are currently open-source or public domain. Take a look at their recent patent applications for further evidence of this trend.
It is even more of a problem in cases where users don't have access to their DNS records.
I use dyndns, and they do not support SPF for free dynamic accounts.
SPF might be a good way to start letting home broadband users access port 25 outgoing again (many ISPs block it now). However, it has to be supported by dynamic DNS providers for it to work.
The thing I don't like any many suggested Internet reforms is that they run counter to the original peer-to-peer nature of the Internet. It used to be that anyone could run a server of any kind, or connect from anywhere to anywhere. Now with NAT and reforms like this, you have to pay a fortune to get this kind of network access (paying for IPs, paying even more for static IPs, paying for domain names, paying for DNS, etc).
A great opt in solution... .. If you don't have SPF records in your DNS, it doesn't mean Hotmail won't accept your mail.
:
If you DO have SPF record for your domain, and the message wasn't sent from one of the specified IP addresses, then Hotmail may block your message.
But the real kicker is when you recieve a message from someone@hotmail.com. If the IP address used to send the message isn't listed in hotmail's SPF TXT DNS record then you know it's not a message sent from hotmail. And same for Gmail
dig -t txt gmail.com
gmail.com. 300 IN TXT "v=spf1 a:mproxy.gmail.com a:rproxy.gmail.com -all"
Which means that the only servers authorized to send mail from @gmail.com are mproxy and rproxy.gmail.com
Basically, there will need to be a shift in email hosting paradigmns. Instead of the concept of recieving email from your hosted server and sending through your local ISP's smtp, you will instead need to send through the hosted server. Most web/mail hosting providers out there allow for outgoing smtp via smtp authentication. And if they don't, well, perhaps they need to start.
Don't delude yourself - there's nothing 'open source' about SenderID - it's going to be an IETF standard - it has nothing to do with source code of any kind.
Funny how the open source community feels the need to grab on to anything that seems good. To bad that this whole idea is the result of several corporations trying to solve the spam problem (Microsoft, Yahoo, and others.) The end result will be a compromise between what these companies want and will be an internet standard.
The open source community is just sitting on the sidelines - waiting for the standard - so that they can copy it just like they do with everything else.
Yes, but there's not many free ones, nor cheap ones. DynDNS, for example, only offers TXT records (required for SPF) only if you pay for Custom DNS, which costs $25 yearly. I don't have too much money to spare.
I heard that SPF breaks forwarding - is this true? When the receiving mail server gets the mail at his port, does he check the client who is sending the packets against the SPF record?
They have. I would invite you to go to the SPF site and read a little on the additions to SPF from MS.
I am as suspicious of MS as the next guy, but I think this was done on the up and up.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
I can think of 3 options for a web host.
1. Provide a webmail service customers can use when they want their domainname on the From: line. Many already provide this but those plans cost a bit more.
2. Provide authenticated SMTP so the customer can use use their own mail program. Many clients support authenticated SMTP and multiple "identities" so a customer can switch between different From: lines & SMTP servers. I think this kind of service is relatively uncommon and providers would run the risk of being labelled as spam sources if their customers had a bad habit of letting their passwords get stolen.
3. Provide a web interface so the customer could update their domain's SPF record. If they switch ISPs (or are just visiting somewhere), they can update the record themselves. This would require the least amount of resources on the webhost's part.
I think what we're going to see is being able to use your domain name on the From: line as another differentiator between webhost pricing tiers. You want to receive mail @domain? That's $X/month? YOu want to also send mail from @domain? That's $X+2/month.
I have the impression that SPF is going to create a lot of problems to universities.
A couple universities I've been to do not allow external SMTP connections. Users need to use their ISPs' SMTP server to send email. I couldn't find how the SPF can accomodate this practice without significant change: either the university allows authenticated external SMTP connections or ISP provides another authenticated SMTP server for these users (to user whatever address they want).
A sig is redundant.
Um. . .isn't that the point of open source?
That depends on the philosophy and license. The BSD license philosophy is "good will prevail over impossible odds even if proprietary companies take everything, copyright it, and use it to hamstring the world!". The GNU GPL philosophy and license is "this is the real world. Proprietary companies will have no conscience about hamstringing everyone. Whatever change you make you must release it as GPL."
Some people say that BSD license is faithful and bulletproof. I feel it's naive. Some people say GNU GPL is snobby. I feel it's realistic.
+++ATHZ 99:5:80
Sender ID is the merging of MS Caller ID and SPF. It takes the SMTP server authentication of SPF, and merges it with the From: header authentication of Caller ID.
It is a Good Thing.
Ironically, the word ironically is often used incorrectly.
Isn't this going to wreak havoc on people who use their ISP's SMTP server when sending mail "from" other accounts (like, say, a work email account) because their ISP blocks outgoing SMTP port 25, and therefore they can't connect to their work's SPF-configured SMTP server? Or people who run their own email server and are forced to relay outbound mail through their ISP's SMTP server for the same reason?
Oh, the humanity!
The thing I don't like any many suggested Internet reforms is that they run counter to the original peer-to-peer nature of the Internet. It used to be that anyone could run a server of any kind, or connect from anywhere to anywhere. Now with NAT and reforms like this, you have to pay a fortune to get this kind of network access (paying for IPs, paying even more for static IPs, paying for domain names, paying for DNS, etc).
In the old days, anyone could run a server of any kind. But it wasn't cheap.
The organization that provided them the LAN which was routed onto the Internet was paying for a T1 similar access.
They might be paying $1200/month for that and 24/7 internet access for $50/month did not exist back then.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
Alternatively, you could connect via some other port than 25 to the SMTP server you want, assuming earthlink is filtering on the port number.
In the very worst case, you could set up some SSH tunnel or VPN connection to the SMTP server in question and use that.
Who's MicroSoft?
Is it too hard to ask that you get the capitalization right of one of the most well known tech companies of this century?
In theory this idea sounds ok, but there are a few fundamental flaws:
1. It only really works if everyone adopts it, so right off the bat, the potential usefulness of the standard is dubious at best.
2. It takes the extreme approach of requiring every host on the Internet to have information specifying authorized relays and hosts.
I still think my idea of an SMTP WHITELIST is more practical than this scheme. Only a fraction of IP space can be considered legitimate SMTP relays, so it makes more sense for those that want to set up an SMTP relay to have to go through any hassle to have their relay recognized and approved. Why make EVERY system on the planet managing domains have to authorize additional parameters for every host?
SPF also doesn't potentially stop the spread of worms and viruses from infected broadband customers. If an ISP authorizes cable/DSL users to send mail from their IP space, then the worm propagation will appear legitimate to SPF-compliant systems. Furthermore, the SPF scheme doesn't do anything to reduce bandwidth - in fact it adds to overhead and basically establishes a system where large ISPs basically continue to let their customers run wild with worm/spam propagating, but might, as an aside, broadcast a few extra bits of information to help other systems decide if the rogue users they have should be listened to. As a result, the ISPs can basically refuse to regulate the illegal activity of their customers in favor of a few 10-minute DNS updates.
I'd estimate that there is probably 1 SMTP relay per 5,000+ domain names in service. The SPF scheme dictates that all 5000+ domain records require special configuration/approval, as opposed to suggesting the 1-in-5000 SMTP hosts have the burden of being authorized. This just doesn't make sense.
Who comes up with these ideas? They must get paid by the hour.
What's the biggest problem with spam right now? Zombie hosts: computers that should not be acting as SMTP relays yet are. The SPF scheme penalizes all systems and all hosts because the ISPs either won't filter port 25 traffic where it doesn't belong, or they won't efficiently contribute their DSL IP space information to RBLs.
We do NOT need a scheme where EVERY HOST on the planet needs to authorize themselves. We need a scheme where ONLY SMTP HOSTS authorize themselves. Instead of requiring 25,000,000+ separate configurations, we implement a system where the 250,000 legitimate SMTP relays are recognized as true sources of e-mail traffic. Then, not only do we shut out spam, but we instantly eradicate the propgation of 99% of all SMTP-based worms.
My mail server checks the existence of a valid mailbox at the sender's claimed address.
Half the spam my mail server receives arrives from valid hotomal.com yahoo.com and aol.com accounts
Except most ISPs block outgoing port 25 these days, so every user has to change his outgoing port number to communicate with the authenticated server. This is a large burden on any small isp/mail host. Making this change will mean a phone call from 80-90% of any consumer base. "What is this port thingy I've got to change to get my email to work again?"
Does anyone know if there is a validator out there that can check your settings for correctness once set in the DNS?
What about in the situation I have where I have to use my ISP SMTP server to send ALL the mail I wish to send since they disallow access to port 25 for all servers other than their mail server (ie send a person@yahoo.com email through my isp.com SMTP server)? Since I'm tied to this scheme, apart from using a web interface, will SPF work in this situation?
Even the samurai
have teddy bears,
and even the teddy bears
get drunk
Maybe I need to build sendmail from source a few more times...
Don't major e-mail daemons already have functionality to disallow mail that doesn't come from a valid system user? Don't major smtp daemons already have the facility for verifying the identity of the system attempting to pass mail to them?
If you want to send mail through your @xyz.org from your home @isp.com account then talk with the xyz.org admin, use user authentication on the xyz.org smtpd, or, as other people have pointed out, use the REPLY-TO line. My assessment is that spam only exists because there are sysadmins who don't know their jobs, don't care about their jobs, or secretly profit from spam. No amount of additional rules, regulations, or protocol implementations will solve the problem of bad admins. From this point of view its suspiciously evident that Microsoft is making a move to redefine e-mail standards with the interest of extending a legal controlling force over it in the future. If this move is successful it's possible that, in 10 years, a patented Microsoft encryption routine holds the Sender ID information and that subroutine is only available in binary form with a $1000/seat license.
Spam is getting to be just like politics. 88% of the people who have no clue what's going on want to write a million worthless fixes. Meanwhile the 2% of us who could properly integrate the existing system are shoved aside by 5% of people who are undesirable greed mongers. Think about it. Take 100 people. 2 of them are brilliant. 10 of them are greedy. 58 of them don't care, 10 are opposed, and 20 are gullible. It takes 5 greedy people to beat up the 2 brilliant people. The other 5 greedy people convince the 20 who are gullible. The 20 who are gullible whine enough so that the 58 who don't care persuade the 10 who are opposed to give in.
+++ATHZ 99:5:80
Not to nitpick, but that's the point of GPL, not necessarily Open Source. GPL requires sharing and GPL is Open Source, but Open Source isn't GPL.
The Glass is Too Big: My Take on Things
After reading this, I'm not sure I want to implement SPF on my domain. I use some features like pre-forwarding with qmail-ldap that will break because of SPF. And not to mention alot of the RFCs that it seems to break
I'm not sure where this "most ISPs" stuff is coming from, since I can't name a single one that block's outgoing port 25. Buy hey, what do I know.
SPF will make it harder for spammers to hide their identity and masquerade as someone else. In the short term, they will forge stuff using unprotected domains, but as time goes on they will have to buy their own domains. While SPF doesn't actually stop spam, it does take away some of the tools spammers use to hide their identities, and makes it slightly more expensive to send spam, and slightly easier to track and stop spammers. I believe that getting some kind of accountability back into email is "necessary but not sufficient" to solving spam. That is, SPF is not the Final Ultimate Solution to the Spam Problem, but it makes some other spam-fighting techniques possible.
Zoneedit.com is also free* and allows you to create TXT records.
*There are limits to zoneedit's free-ness. Basically it's free for fewer than 5 domains and less than 200MB of traffic (200MB is highly unlikely for DNS) but read their policy for details.
It's amazingly easy. There's a little wizard here you can use to set up your DNS.
I did this for my domains in about 5 minutes.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
First off, it hasn't happened yet. Nothing has been proven to work here, since they haven't actually done anything yet.
Second, SPF doesn't stop spam in the long run. SPF does not even address the problem of spam per se -- it addresses email forgery, and that not very well. In the unlikely event that every email system everywhere implemented SPF restrictions, spammers would still be able to send spam. They simply would not be able to send it under forged addresses in domains that publish restrictive SPF records. They could still send forged spam under domains that cannot (for their own reasons) use highly restrictive SPF, or they could send spam under their own domains.
(Yes, spammers have their own domains. Usually lots of them -- domain registrars' "bulk register" systems allow them to get LOTS of them easily. The registrars get their money, so most of them don't care that the domains are being used for spamming and the contact information is bogus.)
SPF is a case of "solving the wrong problem". The patient has a broken arm, but the quack doctor does not know how to set bones so he gives the patient an aspirin. But the patient's problem is not basically that he is in pain, but that his arm is broken -- the quack is solving the wrong problem.
The Internet's email system basically does not have a forgery problem. People who need to send each other forgery-proof email are already able to do this using systems like PGP. The email system does, however, have a spam problem. Though a good deal of spam is forged, the spam problem goes deeper than forgery. If SPF is widely deployed, spammers will just work around it ... just as they worked around the closing of SMTP open relays by deploying zombie viruses.
The spam problem is today one of ISP accountability, not email forgery. Spammers do their thing, and when people come around to complain, spam-friendly ISPs shine them on. No joke -- take a look around the Spamhaus Project, where professional researchers have tracked down the ISPs that do the most to help spammers.
SPF isn't the solution to spam. SPF isn't even the solution to forgery. But it makes nice headlines. People who want to look busy, and look like they are Doing Something to solve a nasty problem, sometimes don't care if the Something they're Doing is actually effective at all.
(Besides, honestly, why would you expect a company which itself sends spam for hire to actually try to stop spam? Microsoft bCentral operates some legitimate mailing lists, but it also allows its list operators to send unsolicited "opt-out" spam. This is an archive of reported spam sent using bCentral facilities.)
Does anyone see the challenge of getting EVERYONE in the world to adopt SPF tactics to stop spam? There will always be back-water companies who have an SMTP server who WON'T have SPF initiated.
Will these servers be blocked by the rest of the world? At least initially, this seems hardly fair.
So the only problem this poses to spammers is to find a few of those domain names that don't incorporate SPF records, and *tada*, they have a new list of email domains to zombify.
Computers are useless. They can only give answers. --Pablo Picasso
It was not my intention to imply sharing source. I was implying that one should share changes. The type of sharing could be as open as source code. It could involve more general descriptions.
UNIX/Linux Consulting
$ host -t TXT aol.com
aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
oooh, you know what I like about this? Not that AOL is using SPF and authorizing SMTP relays, but this advertises which SMTP relays within AOL's IP space it considers legitimate.
What someone needs to do, is use the information above as a mask against the whole of AOL's IP space and stick it in a big RBL. Then we don't need SPF; we finally have a method by which the troublesome ISPs can help us identify the IP space from which no SMTP service should be operating. I like it!
They're encoding the information into TXT records! Ugh, that is a complete hack.
Why not simply create a new record type?
Government of the people, by corporate executives, for corporate profits.
Wait a second. Microsoft is willingly employing open source market software? (looks at calendar).. hmm.. it's not early april. It's either armageddon, or old dogs can be taught new tricks!
No, it's worse. Duke Nukem Forever has just been released.
That would work, although I'm a big fan of making ISPs clean up their own network... if there are some hosts that shouldn't be sending outbound mail, then the cable or DSL folks should not be allowing crap mail to come out of that network. Also, some ISPs or companies will just list all IP ranges they own :) so you wouldn't be able to use it as a mask in that case.
The main point of SPF is to keep folks on totally foreign networks from impersonating you. Hopefully it won't be used by ISPs as an excuse to NOT clean up their own networks. But if used correctly it will help to shine a light on areas where crap forged mail tends to come from.
gregc
they start infrocing manditroy speleng chekcs.
500 dollar reward for tip(s) leading to the arrest of the person(s) who stole my sig.
Ok, I have been railing about how SPF is more of a pain than it's worth and primarily favors monster ISPs.
But I just realized that SPF will provide a an even more useful service for "the rest of us" that its supporters may never have intended.
Let the big boys adopt SPF. The process of doing so requires that they FINALLY publicize the location of their legitimate SMTP relays.
The larger the ISP, the more important this is, so even if only a few of the top ISPs adopt this standard, it solves TONS of problems for the rest of us who are constantly fighting off hoards of spam and worms from these big ISPs who won't regulate the unethical/illegal activities of their customers.
NOW, we look up the wholesale IP space of these AOLs, subtract the "authorized SMTP relays" they identify in their SPF records and we have a most excellent relay blacklist and a means to stop worm propagation.
Most of us have been trying to differentiate between rogue and legitimate SMTP IP space. Thanks to the goofy ITs at the top ISPs, we may finally be able to do this. Excellent!
Let's call this SPF-RPF. The process of them authorizing senders will finally allow us to authorize their legitimate mail relays and blacklist everything else.
I understand publishing my records... But how do I make my server check and verify against published SPF records?
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
No today is the day they released Duke Nukem Forever
I dont mean this as a flame or anything but, some of you really need to read on how SPF really works. The SPF Wizard should help you understand how it works.
Examples:
You only use the servers listed in your MX records to send mail. The SPF would look like: "v=spf1 mx -all".
A second example would be for people that have large numbers of servers. If they have an A record for every server that sends mail the spf record would look like this: "v=spf1 a mx -all" that allows all servers with an A record to send mail as well as servers with MX records.
Another example is if you use an ISP's e-mail server it would look like this: "v=spf1 a mx include:someISP.com -all" This then refers to the ISP's SPF record wile still allowing mail from any A or MX record for your domain.
My suggestion, play around with the wizard and read on SPF before you say it's not going to work. This implememtation will protect your domains from being spoofed. I think it will work.
Even the big dog, Network Solutions, looks like they don't allow you to add TXT records.
Might be helpful if a lot more people started to ask. :)
I'm not sure what the secret to success is, but the secret to failure lies in trying to please everyone -Bill Cosby
SenderID and the LMAP proposals on which it is based are focussed on anti-Forgery, not anti-Spam.
This is intended to make joe-jobs and phishing harder.
Note that S/MIME and PGPMail (also standardized in the IETF)
are better for this because they confirm it was a specific
individual, rather than sourced from a specific domain. But this
is a useful incremental step that may cut down things like
spurious bounces *exactly because the SPAMMERS can work
around it*. Since it does nothing agains the 9 dollar throwaway
domain, it is not going to stop SPAM--just make SPAM purporting to be coming from you just a bit harder.
The MASS birds of a feather session at the upcoming
IETF is intended to look at cryptographic DNS records for a similar purpose (think DomainKeys).
Both are things that reputation services can use as a substrate for further work.
So, it is a useful piece of technology, but please don't judge it by "stops all Spam", or you will conclude it failed at a task it did not take on.
SPF isn't a panacea; it simply forbids email forgery. If I can reject all forged email I have already taken care of most spam; for the rest I know exactly which domain is sending it to me. It reduces false positives: if the major ISP's and corporations use SPF, then my friends (and others) at those ISPs and corps can always send me email without running afoul of my spam filters. If I get spam from an ISP or corp, I know exactly where my complaint to abuse@ should be sent.
Unlimited growth == Cancer.
No, that's the point of Copyleft.
Software under the (contemporary) BSD license, for example, is both Open Source and Free Software. But it is not copyleft.
-Peter
If you control the domain that your email is from, then you simply need to change the DNS settings for that domain to add the proper SPF record.
Basically it's like this.. You have a domain like example.com. You send email from bob@example.com. But you want to send email through some other SMTP server, call it smtp.com, for whatever reason, and keep the From: line as bob@example.com. Since you control the domain, all you need to do is to change the DNS settings for your domain to add SPF records that say "smtp.com is a sender of email for example.com".
Problem solved. When a SPF enabled receiver gets your email, they query example.com's DNS, read the SPF info, see that it's okay for smtp.com to send email for that domain, and all is well.
Now, if you don't have access to your DNS records on that level, then I seriously suggest a) griping at your domain host/provider to let you have that sort of access, or b) switching to a new provider.
In the short term, however, this won't affect you at all. Not having an SPF record essentially means that the default will be used by SPF enabled receivers. The sane default, for the moment, is to allow email from anywhere in the event that SPF records do not exist on the domain in question (assuming SPF is being used as a straight block/no-block type of method, as opposed to a weighting factor in some spam prevention algorithim).
In the long term, eventually everybody will have to implement SPF if they want their email to be received by SPF enabled systems. But that's way, way long term.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Well, I hope this works and I'd love to see my ISP (adelphia) join in and verify the senders of inbound mail. For the last five years, I have blacklisted Hotmail, Yahoo, MSN, and AOL. Messages from these domains are sent straight to delete unless I have white-listed an exception for somebody I know. I do this because about 99.999% of the mail that I get out of those domains is spam (at least it was 5 years ago when I started. I don't know now, because it all gets deleted before I even get a chance to check and I don't log every inbound).
I would also be interested in knowing how much spam with "hotmail.com" and "yahoo.com" is spoofed and how much is really coming from spammers who are abusing real hotmail and yahoo addresses.
Ah, but you misunderstand, it IS all about me, as no one else matters..
Slashdot can be what ever I wish it to be, as I'm the only one that counts anyway.. Everyone else is just here to serve my needs and desires, immediately.
---- Booth was a patriot ----
SPF requires that you know every mail server that will ever relay mail for your domain.
RTFA: you can just add 'ipv4:0.0.0.0/32' and allow the entire internet to send from your domain.
Everyone is asking the same question, over and over again: I want to send mail via host 1, and have it claim to be from host 2. Host 1 is my ISP, and host 2 is my university account. Or, host 2 is my home system, and host 1 is where I am travelling that day. And they all want to know, will this stop me from doing that?
The answer is no, not right now, and maybe not ever. The only checks initially will be for those hosts who do use SPF to limit who can send mail claiming to be from them.
But the point is, surely you can see that by enabling the behavior you want, it will also be possible for any spammer anywhere to send mail claiming to be from you! If you want the power to be able to send mail from anywhere claiming to be you, without any authentication or checking other than your say-so, then you have automatically granted that power to the entire world. Anyone can claim to be you, and their claims will look just as valid as yours.
You might say, this is not my problem, it's the recipient's problem, who is getting fooled by a fake From address. But it is your problem, because it's everyone's problem. It's one of the most annoying properties of spam and viruses, that they pretend to be from people you know and trust.
This From-line munging is obviously an untenable approach in the long run. People who are doing this need to start thinking about other ways to manage their email. Otherwise it's going to get to the point where the From line of a message is meaningless.
Shouldn't you use SRV or EDNS0 records?
SRV records were, roughly speaking, meant for letting people add this sort of thing to DNS without having to add new record types. See also RFC2761, Extension Mechanisms for DNS.
Yes. But SRV records are hard for people to understand, and TXT records are easy. Fast widespread adoption is our goal. The Right Thing To Do is to get our own RRtype, and we will apply for it. We just don't expect to get it anytime soon.
(for SRV records, see http://dqd.com/~mayoff/tools/djbdns/make-record.a
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
In my mind, Sender ID and SPF have nothing to do directly with spam. They are designed to combat fraudulant e-mail headers, nothing more.
Granted, almost all of the current spam has fraudulant headers, but if Sender ID and SPF catch on, that will gradually change. Spam will simply be tagged with the correct relay.
One could say that illegal spam will be easier to track down, but that isn't really true... you can track spam with excellant accuracy today by following the linkage to the company selling the products. That linkage has to be accurate, or there is no profit to be had.
You could also say that spam will be easier to blacklist, but I don't think that is true either. Simple shifts in the spammers' methodologies, such as rotating their DNS names, would suffice to get around blacklists.
What we really need to combat spam is better e-mail management tools. The reason we get unwanted e-mail is because the sender has control, not the individual or company. That needs to change.
Would a large company allow a random outside person walk into their building, go to anybody's cube, and start talking? Never, but that's what happens electronically today with e-mail.
Instead of today's simplistic systems, imagine a multi-tier system of contacts -- a top level of corporate maintained partners and customers, a mid level of department specific contacts, and a bottom tier of personal contacts and exceptions.
This contact list would be paired with a routing system based on well-defined business rules. As companies regain control, the From will become far more important than the To.
But sophisticated management depends on clean data, and clean data is exactly what today's e-mail isn't.
The more checks we can add into the process to validate the headers, the better the tools can become, and the sooner unwanted e-mail will become a thing of the past.
Is this going to cause me problems?
What about those who have a domain that does e-mail forwarding to their ISP account, and have it put their forwading email address in the from field?
WHy do you need a new ISP? just get an email from Spymac.com, or gmail if you have friends. Theres someting out the that allows you to access gmail via POP and spymac give you POP access out of the box.
The only downside I can see is that you'll loose your email and need to inform every one of the change, but then you were planning on doing that anyway. If you're happy with MSN dial-in but not the email just use one of the ones above.
Alternatively you could NOT use outlook (any version) and use Thunderbird link instead.
Just some idea you can try, and maybe avoid the hassle of changing ISP's.
face the world with eyes of fire.
At least in sendmail and similar MTA you can setup so all emails are reverse verified.
Why do we need to reinvent the wheel on this one?
*And* requiring a totally useless XML format, so that every SPF-capable MTA has to incorporate an XML parser.
(sigh) Not informative
Last I looked at the mailing lists, XML is out with regards to MARID. Go read the archives of the IETF's MXCOMP mailing list.
How can you get your local or global dsl providers to let you setup their DNS reverse look ups to even allow this..
There are going to be a lot of pissed off verizon and SBC customers I know of that wont be able to talk to AOL, HOTMAIL, MSN, etc..
And talking with the DSL providers they aren't willing to budge to allow you to manage the reverse lookup.
$ dig @ns3.zoneedit.com mydomain.net TXT
[...]
;; ANSWER SECTION:
mydomain.net. 300 IN TXT "v=spf1 a -all"
If shell access is part of your hosting agreement, and you can get from the web server to the mail server (or if they're the same box obviously), just create an SSH tunnel to the web server and forward a port on your local machine to the mail server's SMTP port. Then tell your mail client to use localhost:"the port you forwarded" as the SMTP server.
/. article about free shell providers recently. Either way.
In Windows this can be easily done with PuTTY. In Linux or OS X the command line SSH clients are perfectly fine as well.
Of course you don't necessarily have to use your web server and mail server. This works as long as you've got a shell on one box, that box can reach the SMTP port on a mail server of your choice, and the shell box is authorized to relay through the mail server (or you use SMTP AUTH).
This isn't a solution for the masses (until someone comes up with a ridiculously easy tunnel application; I don't think PuTTY would cut it for mom and dad. Is there one already?), but if you didn't already know about it, it might be a solution in your specific case.
If you don't have a shell at all there's all kinds of places that sell them for ridiculously cheap. Not to mention there was a
Game... blouses.
is this the same Bill Gates that said Open Source kills jobs? Why is Microsoft adopting an Open Source technology then? ;)
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
There's several ways DDNS services could implement this which make sense..
Assume they wanted their hosts to be able to send mail only from their own machines.. So the IP that is currently bob.example.com can send email from bob.example.com. They could add a TXT record to every DNS response like so: "v=spf1 a mx -all". This states that the receiver should lookup the A address of the domain it's looking up and see if it matches the IP of the sending box. It'll also lookup the MX record and allow that one as well.
Or the DynDNS provider might want to let you specify who your ISP is, and then let you send email from your ISP. In which case they could use: "v=spf1 include:your_isp.com -all", which would tell the receiver to lookup the SPF record for your ISP and use that as the valid senders.
Or they could simply add this and allow anybody to send email from that domain: "v=spf1 all".
In short, there's more to it than simply specifying addresses or ranges of addresses. It can be more complex and designed to handle most situations with minimal effort.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Sure, anything has side effects. But SPF just happens to be the most popular *and* most broken spam countermeasure, at the same time. Side-effect free sender verification: sign all outgoing mails with private key, publish sender public keys in DNS.
I have SPF on my domain, I've had it on my domain for nearly a year. When I set it up, Microsoft had nothing to do with SPF. In fact, at the time, they were touting their "Caller-ID" standard.
It would be super easy for spam software to add a bogus header in the smtp envelope that shows that the mail did originate from a server in the SPF record.
Given the marked rise in spam after the marked rise in viruses, it is safe to assume that the design of spam is now to send it through infected home computers. They have plenty of time before October to update their malware so that this SPF entry is not an issue for them.
However, I and every other DNS admin out there now will have to add this record to each domain that originates email under their control in order to ensure that our users mail gets through. That's a lot of work for a lot of people... not to mention the tech support calls by users whose domain admins were not aware they needed to publish this.
Bad solution.
I don't want anyone to know my "real" ISP address. It's fine that if they look at the "Receoved:" headers they can see it came from my ISP's SMTP server. I don't want my ISP address to get in people's mailing lists, or harvested, either by spammers or by mailing worms.
I thought they were suppose to come with their own new innovative protection that would of course only run on windows.
What, Armageddon?
- The Amazina Llama
Not if you control the DNS for example.com.
You need to add a TXT record to your example.com domain's DNS. It should look like this (or similar in some fashion):
"v=spf1 include:earthlink.com a:your smtpserver.earthlink.com -all"
See, when a SPF-enabled receiver reads the DNS record, it's reading the DNS record for example.com. Since you control that, you can allow anything to send mail in the name of example.com that you want. The "include:" bit just tells it to use earthlink's SPF records (if they exist), and the "a:" bit tells it that anything from smtpserver.earthlink.com is allowed as well. The "-all" at the end disallows the rest of the world to send mail in the name of example.com.
Simple. Take a read about it here: http://spf.pobox.com.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Is there any mechanism in SPF (or Sender ID) for this email setup?
No, because you are basically forging email. Not that there's anything wrong with that, but it is what you are doing. You don't own alumni.xxx.edu, and they may not want you to send email (that purports to be from their systems) through Yahoo.
However, if you get the permission from the owners of alumni.xxx.edu, they might be okay with it and they might add yahoo to their SPF records.
But what you are doing is essentially the wrong way to do it, and that's what the Reply-to: header is for in the first place. You send email from yahoo as per usual, with a Reply-To: header saying where replies should be sent to. All email software supports this transparently, basically.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I wish I could mod you up (I have mod status today...) but I chose to ask questions. thanks for taking the time to answer them.
I like microcars
That none of the libspf2 pages don't pass the XHTML verification when you click on the link to perform that operation?
Setting Sender: is one way around mobile/roaming problems, but not the only way.
Probably the best fix is to use SMTP AUTH to connect back to your home server, and it can send the mail out from there in the normal way.
If you can forge the domain name on an e-mail then anyone can forge the domain name on an e-mail.
It's really that simple. If you agree that domain forging should not be allowed, then you should publish SPF records, fix your mail system to be compatible, and start checking SPF on the inbound side.
If you believe that domain forging should be allowed... well, good luck to ya. We'll see how many domain admins agree with you in five years.
(Nobody is forcing anyone... other then big ISPs saying that enough is enough and requiring it. Which is basically the free-market at work.)
I think what we're going to see is being able to use your domain name on the From: line as another differentiator between webhost pricing tiers. You want to receive mail @domain? That's $X/month? YOu want to also send mail from @domain? That's $X+2/month.
There's enough competition in the hosting market that $X+2/month won't fly (at least not for long). Outbound authenticated SMTP is simply going to become a required part of standard hosting service (if you provide inbound POP3 you need to also provide outbound SMTP for your customers).
A lot of the better hosting companies already support outbound encrypted/authenticated SMTP.
Wolde you bothe eate your cake, and have your cake?
From addres. The originating address on the socket. Thats it.
SPF is a case of "solving the wrong problem". The patient has a broken arm, but the quack doctor does not know how to set bones so he gives the patient an aspirin. But the patient's problem is not basically that he is in pain, but that his arm is broken -- the quack is solving the wrong problem.
It's not a case of "solving the wrong problem". It is a case of people not paying attention to the fact that (even as you said), it's all about forgery and not spam.
Forgery is a problem. It needs to be addressed. SPF provides an easy way to do so without requiring a central registry/authority and by allowing every domain admin to either opt-in or to choose to not to opt-in. If you don't like your domain being forged, then publish SPF records for your domain. If you don't care that anyone can forge your domain onto their trash, then don't publish.
It works on a distributed model, just like most of the other good things about the internet.
Once a few sites start rejecting me for not using it, I guess I'll have to add the records.
um, no... You don't get rejected for "not using it" - what happens is that, if you try sending a message directly from your windoze peecee with e.g. a forged "hotmail.com" sender address to a mail server that checks spf records, they will know your from address is forged.
For email messages purporting to be from a domain without spf records, spf doesn't enter into it, mail is simply processed as in the pre-spf era.
Just kidding, it's just an idea... whoever's got that "Your solution to spam will not work because ..." form, get it ready. :-)
Why not sign outgoing messages with the server's private key, put the signature in the headers, then make the public key available (say, via dns)? Wouldn't this kill spoofing?
Just a thought.
Assume I was drunk when I posted this.
Except for the fact that "forwarded" email will have to be placed in a new envelope in the SPF world, so bounces will only go back to the last SMTP server that it touched. If you "forward" your mail, you'll never get a legimitate bounce back, with out a major overhaul of mail servers (eg, the MTA will have to open up each mail message). SPF is broken, and doesn't really solve the SPAM problem at all. It only allows big organization (like Microsoft) to blacklist the little guys because they might send spam... Meanwhile, the spammers will just buy $8 throw-away "legitimiate" domains.
The wheel is turning, but the hamster is dead.
Probably the best fix is to use SMTP AUTH to connect back to your home server
Some ISPs block even authorized SMTP over the MSA port (587).
Signed on the way out by the mail server?
Sorry, mail tech isn't my thing, so this is a genuine question:*If* the answer is yes to the first two questions, how does this have less side effects than CallerID/(SPF)?
It's freaking amazing that a LARGE company like Microsoft takes THIS long.
My guess is that they looked at it and realized that by the time they came up with something "better", everyone else would have adopted SPF.
IANAL, but I've seen actors play them on TV
That is, until ISPs start to block outgoing TCP ports 25 (SMTP between MTAs, which workstation users shouldn't be using anyway) and 587 (authorized SMTP for MSAs).
Translation: "From:" addresses emerging from your domains don't mean a thing. Your users can set them to whatever they want.
Outfits like yours are a part of the problem. This solution is intended to prevent you from doing what you are currently doing.
Do you know of any specific ones that do? Let me know if so...
I have heard it talked about in the abstract sense, like "Some ISPs block 25, what if they decide to start blocking 587?" I don't think there is any incentive for them to block 587, since it is supposed to be used only for Auth on the other end...
Thanks
gregc
You should only get filtered if the domains you send from HAVE an SPF record and you send from servers not on the approved list for those domains. (And only then if the reciever checks the records and rejects on the basis rather than just filter.)
----- Question authority, but not ours. Hate the man, but we're not him.
I just set up SPF on rougly 10 low volume domains that I and a few friends run on a server hosted where I work. Nice to hear something like this since it helps validate our moving to it!
Just what we need, a totally imcompatible and bug filled protocol that no one wants to adopt due to the inertia of the existing technology. Frankly it would be easier to break little thinks in SMTP than to adopt this new and exciting protocol.
----- Question authority, but not ours. Hate the man, but we're not him.
SMTP using auth over TLS for submissions would be just fine. Most ISPs aren't blocking port 587, just 25.
----- Question authority, but not ours. Hate the man, but we're not him.
I quote from the "sender-id" page linked to from the SPF site:
If you are a software developer and are interested in implementing this specification in software, please review the terms of the Caller ID for E-Mail Implementation License before you begin, as the patent license discusses the rights that Microsoft would grant you or your organization. Please note that a license agreement is not required for individuals, companies, or ISPs who only wish to publish their Sender ID records.
I think SPF is the shiznit, So does MS, thats why they're tying themselves to the protocol. I just hope this is not going to be another Samba fiascoMost of the big cable providers do, in order to prevent spam zombie's from sending spam from their IP net (basically forcing you to use their SMTP server unless you use port 587 (reserverd for SMTP over TLS) or some other nonstandard port.
----- Question authority, but not ours. Hate the man, but we're not him.
try here.
Thank you for contacting Register.com regarding your domain name "matthewmiller.net".
We do understand that you wish to set up SPF records in DNS to your domain name. Please be informed that Register.com system does not support SPF records.
Our technical department is always working on introducing the latest development IT field. Introducing SPF records in DNS is under way; this feature will be introduced in near future however we cannot give you an ETA at this time in this regard. We suggest you to visit our website on regular basics for any future updates.
If you have any further questions or encounter any difficulties with your domain name in the future, please respond to this incident by replying, or using the link included at the beginning if this email. You can also contact a Customer Support representative 24 hours a day, 7 days a week, at the numbers below.
Thank you for choosing Register.com, the First Step on the Web(TM).
Customer Support
Register.com, Inc
Toll free in the U.S. and Canada: (800) 899-9724
Outside the U.S. and Canada: +1 (902) 749-2701
P.S.
Register.com's free monthly email newsletter offers tips, success stories and information to help you improve your online presence and grow your business.
To see past issues and subscribe, just click the link below:
http://www.register.com/newsletters
Guess I'll be switching registrars. Any recommendations?
"Live Free or Die." Don't like it? Then keep out of the USA
I was thinking of webhosts that include mail forwarding but not POP3 or IMAP.
Register.com does NOT support SPF
Thank you for contacting Register.com regarding your domain.
We do understand that you wish to set up SPF records in DNS to your domain name. Please be informed that Register.com system does not support SPF records.
Our technical department is always working on introducing the latest development IT field. Introducing SPF records in DNS is under way; this feature will be introduced in near future however we cannot give you an ETA at this time in this regard. We suggest you to visit our website on regular basics for any future updates.
If you have any further questions or encounter any difficulties with your domain name in the future, please respond to this incident by replying, or using the link included at the beginning if this email. You can also contact a Customer Support representative 24 hours a day, 7 days a week, at the numbers below.
Thank you for choosing Register.com, the First Step on the Web(TM).
Customer Support
Register.com, Inc
Toll free in the U.S. and Canada: (800) 899-9724
Outside the U.S. and Canada: +1 (902) 749-2701
P.S.
Register.com's free monthly email newsletter offers tips, success stories and information to help you improve your online presence and grow your business.
To see past issues and subscribe, just click the link below:
http://www.register.com/newsletters
"Live Free or Die." Don't like it? Then keep out of the USA
I don't see how this will make some people more vunerable. Sure their share of the joe-job burden will go up, but only because THEY WON'T BE ABLE TO FORGE AS MANY DOMAINS. It's not like it makes the other users more vunerable than before, it just puts them in a shrinking pool of exploitable domains.
----- Question authority, but not ours. Hate the man, but we're not him.
But we already have tools to fight open relays. And SPF isn't that much of a burden. What it will force us to do is use SMTP auth, webmail, or VPNs to relay email instead of using the SMTP host of the ISP you are connected to when you travel.
----- Question authority, but not ours. Hate the man, but we're not him.
That is, SPF is not the Final Ultimate Solution to the Spam Problem, but it makes some other spam-fighting techniques possible.
No, it really doesn't; at least not well.
People have been arguing "SPF isn't an anti-spam system", "SPF is an anti-joe-job system", etc.
SPF does not do any of the above.
SPF is a rudimentary, rather poor (easily breakable, inflexible, requires cooperation on a massive scale, lacks end-to-end capabilities, delegation of authority and user-level granularity) authentication system.
While SPF *alone* does not impose any side effects (it just adds a mail header or two) other than a bit of a bandwidth increase, systems based upon SPF generally make assumptions of SPF that do not hold (it can't be spoofed, or the source domain of an email is an effective identifier to an end user, and so forth). SPF is largely broken as a useful system. There are much better authentication systems out there, like PGP/GPG. The only reason SPF has been deployed is because admins are desperate for *anything* to reduce spam, and deploying SPF lets them feel like they're doing something, in the absence of good antispam tools.
May we never see th
No, 1 PGP key per user. There are already systems for publishing public keys in DNS. The additional load on the DNS system would be trivial.
to harp about "supporting" something as genuinely good and simple as spf, but to not use it to benefit others. They have not yet publushed spf records for msn.com, hotmail.com or microsoft.com. You would think they could generate a list of mail servers without too much trouble. A short list of comparable companies that have published spf records is: google.com, gmail.com, earthlink.com, aol.com, aol.net, apple.com. A more exhaustive list is here: http://spftools.infinitepenguins.net/earlyadopters .php
-earl
I hope they don't also think SPF will help protect them from the sun
If you don't understand anything I post, please accept that I ate paste as a small boy...
There is a forgery problem. You're right about PGP, but there's no way to say to the world at large "accept no email from me unless it is PGP-signed". Thus, people and automated systems accept email that they should not. This causes (at least) two big forgery problems:
And lastly, this is related to spam. If we (through a combination of technical and legal means) made it difficult to send email under a false name, I believe spam would a much smaller problem. I would then not even want any laws against spam; just social means. If we could link every email with a real person or company name, we could simply refuse to accept messages from people who spam. But we can't do that now. Both because of forged senders and because of the bogus domain contact info you mentioned.
I use YahooPops to retrieve my email from Yahoo and use my local ISP to send replies.
I guess I'm screwed.
?all is valid in SPF. It basically means that the record can be used for whitelisting, but should never result in a rejection. Of course we want to encourage people to get to -all as soon as possible, but they may not know all the different places that their users send from. The records shown above at least give a Pass result when using the known mailers.
The script that reports this as an error should probably be investigated. Do you have more info on how/why ?all is considered to be an error? (DUNNO is probably not an error in this case... it just means that the result is not black or white, and other filtering or policies should still apply)
Got any references to proposals for a user level key version?
Except for the little fact that hell, you can come up with any scenario if you want. Nothing is perfect. ...And if the power dies, then you suddenly can't send email anymore...
Give me a break. First off, if you really have the need to send email from anywhere in the whole goddamn world, then you can still do so. "v=spl1 all". Yes, it lets anybody spoof you, but HTF is that any different from right now?
There is no perfect solution. This solution is good for 99% of the time, unless you contrive some crazy ass scenario that most people don't actually do and won't actually have a problem with. If you have special needs, then you can be accomodated at a cost.
And if it's that goddamn important for you to send email, you need to have your own secure server running on some obscure port somewhere where you can authenticate to it from where the hell you happen to be. You don't need to be using random ISP's SMTP servers and expecting all your mail to make it there unaffected.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
SPF is a case of "solving the wrong problem"
I think you are looking at this the wrong way. I think of SPF as an enable-ing technology. You are right: by itself, SPF does not do alot of good, but makes other techniques much more useful.
Say you get a spam email. Look up the SPF from the source domain. Does it match the source IP? Yes: block the domain. No: block the IP. Done, Done, and Done.
You can't do this without SPF. It has to reach a critical mass first, but this announcement means the ball is rolling over the top of the hill.
(Not perfect, but think for a few minutes and you will know how to improve it. I did.)
If you open your mind too wide, people will throw trash in it.
Well, it's possible to change the "From:" header in the address body without changing the Envelope MAIL FROM: command. SPF is checking the MAIL FROM: portion, not the message's From: header.
That is, Yahoo could conceivably connect to a server to send your email, use your yahoo.com email address as the MAIL FROM: line, and then a different address in the actual body of the message, and it'd make it through SPF, no trouble.
Virtually every SMTP receiver I have seen will show this happened to the sender by including a "Real-From:" header or something like that. But the email client almost always displays the given "From:" header instead. So it'll still be possible, usually, to spoof your From: header, you just won't be able to spoof the Envelope's from header. This really depends on how Yahoo does the spoof, actually. It might make it through SPF, but then it might not, depends on how they do it.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
So here's my situation: I send mail from my home network from either my personal domain (which is hosted elsewhere - I pick mail up by POP3), or from my employer (ditto).
In the glorious days when SPF arrives, I will ideally want to configure things so my MTA (Postfix) sends mail with an SMTP envelope sender of my personal domain to my personal domain hoster, and from my work account to my employer. However AFAICT postfix doesn't do sender-based routing, only recipient based routing. I've got a dynamic IP address, so I can't get marked as a valid SPF sender for either account.
Surely it won't be the only MTA that can't do this, and this type of situation - needing to forward to different relays because of different accounts - won't be uncommon.
Any ideas how to do this? Worst case I can set up the account details in each MUA, but that's a pain, and defeats the purpose of a central mail hub.
So my domain is registered through joker.com, the number 13 domain registrar according to State of the Domain. Joker.com's DNS service doesn't provide the ability to create a TXT record. The other name registrar that provides DNS that I've looked into, 1&1, also does not allow TXT records. So do I actually have to find some new DNS provider or run my own DNS server in order to have a TXT record and thereby allow my users to communicate via email to hotmail?!
Tell me it 'aint so!
I did the 'dig -t txt gmail.com' and it works like you state. However, when i did a 'dig -t txt hotmail.com' I got nothing like it back.
...
Does this mean that Microsoft's solution for SPAM is only to make their life easier, and not the rest of the internet community ?
Also, 'aol.com' works, 'yahoo.com' does not,
I am one of the many people who uses a DNS hosting service (active-domain.com). There are many other people who this and other services.
I have asked about SPF support, but active-domain are not overly interested in providing this. I gather from reading similar posts that other similar service providers likewise are not interested offering this service.
There is a real possibility that in future some organisations will start to look to SPF as a means for blocking spammers (as a commercial administrator I would like to be able to do som myself).
It is therefore likely that users of these 'limited' DNS hosting services will need to look elsewhere for their services.
1) Can anyone provide any details on commercial DNS hosting services that will allow people to publish TXT (SPF) records ?
2) If you are in a similar situation as myself, rather than sit back and moan, email your DNS providers technical support and ask when they will be providing support.
Slashdot seems to be good at killing people's web servers - let's see if it can assist with lightening the SPAM load on peoples email servers to make up.
Thanks,
no problem...
yourdomain.com. IN TXT "v=spf1 +all"
Well, my mail provider deployed SPF quietly and the result was a few months of occasionall dropped mails: mail forwarding from one low-volume but important domain didn't work. When I looked into how that could happen, it seemed like SPF was working the way it was supposed to, it was just that unless the whole world switched to it, this sort of thing was bound to happen.
Since my spam filters are working pretty well, I concluded it was better to live without SPF and let the spam filters deal with the extra junk than to lose mail because of SPF's limitations.
So when can we expect Exchange to begin supporting SPF?
In each case, SPF doesn't actually prevent the malicious user or clueless operator from causing you the damage he can cause you now. Why then should you bother to support it?
Being seen as doing something is good enough reason for Microsoft. They'll take any chance they get to be represented in the media as part of the solution when everyone in the trenches knows they are the root of the problem -- nets of worms, preferred system of trojans, spawner of zombies.
But the workaday operator, you and me -- that lie just sits wrong with us. We give a damn about the system we work all day to maintain. We give a damn about our fellows at other sites who have to deal with the same freakin' virus and spam bullshite we do. We shouldn't give our nod to flashy systems that our own experience and knowledge prove have no chance of working to solve the real problem.
Forgery is a failing of the current mail system, yes. But it is not responsible for spam, and spam crime can operate gleefully without the kind of "forgery" that SPF attacks. I know that users aren't always 100% happy with tough-on-spam answers like greylisting and blocklists, but those are the ones that work. Why waste time on junk like SPF that gets headlines but doesn't actually inconvenience the spammers at all?
Use port 587. It is the standard smtp submitter port. All mail clients don't use this port by default, but I expect them to use 587 shortly in the future.
shouldn't that be 0.0.0.0/0 ?
I've been using SPF tags on my domains for months now. The only spam I see is forged to look like it came from one of my domains, as I've whitelisted them. I haven't taken the time to enable postfix to drop SPF failed messages. As soon as I do get that configuration change done, I will receive zero spam, and that's the way it should be. SPF is just one additional tool that fills an existing gap. Use it if it will benefit you. Otherwise, don't complain as it's not in anyway being forced on you.
"Why do you consent to live in ignorance and fear?" - Bad Religion
Every high speed ISP I've ever used (dsl, cable, wireless) has blocked by default outgoing port 25 on their DHCP/normal addresses. my DSL and wireless providers have made exceptions for static IPs that I pay extra for, which are reserved in their network, and set aside for people to run servers on, and therefore aren't as restricted. But, good luck getting comcast to do same..
Case in real life: email bouncing back
Reason: receiving end had its SPF checking misconfigured and was not accepting email from my domain because my SPF record did not match the receiver's upstream SMTP server. The mail was checked against SPF again after it was accepted from my domain. Unable to fix the real problem.
Resolution: remove SPF record and wait for 86400 seconds for DNS caches around the world to dry out
SPF is a solution for the perfect world. I'll publish SPF records again, when major ISPs require them before accepting email. Early adopters will always be bitten.