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."
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
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.
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
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
PGP/GPG are nice, but they have nothing to do with the anti-spamming technology present in SPF. All SPF is, is special data set in your DNS telling you which hosts are allowed to send mail on behalf of your server. That way when your 0wn3d computer sends mail from "hotgirl@hotmail.com", people can tell it's a fake.
The World Wide Web is dying. Soon, we shall have only the Internet.
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.
Additional benefit of using GPG/Pubkey Cryptography:
Bulkmailers will have to encrypt every mail with the public key of the recipient. Considering that the average number of mails in a batch is usually >> 50,000, the amount of time needed is non-trivial.
Apart from that, the bulkmailer will also have to retrieve and store the public key of each single recipient.
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.
XML was dropped from the Sender ID spec by the IETF last month.
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.
SPF support for most open source mail servers can be found at libspf2.
Um. . .isn't that the point of open source?
I think I'll stop here.
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.
It's a new open standard that forms part of the way you send mail from now on. It is a very worthwhile method of cutting down on SPAM that spoofs it's origin. If you (or more likely your ISP) don't want to conform to the standard, no one is stopping you from sending eMail. But you just have to accept that there is a much higher chance of it being filtered by a spam filter, no matter who you send it to.
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?
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.
;)
:p
Yes they do.
You're thinking of HTML, not HTTP which are two different things.
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.}
The person that wrote "RTFA" is trying to help you in a more profound way. They are trying to teach to learn to read before asking, something that will make you look like less of an idiot (which you presently look like).
Give the man a fish, and you feed him for a day. Teach the man to fish, and you feed him for a lifetime.
You're confusing HTTP with HTML.
Dissolve... Resolve... Evolve...
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.
They've fiddled with HTTP also. ISTR some tricks IE did with IIS to keep persistent connections so that page loads would be quicker.
I think that using PGP would be a better system, but I don't think it will ever actually happen...too difficult to implement.
Except PGP would mean you have to accept the complete message, then check the signature (and cache a signature for every from address).
SPF does it a lot sooner, from the FROM command, so you're not wasting that much bandwidth. Also there's less caching as it's one record *per domain*
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.
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
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
From the article: Messages that fail the check will not be rejected, but will be further scrutinized and filtered
autopr0n is like, down and stuff.
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?
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.
It is; provided that you share the changes you make.
UNIX/Linux Consulting
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.
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
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.
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
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
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
SPF is all nice and such, but it won't help stop spam at all. All it will do is encourage spammers to use other forged domains that don't have SPF records (which is most of them.)
Adoption of SPF or other technologies (domain keys for example) needs to be near 100% to be useful in reducing spam. Lack of records can be somewhat useful as a scoring tool in spamassassin for example, but that's about it. Spammers will just find another way to spam - maybe they will start publishing SPF records on the 8782374651872356 domains that they have registered or taken over.
Spammers already control a large percentage of windows machines - they really don't care if what they are doing is illegal or not. Grandma's machine will start spewing spam using her real email address via her ISP slowly - a few dozen messages every day. Of course there are millions of other grandmother's machines to use.
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.
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.
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.
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.
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 fiascoSPF is all nice and such, but it won't help stop spam at all.
But thankfully, it prevents skin cancer.
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.