Slashdot Mirror

← Back to Stories (view on slashdot.org)

SPF To Be Integrated With MS 'Caller ID' System

Posted by timothy on from the in-quotes dept.

An anonymous reader submits "CNET's news.com is reporting 'An ongoing effort to consolidate antispam authentication schemes took a big step forward with the merging of Sender Policy Framework (SPF) and Microsoft's Caller ID for E-mail.' This is potentially good news." For more background, here are three previous mentions of Microsoft's proposed Caller ID-style system.

25 of 227 comments (clear)

  1. The only good anti-spam solution by FictionPimp · · Score: 4, Funny

    Stop using email. Require all communication to come on 11X17 inch plastic sheets sent via fedex. Thats what I do.

    1. Re:The only good anti-spam solution by Da+Fokka · · Score: 4, Funny

      Hail, brother!

      We don't use cars at my business. They're too cumbersome. I still prefer the good ol' horse-and-carriage. They can make a mess but doing so in front of the offices of the guys who keep sending us directmail solves that problem as well.

      But what is this 'fax' you are talking about?!

  2. Good they've merged. Why XML ? by Space+cowboy · · Score: 5, Insightful


    The combined SPF and Caller ID, which has yet to be named, will use XML (Extensible Markup Language) to let Net service providers post IP addresses in the Domain Name System, the giant database that translates alphanumeric domain names like "news.com" into numerical IP addresses for Web servers.

    I have yet to see a good reason why XML is the choice for the payload. I'm not really buying the argument that it's easier to shoehorn XML into TXT fields rather than have another tag. Either way, in order to implement the proposal the MTA authors will have to do some work, and I don't think there's much to choose between the two...

    I still can't really rid myself of the nagging suspicion that the extensibility of an XML-driven anti-spam system plays into the hands of 'embrace and extend' that MS has used successfully since time began...

    On the other hand, getting some authentication that it really came from where it says it came from will be very useful. The corollory is that 'owning' a mail server will become a higher priority for the hacker/spammer coalitions. Look for more attacks on MX machines if this becomes widespread...

    Next on the agenda - get everyone to use digitally-signed certificates :-)

    Simon
    --
    Physicists get Hadrons!
    1. Re:Good they've merged. Why XML ? by Allen+Zadr · · Score: 5, Insightful

      That's a good point, but I see the eXtensability of XML as the power here. It would be relatively simple to extend the Email-Caller-ID XML specification to include an <spf:details/> tag. Which, would naturally allow for other extensions as well.

      Remember, too, that XML is not a Microsoft technology. It's a W3C technology that Microsoft also uses. That's a big difference. If this proposal included a .NET extension to my Mail server, then I'd be suspicious.

      My question is: How will SPF or Email-Caller-ID take into account mailing lists? Will this block Emails from my address sent through sourceforge.net's many fine list servers?

      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
    2. Re:Good they've merged. Why XML ? by thogard · · Score: 4, Informative

      Cracker will love the xml format. It turns out that the record size will exceed the UDP packet size for DNS records so they get upsized to use TCP packets.

      The thing is how many people allow TCP packets on port 53 on their firewall? There is no reason execpt to talk to your second-dns records. All other cases should be turned off but this requires that it be turned on.

    3. Re:Good they've merged. Why XML ? by Allen+Zadr · · Score: 5, Informative
      Actually - nevermind. I found a reason why I can't impliment this technology, ever.

      Use of this technology requires submitting to a Microsoft license. This license allows distribution (but not re-distribution), and is not compatible with the GPL. That is to say, no GPL mail server will ever be able to directly impliment checks for this.

      From the license (forgive typos, I typed this from the PDF):

      2.2. Source Code Distribution You also have a nontransferable, non-sublicenseable, personal, license to distribute or otherwise disclose source code copies of such Licensed Implementation licensed in Section 2.1 only if You (i) prominently display the following notice in all copies of such source code, and (ii) distribute or disclose the source code only under a license agreement that includes the following notice as a term of such license agreement and does not include any other terms that are inconsistent with, or would prohibit, the following notice:

      "This source code may incorporate intellectual property owned by Microsoft Corporation. Our porvision of this source code does not include any licenses or any other rights to you under any Microsoft intellectual property. If you would like a license from Microsoft (e.h. rebrand, redistribute), you need to contact Microsoft directly."

      That, my friend, is embrace, extend and assimilate. Nothing under strict GPL can impliment this natively. IIRC, SPF (Sender Permitted From) did not have source restrictive terms.
      --
      Kinetic stupidity has a new brand leader: Allen Zadr.
  3. SPF 30 by FireBug · · Score: 5, Funny

    Why on earth are they integrating SPF into technology? I mean, it's not like Slashdotians ever go out into the sun or anything...

    Laugh! It was a joke!

  4. Re:Why not XML? by lpontiac · · Score: 4, Informative

    XML is not a format. It's a metaformat.

  5. Sounds like a truly awful idea by isdnip · · Score: 4, Insightful

    Now it sounds like a bad idea for both semantic (what it does) and syntactic (how it is coded) reasons!

    The syntactic bit is easy -- XML is hardly appropriate for a DNS function. Mickeysoft is running around patenting XML schemas, and it adds a new layer of complexity to DNS. But then bad syntax is usually dealt with by code.

    The semantic bit is worse -- SPF doesn't block spam unless the mail system makes it mandatory, after all, so until 100% compliance is reached, non-SPF mail will still have to be accepted. But wait -- SPF doesn't block spam! It just blocks spam where the From: is not right. Spammers can still create new domains on a hit-and-run basis, and they'll pass SPF. So it's another blast-proof vault door stuck onto a grass hut, a silly waste of time. The only potential real benefit, I suspect, would be to make phishing harder. The address will have to be slightly different from the spoofed domain. But that leaves plenty of opportunity to create deceptively-close hit-and-run domains (like, say, pay-pa1-approva1.com).

    Worse, of course, is the collateral damage. How will I be able to send mail using my own business' domain, as I do today, when it is going out via an ISP server? My "from" address is an alias, not a real sender, and I use it to send via more than one ISP, depending on where I am. SPF seems to make this a lot harder, thereby forcing more people to put their ISPs' name in the From: field, rather than their own. Since email is not portable, a user's address is lost when they change ISPs, or when their ISP changes names (mediaone->attbi->comcast). Personal domains (forwarded via a service like mydomain) solve this. Will SPF kill mydomain?

    I repeat what I've said before. The only way to kill spam is to stop having all email be totally, absolutely, "free" of charge in any quantity. This is not the topic to discuss solutions, but they are certainly possible, and they aren't SPF.

    1. Re:Sounds like a truly awful idea by Albanach · · Score: 5, Insightful
      This is not the topic to discuss solutions, but they are certainly possible, and they aren't SPF.

      If spammers have to buy new domains for every couple of thousand spams they face a big problem.

      • Firstly it all adds to the cost - with tiny response rates you'd have to imagine the margins are tight.
      • Secondly if they have to buy domains they need to pay for them - that leaves a physical paper trail to spammers, now legislation can help.
      • Thirdly we have plenty of existing technology such as black hole lists that will be a lot more effective if lots of spam comes from one newly registered domain.
      • Fourthly we don't need the entire web to be using SPF for it to become effective. If you receive spam from an AOL account it's now possible to easily check if it in fact came from an AOL mailserver. That other people haven't yet implimented SPF is irrelevant - we can use the technology to our advantage today. Once it's widely implimented we can even start to apply a small spamassassin score to not SPF confirmed mail. As adoption grows we can increase that score still further.
    2. Re:Sounds like a truly awful idea by Chang · · Score: 5, Insightful

      > SPF doesn't block spam unless the mail system makes it mandatory, after all, so until 100% compliance is reached, non-SPF mail will still have to be accepted

      This is false. There is no requirement for every domain on the internet to adopt SPF before it becomes useful.

      Instead each domain owner decides when to flip the switch on for SPF enforcement for their individual domains. Since 14,000 domain already have valid SPF records and many of them have enabled enforcement, SPF is useful for not accepting worthless spoofed emails TODAY. Not in some far off future.

    3. Re:Sounds like a truly awful idea by FattMattP · · Score: 5, Informative
      But wait -- SPF doesn't block spam!
      Correct. It's not meant to. SPF's goal is to prevent domain name forgery. Blocking spam, if it does that, is a side effect. Authenticating the sender is the primary goal.
      It just blocks spam where the From: is not right.
      No, that's what MS "Caller-ID" does. SPF checks the MAIL FROM in the SMTP transaction. Think of it this way, SPF does its checks on the envelope and caller-id does its checks on the header.
      The only potential real benefit, I suspect, would be to make phishing harder.
      That's the point.
      --
      Prevent email address forgery. Publish SPF records for y
  6. Re:Why not XML? by DrPizza · · Score: 5, Insightful

    Because, since XML is not a format (but rather a standardized way of creating one's own formats) the issue of "creating a format" is not solved by the decision to use XML.

    What XML "wins" is off-the-shelf parsers; one still needs to write some amount of code to convert dumb XML (elements and attributes and all that crud) into something with semantic meaning to your application.

    For a simple application like this it's not clear that the overheads of XML (both in terms of size, computational complexity, and programmer overhead to make the aforementioned conversion) are at all worthwhile.

  7. Re:i still don't trust it... by WormholeFiend · · Score: 4, Insightful

    I think their main motivation is to stop the spread of virus attachments... anytime there's a MS-targetting worm going around, using similar distribution processes as spam, it creates an additional workload, not to mention that it tars Microsoft's image.

    From my point of view, the spam cleanup would just be collateral.

  8. You could've read all about it last week... by jgardn · · Score: 4, Insightful

    ...in a comment I made here.

    Basically, this is a simply classic way to "embrace and extend" Microsoft's Caller ID. Before the flag day, SPF will work the way it is now. After the flag day, which will probably occur later rather than sooner, SPF will have all the functionality of Caller ID. The idea of allowing both XML and text descriptors is simply brilliant. Microsoft wanted to force everyone to use XML, but now you have a choice. I believe most (like 99.9%) will use the text descriptors, both because it is easier and because it is sufficient for 99.9% of the cases.

    The net result is Microsoft can't claim ownership anymore. Caller ID will be a footnote in the history of email authentication.

    --
    The radical sect of Islam would either see you dead or "reverted" to Islam.
  9. Re:Boycott of Microsoft's Caller ID for E-mail by Rayban · · Score: 4, Interesting

    I heartily agree! It's good to see them cooperating, but I hope that the final license has a royalty-free patent grant with no attribution clauses.

    If the two camps agree, this will speed up adoption of SPF records enormously.

    --
    æeee!
  10. Spam solution already exists by Rashkae · · Score: 5, Interesting

    Spam would very quickly cease being a problem if mail clients were configured to start using PGP (GPG) keys and signatures by default. There is no need to re-invent or even change the e-mail RFC's.

    Very simply, people can choose whether they want to receive unsigned e-mail, or accept sinatures from unkown keys. We'll eventually start building a web of turst (mistrust), such as, being able to automatically accept a key signed by some people or orgs, and similarly, blacklisting keys.

    I could very easily, for example, instruct unknown senders (people who aren't in my contact list yet) to download my public key from a specified location to encryp a message that would bypass my filtes. Only a person who followed the instructions would be able to send me an unsolicited message.

    1. Re:Spam solution already exists by gclef · · Score: 5, Insightful

      You know, people have been saying that for almost a decade now. Face it: digitally signed email isn't working. Key management is a pain in the ass, the bootstrapping necessary to check user's keys is a mess, and it doesn't really gain you that much in the end. We've had 10 years to get signed email working, and it didn't happen. Time to find another way (whether it's this SPF or something else is a point for argument).

  11. breaks forwarding by close_wait · · Score: 5, Informative
    I dislike SPF because it breaks forwarding. There is a "workaround" but that's required on every MTA in the world that allows forwarding, and is intensely ugly - it requires adding a bunch of garbage to the sender address, and also requires the MTA to main a cache of forwarded addresses so that bounces can be passed back down the chain.

    The problem is this. Suppose AOL start adding SPF records to their DNS, saying effectively 'only the following IP addresses are authorized to send @aol.com emails. Suppose also that Hotmail start rejecting emails from SPF domains where the IP addresses don't match. Now suppose that joe@small.biz is going to be away from the office for a couple of weeks, so he gets the small.biz mail server to forward his emails to his hotmail account. At this point anyone from AOL who emails him will find the emails bouncing (although if they're from AOL, this may not be such a bad thing...)

  12. Pobox.com antispam working like gangbusters for me by DeadVulcan · · Score: 4, Insightful

    Well, I'm a pobox.com customer, and my own experience of their new antispam measures is absolutely nothing but fantastic. They recently overhauled their spam filters, and the result (again, this is just my experience) has been stunning.

    Of course, this says little about SPF itself, but at the very least, for what it's worth, the company that invented it comes with my recommendation.

    ...until 100% compliance is reached, non-SPF mail will still have to be accepted.

    Well, the way pobox.com has done it, you can choose to have your E-mail "flagged." SPF is one of those possible flags. If an E-mail gets X (a user-definable number) or more flags, it can be rejected as spam. This makes SPF useful even when there isn't 100% compliance.

    How will I be able to send mail using my own business' domain, as I do today, when it is going out via an ISP server?

    I would think that if your ISP is interested in doing honest business, they would make the effort to list their own mail server.

    If you're running your own mail server, then, yes, this is a valid concern.

    The only way to kill spam is to stop having all email be totally, absolutely, "free" of charge in any quantity.

    I don't deny that that would be a very effective way, but I don't agree that it is the only way.

    --
    Accountability on the heads of the powerful.
    Power in the hands of the accountable.
  13. Re:Why not XML? by Russ+Nelson · · Score: 4, Insightful

    Uhhhhhhhh, because a DNS packet is limited to 512 octets??
    -russ

    --
    Don't piss off The Angry Economist
  14. dynamic dns users by tacocat · · Score: 4, Interesting

    How will this effect dynamic DNS users who send email? I'm not talking about some rogue spammer, but the people who have legitimate servers running on real IP addresses with domain names that are managed by the likes of dyndns.org

    In the past, these DHCP hosted addresses have been under a lot of grief with people erroneously RBLing them simply because they are DHCP (like it ever really expires!!!) managed IP addresses.

    Much of the workaround for this has been to RELAY all the email up to the ISP for delivery from a non DHCP hosted IP address. But some people block these because they show evidence of being relayed by anyone and hence must be evil.

    So what will have to do in order to get my mail server considered acceptable for sending email under this SPF/CallerID scheme?

    I'm also really curious to see how this can be a good thing at the same time that it involved Microsoft, but I'm trying to keep an open mind on this one...

    1. Re:dynamic dns users by ahodgson · · Score: 5, Insightful

      In theory, SPF should make it easier for these people to send E-mail. They can publish a valid SPF record for their domain, which should make mail from their system more trustworthy than mail from dynamic IP space is generally. Ie, the reason people block mail from dynamic IP space is because of the incredible amount of crud coming from trojanned Windows machines in that space.

      If a real sender can somehow distinguish themselves via a valid SPF record, they might actually have better luck sending mail than they do now.

  15. AOL and MS say: publish SPF records by wayne · · Score: 5, Interesting
    AOL just added a webpage saying that you should publish SPF records if you want to be whitelisted with AOL.

    The MicroSoft Caller-ID/SPF merger proposals say that SPF records will be honored, so you can publish them without fear of losing support.

    So, go ahead and publish SPF records.

    MicroSoft supporting SPF records is a really smart move. Last week, I posted results of a survey of 1.3 million email domain names to the IETF MARID mailing list. Now that I'm back from the MARID meeting, I just finished a survey of Caller-ID records. There appears to be about a factor of 500-1000 more domains that have published SPF exclusively than Caller-ID exclusively and only a tiny fraction of the 1.3 million domains have published Caller-ID records. In short, MicroSoft isn't changing to support SPF records because they are better (I think they are), but because it is an acknowledgement that MicroSoft's Caller-ID hasn't caught on.

    Meng Weng Wong (the SPF author) and MicroSoft are still discussing how exactly this merger will work on. I personally don't see any reason to support XML right away. MicroSoft has not come out with a single concrete extention that can't be done with SPF already.

    I also think that there are alternatives to the complex Caller-ID algorithm and that doesn't require every Ezmlm and other mailing lists to upgrade their software. From the research that I've done (and yes, this is something I have really researched), there appears to be far more mailing lists broken by MS's Caller-ID system than email forwarders broken by SPF.

    (I'm the author of libspf-alt and the maintainer of the trusted-forwarder global whitelist. So, now you know why I have researched this stuff so much.)

    --
    SPF support for most open source mail servers can be found at libspf2.
  16. Why XML is bad by tacocat · · Score: 4, Insightful

    It's simple really. DNS is one of the highest areas of traffic and hits out there. Every web page generates multiple DNS hits and so does email and P2P and everything else.

    XML, is a bunch of text that wraps around a bunch of data and is called meta data. It's not the data you need, but data about the data you need. In DNS, you already know what you need, so the "meta" is silly.

    Point being, you add a lot of extra characters to the data transmissions. UDP won't support it anymore so we have to to with TCP, which has even more overhead being added to the process.

    Compound this with MSFT's tendency to send shitloads of data across every network they touch just because they can, and you've DDOSed the Internet.

    XML may have a place, but DNS sure as hell isn't it.