Slashdot Mirror
IETF Decides On SPF / Sender-ID issue
Zocalo writes "The MARID working group at the IETF responsible for deciding on which extensions to SMTP will be used to try and prevent spoofing of the sender has made their decision. At issue was whether Microsoft's patent encumbered Sender-ID would be eligable for inclusion in an Internet standard. An initial analysis of the text of their decision, available here with a brief analysis, would suggest not. Unless Microsoft is going to make any dramatic concessions out of desperation, that pretty much clears the way for Meng Wong's Classic SPF to become the standard and hopefully make Joe-Jobs at thing of the past."
Why is that the spammers actually supporting this ? Does this give them more targeted email addresses ?
I love it when the world has a moment of clarity and decides that Microsoft has enough damn patents and we're not going to let them run everything. Adopt the open standard that everyone can use. It makes more sense.
Question: Is the IETF allowed to adopt patent-encumbered standards? I mean, wouldn't that grant some sort of monopoly license in effect for MS, seeing as if you want to adopt a standard, you need to pay somebody? Shouldn't standards be free, and people can make money off the implementation of said standards? I don't know how these things work, nor am I a lawyer of any capacity.
Microsoft shouldn't be surprised that their patent-encumbered method didn't fly. Remember the whole "burn all GIFs" campaign, when a patent made gif files possibly illegal to use? Now - imagine that mess with your email, and Microsoft holding the reins. Argh.
We've been through the whole embrace-and-extend loop with MS before, and it's nice to see the IETF understand the problems that a patent encumbered standard would produce.
Weaselmancer
rediculous.
This worries me more than it makes me excited. I have several email addresses that I send mail from home through ISP. I don't believe they are going to put those domains in thier DNS list.
In the case I guess the only option will to be use webmail for any addresses not provided by my ISP. That's a pain...
"Luke, I am your node.parent();"
MS will not take this without fighting back. I suspect they will hint that they may have issues with SPF as well, maybe in a years time or so.
Fucking S/W patents. If these had been available 20 years ago the NET would never have been born.
These people are just selfish. They build their bisinesses on the NET backbone, given to them for free and then do everything possible to destroy the vehicle that built it.
Human nature?
SPF Breaks Forwarding.
Yes I know about SRS. (sender rewriting scheme)
SRS is a LAME workaround for the fact that SPF breaks forwarding.
That's not what the MARID chairs decided at all!
They caved and send they'd implement Sender-ID.
1 44 2237&tid=111&tid=109
It makes Apache and FSFlook good as they
proved resistance isn't futile.
http://it.slashdot.org/article.pl?sid=04/02/24/
When Microsoft ships their method on all their mail servers and mail clients, will it matter that it is not a sanctioned standard?
Where law ends, tyranny begins -- William Pitt
Each email should be digitally signed. Signature could be in the header. When mail comes from recognized source it would fall into normal mailbox. All other mail would fall into suspect box. One could once in a while check the suspect box and add new friends public keys to their rings. Also when meeting new friends one could include the public key in the contact info.
combatting spam. It's about being able to verify that the envelope sender is actually authorized to send mail for the domain in the envelope. That is all.
HAND.
I already sent a mail to the company that hosts the DNS A records for my domains (also my DNS registrar) asking when I'll be able to add an SPF record.
My spelling and grammar skills worry me even more...
I even previewed before posting!
"Luke, I am your node.parent();"
Can SPF itself be hijacked ?
.. then when the SPF check happens (u can guess it'll be immediate?) ..you fake a "passed" response from somerealdomain.com's IP (using a spoofed IP) ..before the actual server has had time to respond.
You send to abc@blahblha.com an email from an address "blah@somerealdomain.com
Sort of like man in the middle or TCP/IP data / telnet injection attacks.
Yes you won't see the traffic being sent to the server so it makes it harder cause of timing issues.
The one feature of Sender-ID that I'd like to see in SPF is checking the header-sender as well as the SMTP-sender. Of course this is expensive, requiring reception of the message body, but it's worth it.
It occurred to me recently that I could write a separate milter to implement just this one check. It would compare the SMTP-sender against the header-sender, and if they don't match then it would add a header to the message saying "possibly forged". A later step in the delivery process, such as bogofilter, would see this header and weigh it appropriately.
I'm interested in comments on this idea.
There is absolutely zero value proposition for anyone to let MS own, encumber, or otherwise threaten, by act or by fear of an act, the email standard.
They need to be kept 1000 feet away from any standards setting. Microsoft should only encounter the email standard when they send an email. Anything else is an absurdly bad idea.
If you had to bet, could you honestly bet they wouldn't exploit their license to shut out open source, or (more likely) GPL, now or (more likely) later?
I'd bet your well-cushioned ass they would.
It is hardly a conspiracy theory, when you can open any business section and read about their new patent portfolio manager or the SCO lawsuit. They play dirty, they do it in exactly this way, and everybody knows it.
Letting them taint the standard is bad for other vendors. It's bad for service providers. It's bad for users (read: most of the world's population, individuals and businesses). It's even bad for Microsoft itself.
It is absolutely absurd to have a standards war over email. But now we have to consider it.
Standards bodies may do the right thing. That's great. But what I fear now is that Microsoft will say "OK, you don't want to play our game? That's fine. Have it your way. Just don't bother sending any emails to @microsoft.com or @hotmail.com (and everywhere else we can buy or control) without a patented Caller/Sender ID record."
When they do this, we have to stand in a big line facing them, stare back, grin, and say "your loss."
Get ready...
Want to Know How to Cheat the GPL? Read On!
Patents are always a monopoly.
That said, the answer seems to be no. The IETF can adopt a patent-encumbered method as a standard.
As you can see here, there appear to be quite a number of patents which may or may not relate to IETF standards. And you can see that in these cases, it appears that the IETF demands that the patent is licensed on "fair, reasonable and non-discriminatory terms".. whatever that means.
Why don't they have a system that when an email is sent, the sending server makes a note. Then the receiving server receives the email and replies to the address asking 'did you send this?'. Then the sending server replies to that and says "yes", and the email is now authenticated.
Okay there would be an increase in mail traffic, but the eventual benefits, should outweigh that (though I'm very open to the fact that there is probably some fundamental flaw in my idea).
I'm now seeing 30-40 bounceback emails a day originally sent from people spoofing my vanity domain - I haven't given any accounts out, of course. Makes me wonder how many of their emails got through to their victims, as these are just some of the failures. The most annoying part for me is that I see them come in batches - with very different originating IPs and to different mail servers for each message - so I don't know if it's a pack of zombies and my domain is one of the ones in rotation, picked out of someone's address book, or if someone is doing a deliberate joe-job on me.
This ought to be considered actionable as a DOS attack - if companies start filtering out my domain name, I can't apply for jobs with them, for example. And if my upstream ever gets tired of explaining to idiots to read their headers instead of thinking it's me, then I'll have to hunt for another provider. Even without those reasons, it still takes me time every day to clean out my admin box so I can get my real mail. In fact, because I'm the only person at my vanity domain, and it's part of my online identity, it also ought to be considered slander for someone to pretend to be from my domain, because they're effectively claiming I'm sending these ads, etc.
I hope SPF becomes generally accepted, and soon. I'm afraid it won't, though, because there are millions of people running old copies of MS Exchange, etc., and they probably won't want to pay to upgrade or take the performance hit to authenticate messages this way. Still, if I go ahead and stick the DNS entries in, it might at least prevent some of the damage.
Get off my launchpad!
One "little" problem. 95% of the worlds desktops run some kind of Windows. Microsoft will not follow this open standard, and since they control the desktop, they control your email.
Unfortunately, that's what's covered by Microsoft's patent.
Really.
Microsoft want to patent going through a header to see who the message claims to have been sent by - the "Purported Responsible Address" - aka the PRA.
Take a look at the algorithm they are trying to patent and ask yourself how many times you've done this yourself when trying to figure out where mail came from.
It's like trying to patent an algorithm to find the author of a book: 1) look for a name on the cover 2) look for a name on the spine 3) look for a name in the copyright declaration 4) if you've found it, there you go! 5) if you haven't, too bad.
How can they expect to be taken seriously?
And in follow up to the parent's post, I want to ask:
So... what, if they did publish the patent, they could decide to include it in a standard? Seeing the patent doesn't prevent the patent owner from taking advantage of it, does it? (In fact, seeing the patent makes it easier to be sued for infringement.) Or am I missing something here?
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
3. On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type.
Look closely. The wording to pay close attention to is "This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application.".
In other words, we don't know what the patent is, so we shouldn't waste time doing any work an anything that might infringe it. That's significantly different to saying that the original patent-encumbered work won't be accepted, in fact the wording has been very carefuly picked to remain non-committal on that point.
Next, look at an extract from point 4 of the summary: ...With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.
4.
In other words, not only the should the committee not waste its time until all the patent claims are made public, but neither should anybody else try submitting new things until the committee knows what's happening with the current proposals.
I read the summary as a glorified "we can't know what to do as not all claims have been made public, so we'll just put everything off until the claims are fully known". Neither backing for, nor rejection of Sender-ID. And certainly nothing whatsoever about falling back purely onto SPF.
Cheers,
Ian
But sendmail has both free and paid versions. How many sendmail installations use the paid version, and how many use the free? Has sendmail released a free version with the Microsoft art? Can they, legally?
Just looked, and free sendmail was released under BSD, so it looks like they really have caved.
Anyone familiar with licensing of qmail, Postfix, and Exim?
The living have better things to do than to continue hating the dead.
Don't some MTA's like Exim already have an option for enforcing this?
Forwarding exploits a hole in SMTP.
Yes I know a lot of people use forwarding (resending a mail with the same from address as it had originally)
Forwarding is a LAME workaround for the fact that SMTP has no proper email redirection built-in.
Microsoft's patent covers checking the header-senders in a particular order. If you've been following the patent discussion you should know that there are plenty of other programs that check in other orders. If you're worried about the patent (I'm not), then just don't use Microsoft's particular order.
We had an old Exchange 5.5 server running on under-powered hardware. We installed XWall on another machine and relayed incoming messages through it. This took the filtering and virus scanning load off the Exchange server and made it usable again. I don't know if XWall currently supports SPF (I'm also too lazy to look), but it can certainly bring additional filtering functionality to an old Exchange installation. It's pretty cheap too.
Yakov Shafranovich, the former co-chair of the Anti Spam Research Group (ASRG), has written an excellent dissection of the history of Sender ID, published on the CircleID website. Part 1 Part 2
Opera Watch - An Opera browser blog.
#1. No, it would not look up your ISP's SPF record. It would look up the SPF record of the domain you claimed to be sending from. If that SPF record included the mail servers from your ISP, it would be fine.
#2. What happens when the SPF record does not exist or does not match is entirely up to the implementation.
Example: SpamAssassin
I can set the rule to add 20 (or any other number) if the SPF doesn't match.
I can set the rule to add 1 (or any other number) if there is not SPF.
It all depends upon which system you use to check the SPF and what the capabilities of that system are.
If your mail doesn't pass on SMTP FROM it's going to be rejected by our MX's before data, there's little point in checking forgable data anyway. Spammers supported PRA because they could then claim successful delivery, everybody else gets to fix their mail systems.
Perhaps people are finally ON to Microsoft. I'm glad Apache and the FSF stood up to them. Everyone that deals with them pays in the end. They should be avoided at all costs.
Just ask Dan Rather.
That's great to hear that you did even that much. I have no doubts that companies could implement SPF even with MS Exchange, but it will take work. And if you think back to how long it took your company to decide to set up that XWall, it will probably seem obvious that many companies, especially small ones, won't bother.
I'm really worried that MS will just include Sender-ID as part of their next server releases, or worse yet offer service packs for prior versions, and when/if companies upgrade or patch, they'll think Sender-ID is what they want because they got it "free." Since you said you're too lazy to see if XWall supports SPF, if a service pack for your exchange version came out, and enabled Sender-ID, would you just run with it? That's what I'm talking about.
These arguments others have about most email servers not being MS-related are feeble, in my opinion, because they do seem to be the largest player in the corporate email market, and that's where the important email goes. Spoofers (at least the ones I've been seeing bounced mails from) connect directly to destination mail servers, they don't use their ISPs as MTAs. So what ISPs might run is not relevant to them.
Get off my launchpad!
Yes, it's an issue. When I first set up my mail server about six years ago, the default configuration was to bounce unknown local addresses back to the sender. As I was only getting a few pieces of unwanted email a week that wasn't a big deal.
... but unfortunately about ten thousand spams a week were being bounced back to their senders by the server and my ISP figured that I was spamming!. Oops.
Then three weeks ago my ISP shuts off my SMTP access, no warning, no explanation. Now, as it happens my server runs all incoming mail through three or four RBLs, also uses SpamAssassin, has a Bayesian filter system and I use Thunderbird. So after all that filtering I really didn't see much spam in my Inbox
The higher the technology, the sharper that two-edged sword.
Has anyone here setup SPF/SRS with
qmail/Specifically Matt Simmerson's Mail Toaster?
I'm curious if anyone has taken the time to do this, and also if there is demand out there to have Matt make the toaster SPF/SRS compatible.
I think this seems like a good step in the right direction -- doesn't solve all our mail problems, but atleast slows down a lot of the worm-spam phenomenon; I just don't have the time to piece this all together, so I'm hoping to see it in Mail Toaster sometime soon!
May this post be indexed by spiders, and archived for all to see as my Internet epitaph.
Still making it yet another incredibly stupid patent?
In all seriousness, am I violating their patent if I manually scan the header in their special order?
Finkployd
Doesn't matter what you're running (i.e. old versions of Exchange). For the old-Exchange-org, for their outgoing mail all they have to do is put the TXT records in their DNS. Doesn't matter what their mailer is. For incoming (to use SPF to check incoming mail) all they have to do is have a front-end mail relay in front of their exchange server which deals with the filtering before passing mail onto Exchange -- which they should do anyway, only a nutter exposes an old version of Exchange directly on the internet.
Oolite: Elite-like game. For Mac, Linux and Windows
You are correct, and that's why the SPF/SenderID solutions are off target. SenderID is a bandaid designed to block zombie Windows machines while allowing 'legitimate email advertisers' (*choke*) to continue to spam. Since these solutions are designed for a specific problem, they don't get at the real source of spam.
The whole problem is that there is currently no way for a mail server to determine with certainty that the sending host is who it says it is. SPF/SenderID just tell the server that the sending host is the right one to be sending from the domain it's claiming. As far as I can see, that doesn't fight the real problem, which is forged headers.
The real answer is to fix SMTP so that forged headers don't work. That's all. Don't try to do too much or focus on a specific area of spam.
Once we know which machines are sending spam, we can take countermeasures. The countermeasures (blacklists, complaints to abuse@their.isp, quarantine, etc.) all fall into place once we know with certainty who is spamming.
sigs, as if you care.
Forwarding is wrong. Always has been. Re-mailing is what should be done in the majority of cases. Mailing lists won't have any problem because the mailing list itself can be the return address, thus not invoking an SPF lookup on the poster herself. Private forwarding is the big issue (e.g. like bigfoot.com) and in these cases SRS and backtracking can be used.
Now do you a constructive suggestion of an alternative to SPF that both supports the kind of forwarding you want to do, and still informs those who participate that no mail server but mine (or which I say) are valid for sending mail addressed as from my domains?
now we need to go OSS in diesel cars
That's probably because you shouldn't be bouncing mail like that. If the local address is unknown or the message triggers a spam filter, the mailserver should respond with a 500-series SMTP error (probably 550). Note: this only works on machines receiving SMTP connections directly from the world. If you know there's another machine between you and the world (eg. external server receives mail, queues it and then passes it along to a second machine that runs the spam filters and delivers the mail to mailboxes), SMTP errors cause other problems.
AFAIK, if you post to a moderated newsgroup, it's the news server which mails to the moderation address. But I guess it's practically impossible to put all news servers into the SPF records of all mail domains. So will SPF break moderated newsgroups?
The Tao of math: The numbers you can count are not the real numbers.
1) Embrace (Done)
2) Extend (Pending)
3) ??? (Pending)
4) Profit (Pending)
Thanks for helping MS with Step 1. Wait for changes + patent threats in 3-5 years.
One aspect of fighting spam is fighting the costs that spamming imposes. This is one of the reasons I don't generally use content based analysis. But, it would be OK to also do these checks at the RFCx822 level for mail that wasn't rejected before, that would otherwise be accepted anyway.
now we need to go OSS in diesel cars
We were a small company. I think it's easy for a tech savvy small company to implement these things. We've been swallowed up by a large company and I'm no longer involved the network stuff (finally I can concentrate on being a software engineer!). However, I've been banging my head against a wall for months just trying to educate MIS and get them to add SPF to our DNS records. The fact that it's not standard yet is irrelevant in this particular situation.
As for ISPs, I'm happy if the big ones block outgoing port 25 and force their users through a smarthost. I'm with a small ISP, partly chosen because they allow servers. They don't offer tech support etc and cater to the experienced so there is less chance of some ignoramus accidentally becoming a mass mailer.
I noticed that some open source projects have Patent issues and it doesn't seem to hinder them.
MS has said that the patent exists primiarly to protect them from an Eolas, but would it be accpetable To OSS if MS went through a similar route that Theora has gone and granted an irrevociable royalty free licence to any open source implemantation that requests it?
In Soviet Russia, Trojan exploits YOU!
It's not over for Microsoft's efforts...though it's very close to being over. The important section that points this out -- with highlighted text -- is below;
They aren't saying that the Microsoft patent (or any patent) is bad...they are saying that it can't be publically reviewed or is not clear enough to make a decision.
This does give Microsoft some wiggle room if they want to 'clarify' what they mean...and in the course of that, possibly elminate the problems they originally introduced.
Microsoft has a choice to either correct the mistakes (by 'clarifying' them) or what they contributed with patent encumberences will not be accepted.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Oh, you mean like DHCP and BootP?
Yeah, that's been a REAL disaster. Encumbered by patents, not cross platform, very secretive...
Christ- I hate MS as much as the next guy, but chill out.
Please help metamoderate.
It's the incoming to the Exchange servers that was worrying me, and you know many if not most people don't put anything up in front of their Exchange servers, or if they do, it's just a generic firewall. It doesn't matter that it's stupid, it's what they do (or don't do). Remember how long it took for people to get serious about closing their open relays? Good comment anyway, though.
Get off my launchpad!
Yes, that's the idea. You would run sendermilter *after* spfmilter. First spfmilter rejects mail trying to use an smtp-sender that it is not authorized to use. Then on the mail that gets through that check, sendermilter would see if the header-sender inside the message matches the authorized smtp-sender. If it doesn't, the message is still accepted but it gets marked as possibly forged.
No you wouldn't be violating the patent. "mental acts" are specifically excluded from the patent process.
"only a nutter exposes an old version of Exchange directly on the internet."
;-)
True, and only idiots connect Windows boxes to the net without firewalls... so your point is?
Justin.
You're only jealous cos the little penguins are talking to me.
Is this not SPF is doing? It checks the headers to see that the point of origin is the same IP as listed for your domain name as a legitimate sending point. I know of no way to forge headers once mail has left the source server. Each SMTP relay will stamp the mail with it's header. If a SMTP accepts mail from a relay that doesn't match the header it should reject it should it not? I've never received an email that didn't come from the IP number it said it did. I often get mail with the wrong domain name but the IPs always trace back. I can't see how you can forge IP numbers and expect mail to be delivered unless the majority of sendmail servers are poorly configured.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
If all the ISPs have proper SMTP outgoing relay configuration to allow only people in their networks that is known to their customers database to do SMTP send (i.e. you can only send if your MAIL FROM and your smtp authentication login matches). I think it will help to some extend to cut off a lot of spoof emails from their domains. So what's left are those domains that spammers create which can be safely assumed to be spam domain for blacklisting. The key is to stop them before they send or make them liable for what they send instead of reactively response on the receiving side. I think this is probably what http://www.zoemail.net/ do for their smtp outgoing relay configuration for their POP3 customers.
Does this prevent sending email without a domain? such as sending from user@ip.address. Is that even possible now? I would hope that we would retain an ability to send (and have received) email via smtp from an IP address directly.
Either way, the point of anti spam measures should be just to make sure that the sender identifies themselves correctly and not just to create barriers which raise the cost of email and rely upon centralization of trusted resources.
Do we know for certain that Microsoft isn't also claiming rights to PRA? After all, their disclosure of intellectual property interests explicitly cites PRA.
I understand that SenderID and other proposals basically want to make sure that the user is a real user, but:
Doesn't this put a strain on the REAL system?
Let's say that a SPAM system uses my email address to send out 50000+ emails to the world. That means that my system will get hit with 50000+ requests to validate whether the server sending is really in a Mail Group.
So on top of all of the ACTUAL work my system is doing, it now has to support all the SPAM systems that want to use my email address on their system.
This works great for the AOL, Microsoft, etc, but what about the single server mail systems like mine. I support my own email server on my DSL.
What about all the email sent as spam that refers to linux.org or openoffice.org that already handle alot of ACTUAL mail through the domains.
Now it has to put up with all the SPAM messages requests to see if their real as well.
Why not setup the SPAM filters at the Mail Reciept layer, and return a 5nn message saying SPAM is not excepted at this domain.
They get paid per the actual receieved email. If everyone is killing their delivery before it is received then they don't get paid.
Am I missing something here?
Scott Carr
First off, the co-chairs message is so murky and confusing that about a half dozen of us have asked for clarifications about what the heck they are saying.
Far from ruling against MS, it appears to me that the co-chairs have give the green light to advance the patent encumbered PRA algorithm and they are saying that the IETF working group will not consider any replacement for the PRA since it might infringe on MS's patent.
Within a matter of seconds after Chuck first posted this story, I told him I thought he had gotten it totally wrong. Chuck agreed that the jig many not be up, reworded the very end of the story (RTFA) and sent email to the co-chairs. To the best of my knowledge, the co-chairs have not responded to any of us who have asked for clarification.
SPF support for most open source mail servers can be found at libspf2.
You have other choices too:
(1) Encourage your hosting company to offer smtps, or switch hosting companies (they're pretty cheap these days). As SPF becomes more popular, I think hosting companies will be more aggressive about enabling secure smtp.
(2) Don't bother publishing SPF records. You won't get the protection that SPF affords, but everything will still work.
(3) Hire an SMTPS provider separate from your current hosting company.
SPF classic checks SMTP MAIL-FROM. Email headers are part of SMTP DATA and are arbitrary, I (as in me) can send messages with any headers I want, it's trivial and legitimate for me to do so. Spam sometimes adds additional "Recieved" headers so that it appears (to novices) to have come from elsewhere.
We (as in work) strip all "Recieved" headers containing internal network addresses when we send mail outside our network. We also used to add a false header that made it look like the mail had passed through another internet facing host that was, in fact a honeypot.
* IP's don't always trace back when the headers are forged.
* The only way you can trust mail headers is by signing the entire message and storing the key in DNS, at which point you may as well be using SPF.
It's your DNS server which gets hit (a very lightweight hit--one UDP request, and a reply, which is static and requires no processing), not your mail server. In most cases, depending on the recipients' configurations, your DNS server is getting hit by the receiving mail server anyway (reverse lookup), so this is not a significant increase in traffic.
CAn'T CompreHend SARcaSm?
Perhaps I wasn't clear. SPF tells you whether a given sender is authorized to send mail from some domain. It doesn't tell you whether the sender is really from that domain.
SPF is doing the wrong job, and not doing it well. What's to keep a zombie from querying DNS to find the correct mail server for its domain and forging the headers to reflect that? Nothing. It would then be up to the individual ISP to make sure noone in their domain does that.
Right. If they were willing to do that, they'd do it now.
There is also nothing keeping a spammer (or a spam-friendly ISP) from publishing DNS SPF records for its zombies. Expect a worm that does that to be written as soon as the spec is finalized. All those WinXP DNS servers out there ... [[shudder]].
sigs, as if you care.
I've just read a badly-edited book which (mis)used "try and" on about every couple of pages and now it goes through my head like a nail. Please have mercy on those of us accustomed to reading good writing.
Receiving mail is done over a TCP connection, which is two-way. You can't forge the from IP address, because the server's replies will go there, not to you.
Eg:
Once sph gets a large enough install base, the spammers will need to find another way to convince victims to open their email. My prediction is that we'll see more mail from yah00.com, a0l.com, ao1.com, etc. All a spammer has to do is get a domain like that registered and publish an SPF record for it and they'll be able to continue their operation. It does make them work harder though, and it pretty much negates the usefulness of trojans that turn infected machines into a spambots.
Yes, my only tool is a hammer. And you're starting to look like a nail.
If that were how it worked, it would be a little draconian, but probably better than the current protocol. I don't think that's the design, though. It looks to me that there is not the alteration to SMTP that you describe.
SPF/SenderID just check the headers of an already-received message to make sure that the headers reflect a valid mail server.
If I'm wrong, that's good.
sigs, as if you care.
Whatever happened to the idea that the Internet was a community of peers? I mean, my web browser doesn't care if the web site is registered with DNS or not. I can go to 125.10.233.5 as easily as I can go to linux.com. Likewise, my mail client doesn't care about DNS records. That used to be an optional part of the whole.
:(
Looks like the days when every machine was a peer on the Internet is gone in favor of the day when every machine must register with a superpeer (like DNS) to be considered a valid endpoint.
Kinda sucks, if you ask me, to fight spam by ruining the best part of the Internet, ESPECIALLY WHEN THERE ARE BETTER ALTERNATIVES OUT THERE! Look at IM2000 or any similar idea. These would work just as well without requiring me to lose my status as valid endpoint and without me being forced to register with a superpeer, like DNS.
-Tom
I think (please correct me if I am wrong)
a) most ISP nowaday is moving toward virtual domain for email given there are a lot of great open-source projects to make setting up virtual domain email a piece of cake (e.g. virtual domain guide from Gentoo And it is easier to maintain.
b) centralization of trusted resources in this context is local to the ISP and their customers. and I am pretty sure they will have database replication one way or the other to keep things running smooth.
c) this actually helps to reduce waste bandwidth for dealing with spam at the very early stage of spam life cycle since it is being dealt with before it gets send.
d) this makes spammer trace-able in a way which may help law enforcement in future.
I'm already suffering from this after establishing an SPF record for my domain -- a friend of mine (@mail.ru) forwards all his e-mails to his cell-phone. The cell-phone company checks the SPF record of my domain and rejects them, because mail.ru's servers are not listed in my SPF record (nor should they be)... As a result, I get the bounces and he gets no notifications.
Until the mail-forwarding is fixed somehow, SPF should not be adopted...
In Soviet Washington the swamp drains you.
This may also helps to reduce the usefulness of having spam zombie PC around the internet.
IANAL, but the licence restrictions for incorporating the patented Domain Keys algorithm into source code appear to be incompatible with both the GPL, and with BSD style open source licencing. Isn't this the same problem that killed Sender-ID in favour of SPF?
http://antispam.yahoo.com/domainkeys-license-01
Doug Moen
I have written a truly remarkable program which this sig is too small to contain.
http://shit.slashdot.org/article.pl?sid=04/09/13/1 317238&threshold=-1&tid=172&tid=95&tid=218
Somebody needs a grammar checker...
You mean like this:
Sep 12 15:18:26 rdb sm-mta[11323]: ruleset=check_relay, arg1=dsl-201-128-63-211.prod-infinitum.com.mx, arg2=201.128.63.211, relay=dsl-201-128-63-211.prod-infinitum.com.mx [201.128.63.211] (may be forged), reject=553 5.3.0 (bjabl)Known Spam Source - Mail from 201.128.63.211 rejected.
No additional milter req'd.
1. Will it solve spam? Well, it was announced with the statement "Spam as a technical problem is solved by SPF." but -- despite the lack of a full public retraction of that statement, we're now told it was never intended to solve spam. Fine...but let's note that if it didn't claim to have something do with spam, few people, if any, would care about it.
2. Will it solve forgeries? No. There are still a myriad of ways forgeries can be constructed -- and many of those will pass SPF checks, because they utilize the outbound mail servers as unforged mail. (And while you might think that the people running those mail servers would detect and correct this...you'd be wrong. They've built up multi-year track records demonstrating that they either don't know or don't care -- so it's unlikely they'll wake up tomorrow feeling differently.)
3. Will it stop bounces from forgeries? Maybe. But it's important to note that it doesn't stop them by actually FIXING the broken mail systems which are generating them. This is a brittle approach to solving the problem which has as its only merit that it may be easier than tackling the core issue. But experience strongly suggests that it would be much better for the long-term health of the Internet's mail system to roll up our sleeves and actually deal with the bounce-vs-reject issue than find a way to sweep it under the carpet.
4. Will it stop joe-jobs? Maybe -- if enough people use it, if spammers don't game it (and they're already working on it) and if it doesn't impose its own consequences. (Consider what will happen to your DNS servers if some spammer decides to joe-job your domain and N mail servers out there -- instead of just rejecting the traffic and being done with it -- all try to verify your SPF records simultaneously.)
5. Does it solve an important problem? No. Forgery isn't a serious problem -- spam is.
6. Does it solve the problem thoroughly? No. Really solving mail forgery requires secure DNS, public-key encryption of message content, secure end-user systems, secure mail clients, and other components. These all exist, but until they're ubiquitous, any sense that the mail forgery problem is "solved" is illusory.
Despite all this, there are a few good ideas in SPF, and in DomainKeys, and in some of the other proposals which are out there. But those ideas need to be weighed in light of the environment in which we find ourselves, and take into account:
- Millions of hijacked systems
- Cheap "throwaway" domains
- "Bulletproof" hosting
- Rapidly-updating DNS (which just got worse)
- non-SMTP methods of sending spam
- poorly-maintained mail gateways
- Scalability (SMTP, DNS, etc.) concerns
among other things. For example, a much better (and far simpler) proposal that could be implemented immediately with minimal impact is: here. Of course, this doesn't solve everything either, nor does it claim to: but what it does tackle, it handles very well. Backers of SPF/DomainKeys/etc. would be well-advised to take a long look at it.It's possible to do that, but anyone with a clue will have set up their mx to reject anything that fails a reverse lookup...
Code, Hardware, stuff like that.
.... is not quite as simple as this ....
the IETF in fact achieved consensus on an IPR policy. It was just not a policy that demanded Royalty-Free and Open Source Compatible licensing of everything.
As I see it, both SPF and SenderID cannot really prevent email address forging:
SPF only verifies the envelope from (SMTP MAIL FROM command).
SenderID has an "algorithm" for trying to determine what email address the message claims to "come from" using RFC822 "From", "Sender", "Resent-from" and "Resent-sender" (actually also "Received") headers (they call it "Purported Responsible Address"). Then the domain in this address is chacked against a DNS record defining a set of IP addresses that may be used to send for that domain.
Why doesn't it prevent Joe jobs?
Because all that the spammer needs to do is provide a "Sender" header with a domain that is allows the server the spammer uses to send, and the email would get through. Replies would go to the address in the "From" header, and that would be the poor victim of the Joe job. Bounces would go to the envelope from, so with SenderID that would not be the verified address, but again the poor victim's address. "Classic" SPF at least has an advantage of avoiding real SMAP bounces from going to the Joe job victim.
The same works for phishing. a phisher might have to be more caerful about revealing her own identity by registering a domain to use in the "sender" header, but then a phisher has the advantage of belonging to the "identity theft industry", so would probably have no problem to use previously stolen identities+credit card numbers to register enough domains to be able to steal even more identities.
These "verification schemes" might allow a bit more information to be revealed about the physical system used to send spam, but that's all. And every spam message that tries to sell something already has some kind of info on how to contact the spammer in order to make a purchase, that can be used to track the spammer (and often convict the spammer for something other than sending spam, such as illegal selling of drugs, or fraud, in the case of "organ enlargement pills" etc.)
So it's doubtful whether these "verification schemes" are worth the trouble.
There rest is a bit "off topic":
I have a very simple "verification scheme": different possible senders get different addresses, and the address that receives the email message should then match the sender. Theoretically I can create rules to trash whatever doesn't match, but practically there's no need, because it rarely happens that they are needed, and if they are, then in a single sender situation it's easier to replace the address and notify the single sender of the address change. (actually the only addresses where I get spam are the ones that are publicly available, such as that used in slashdot and the one in my whois record. And the spam volume they receive is low enough that for now I prefer to report the spam I get to spamcop and not change the addresses).
Perhaps a better solution to make life hard to spammers is an "address change notification protocol". This would allow creating systems that automatically create different addresses for different senders, and do it in the background making it transparent for the user. Spammers depend on pretty reliable mailing lists, and a situation where each address would receive a single piece of spam and then be automatically changed would be a nightmare for them. It would ruin their business model!
#1. -------
You write a message somebody@hiscompany.com and mark it From: me@mycompany.com
You send message from your ISP's mail server.
When somebody's mail server gets it, it will look up the SPF address for mycompany.com (that's whom the message claims it is from). If mycompany.com's SPF record does NOT reference the ISP's servers, the message will be assumed to have failed the SPF test.
So the ISP's SPF record will not be checked.
#2. -----
Spammer sends a message from an open relay in China claiming to be from hotgirlz@hotmail.com.
Your server receives it and checks the SPF for hotmail.com. Since the hotmail servers will NOT reference the open relay, the message will fail the SPF test.
The problem is not "software patents" but obvious things being patented. That fact that something that is done in real life (such as remebering your client) can be considered an innovation just because it is applied in software, and therefore may be patented, is a flaw in the way patents are examined. The fact that any prcedure can be done by a computer (a "Turing computer") was already proved by Turing in 1936 (or at least was well known in the 30's). It doesn't mean that new procedures used in software shouldn't be patentable. But it does mean that software that just mimicks functiionality alreaddy existing not in software should not be patentable. So for example, a new method of voice recognition might be patentable, but the use of voice recognition by a computer to identify a customer shouldn't be patentable, since there is prior art: a lot of people that know me can identify me by hearing my voice on the phone (actually they can also identify me by analysis of my facial characteristics ;-) ). The procedure exists. And the fact that if it can be done without a computer it can be also be done by a computer is well known. So these kind of patents should be voided.
> In the case I guess the only option will to be use webmail
> for any addresses not provided by my ISP
Not really. You would just need to have your mail user agent (your email client) to add a "Sender:" header specifying an address in the domain you are sending from.
If it doesn't have this functionality, ask the vendor to include it.
If it doesn't (and it's name start with an M and ends with a $) then use another client.
Probably if and when these sender recognition schemes become widely employed, free software email programs would include options to set a "Sender:" header configurable by server used to send (so if multiple SMTP servers are available for the client for sending, the client would automatically send to an address that may send from that server).
The problem you described already exists for example for Gmail users who use their email clients to send email to recipients in one of the few places that already implemented rejeting by SPF.
Oh, I know ... it was a configuration error that simply didn't matter when the system was first installed. All I have it do now is simply drop any messages with an invalid local address because I don't have any reason to pass an error along to my domain host's POP3 server: they have no idea how my local server's accounts are configured and as far as they are concerned it's just legitimate mail. But the volume of spam my primary domain has received as gone up at least an order of magnitude this year, and I simply ran afoul of new anti-spam measures put in place recently by my ISP. Couldn't argue about it, it was my fault.
The higher the technology, the sharper that two-edged sword.
Ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg04
Actually, I think it will soon be even more common to see people wrap their organization in an email "firewall" which is pretty likely to run a free Unix, as the email problems continue to mount until a truly disproportionate amount of the time of either people in power or their secretaries is spent dealing with email. It's getting there, although for most people it's still only a slight annoyance.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Now Microsoft says they have applied for a patent on reading the headers on an email to determine -- what? Who sent the mail! Could the writers of the RFC 822 have ever imagined that the headers on an email might be used for something so non-obvious -- so brilliant -- as determining the email address, including the domain name, of the person/entity that sent the email?
And Microsoft doesn't even have to be granted this amazing patent to throw the MARID working group into a tailspin. They only have to mention that they've applied for it...
>It's possible to do that, but anyone with a clue will have set up their mx to reject anything that fails a reverse lookup...
Um, no cigar. Close though. Mail will probably rejected on failure, but almost never on a mismatch of the reverse lookup.