Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Spam Microsoft The Internet Your Rights Online

SPF To Be Integrated With MS 'Caller ID' System 227

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

SPF To Be Integrated With MS 'Caller ID' System More

SPF To Be Integrated With MS 'Caller ID' System

Comments Filter:

  • The only good anti-spam solution (Score:4, Funny)

    by FictionPimp ( 712802 ) on Wednesday May 26, 2004 @10:33AM (#9258616) Homepage
    Stop using email. Require all communication to come on 11X17 inch plastic sheets sent via fedex. Thats what I do.

    • 11x17, eh? I was tempted to point out that "I live in Europe, you insensitive clod!" until I thought... that'll make it even harder! What's the US equivalent of A0, Really f*ing big? And does it have to be plastic - would a precious metal do? ;)

      Slightly less off-topic: the Singapore government is proposing [theregister.co.uk] to fine spammers up to a $1 (Singaporean) per spam. Granted, it won't stem the tide from outside Singapore, but it's a sight better than CAN-SPAM or anything the EU's proposed.

      <thinks>Can't we

  • Good they've merged. Why XML ? (Score:5, Insightful)

    by Space cowboy ( 13680 ) * on Wednesday May 26, 2004 @10:34AM (#9258618) Journal


    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 [slashdot.org] 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

    • Why not XML? (Score:2, Insightful)

      by Mz6 ( 741941 ) *
      Why build a new format when there is one already available that would suit their needs?

      • Re:Why not XML? (Score:5, Informative)

        by lpontiac ( 173839 ) on Wednesday May 26, 2004 @10:44AM (#9258704)
        XML is not a format. It's a metaformat.

      • Re:Why not XML? (Score:5, Insightful)

        by DrPizza ( 558687 ) on Wednesday May 26, 2004 @10:48AM (#9258733) Homepage

        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.

        • Re:Why not XML? (Score:4, Insightful)

          by BlackHawk-666 ( 560896 ) on Wednesday May 26, 2004 @11:16AM (#9259003)
          Plain old text files might be better I reckon. e.g.

          MX:MyFatServer:212.169.24.12,212.169.24.13
          MX:MyOtherServer:212.169.24.16

          Not taxing to parse, simple, grepable, fast, lightweight, human readable. Even if you work for MS you should be able to write the code to parse this ;->

      • Re:Why not XML? (Score:3, Insightful)

        by silas_moeckel ( 234313 )
        How about because XML is pretty bloated and an embrase and extend sort of language thats designed to let people insert new things without breaking old things. Meaning MS or anytbody else can introduce new tags that arent compatable with somebody elses tags, they shouldent collide but the bloat gets pretty bad when you have to support 2 3 4 20 differnet version of the same tags to be compabible with everybody. XML is good for programs that should be embraced and extended. Internet related thigns should co
        • But SMTP already allows anyone and their grandmother to add new header fields. Keeping that feature is good for change and innovation.
          • Yes they allow new headers to the mail thats all fine and dandy (I would hate for spam assisin not to work) it's about allowing people to change things in DNS most importantly insert big ugly XML that needs to be retreived in a single packet or your overheard goes through the roof setting up a tcp session etc etc etc. Basicaly adding an extensible standard to something of a fixed size does not make sence. The packet simply can only be so big so you cant let anybody do whatever they want in it.
        • where all you get is (if you're lucky) a text version of the email message, then a WINMAIL.DAT uuencoded or MIMEd attachment, which contains all the useful data in a proprietary binary format.

          Rather than simply create compliant MIME mails, Microsoft uses this secret format to say "yeah, we'll try and send email, but if you really want to communicate with companies that use Exchange Mail Server, you need to buy a copy of Exchange Mail Server".

      • Re:Why not XML? (Score:5, Insightful)

        by Russ Nelson ( 33911 ) <slashdot@russnelson.com> on Wednesday May 26, 2004 @11:36AM (#9259174) Homepage
        Uhhhhhhhh, because a DNS packet is limited to 512 octets??
        -russ

    • Re:Good they've merged. Why XML ? (Score:2, Interesting)

      by Anonymous Coward
      not only that but xml will slow down the dns lookup since the answer will exceed the udp limit and will have to switch over to tcp.

    • Re:Good they've merged. Why XML ? (Score:5, Insightful)

      by Allen Zadr ( 767458 ) * <Allen.Zadr@g m a i l . com> on Wednesday May 26, 2004 @10:44AM (#9258705) Journal

      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?

      • Re:Good they've merged. Why XML ? (Score:5, Informative)

        by Allen Zadr ( 767458 ) * <Allen.Zadr@g m a i l . com> on Wednesday May 26, 2004 @11:30AM (#9259135) Journal
        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.
      • Dude, there's a gazillion formats which can be extensible and self-documenting. XML is a religion, and you obviously drank the kool-aid.
        -russ
        • Wow, a gazillion [google.com]? Cool!

          Do you have a better alternative? Preferably something that is standardized, or at least based on something that most developers would already have some familiarity with.

          Troll me if you like, but please, contribute an alternative idea along with your troll.

    • "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..."

      isn't that what the X in XML stands for? you seem to be under the impression that XML is evil because MS embrace it so heavily. ok, i'm putting words into your mouth, but that's what I read nontheless. personally i don't see the difference between RCPT-TO: blah@blah.com and blah@blah.com. both of the

      • you seem to be under the impression that XML is evil because MS embrace it so heavily

        I'd like to think I'm a *bit* more analytical than that! If you read the link in my post, I do say I'm a fan of XML, I just didn't think it was worth repeating...

        My point is that if you establish an open standard which everyone starts to use, and people then start to add things, because they can, because XML parsers ignore what they don't understand, the whole system can become far more complicated (and therefore vulnera

    • Re:Good they've merged. Why XML ? (Score:5, Informative)

      by thogard ( 43403 ) on Wednesday May 26, 2004 @11:11AM (#9258951) Homepage
      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.
      • So crackers are going to somehow use port 53 of my machine to connect to a nonexistant server and root my box?

        Open ports are not inherently insecure.

      • The plan appears to be to support both XML and v=spf1 formats (according to the summary of the meeting between the SPF and Microsoft folkw). The expectation is that the vast majority of sites will publish the simple and compact v=spf1 format for the forseeable future. XML allows extensibility for the unforseen future that follows afterwards.
  • You will be truly disturbed to find out that your Grandmother is apparently the one who's been pushing for you to use Cialis.

  • SPF 30 (Score:5, Funny)

    by FireBug ( 83228 ) on Wednesday May 26, 2004 @10:38AM (#9258659) Homepage
    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!

    • Re:SPF 30 (Score:4, Interesting)

      by Pxtl ( 151020 ) on Wednesday May 26, 2004 @10:51AM (#9258764) Homepage
      Cute. Still, I do wonder why they even advertise this as "caller ID" - after all, everyone knows caller id can be spoofed. Really, the existing e-mail header is the same as caller ID. In theory it says who's calling, but anyone dedicated can get around it.

      Why don't they just call it like it is? A secure substitute for the "source" field of the e-mail header.

  • Sounds like a truly awful idea (Score:5, Insightful)

    by isdnip ( 49656 ) on Wednesday May 26, 2004 @10:47AM (#9258720)
    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.
    • As for email not being portable, I'd expect more personal domains (or permanent email addresses) as a result. Google's GMail (and other long-term, high-storage services) would let you keep your email address even if you switched ISPs. I bought a domain just so I would have an email address that I wouldn't have to worry about losing.

    • It just blocks spam where the From: is not right.

      Correct, but what this means is that there should now be some level of accountability to the originator. One of the biggest complaints I would have, looking into email-spam as a problem, would be that there's no way to hold a sender accountable when the true origination of the message is unknown. If I understand the proposal correctly, that accountability will at least be marginally present.

      The ability to spoof this system is another issue entirely.

      • An SPF record is a record stating what hosts are registered senders of mail from a given domain. There's nothing stopping you from adding, say, smtp.verizon.net or whatnot to the record.

        Of course, there's also SMTP AUTH...

    • Re:Sounds like a truly awful idea (Score:5, Insightful)

      by Albanach ( 527650 ) on Wednesday May 26, 2004 @11:08AM (#9258926) Homepage
      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.

      • Legislation hasn't helped yet (Score:4, Insightful)

        by swb ( 14022 ) on Wednesday May 26, 2004 @11:37AM (#9259186)
        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.

        Sorry, but I have to hit the bullshit button. Legislation hasn't helped yet, and I'm not talking about CAN-SPAM or any of the other anti-bulk mail bills, but the existing laws dealing with all manner of fraud, FDA regulations and any of the other various and sundry state and federal laws regulating the almost-universally fraudulent commercial content of spam.

        You're suffering from the same delusion that many people, myself included, often suffer from -- "Can't we pass a *law*"? -- when there are many good laws already on the books that better deal with the problem in general.

        I'd suggest a RICO investigation into some of the top-level spammers, their clients, and the people involved in the payments, the network access, and find out how dirty they really are. I don't know, but I suspect, that most of these people know they're involved in deeply fraudulent activity. A few racketeering convictions involving major ISPs, banks, spammers, and their business clients with some noisy investigation of other spammers could have a *real* impact -- squeezing the spammers out of ISP suppliers and banking services they literally can't do business without.
        • If nobody has gotten the government's attention with the obvious fact that the filter-cracking junk appended to spam is a perfect terrorist comm channel (you can't do traffic analysis on a signal that is going to practically everybody), what would it take to get their attention? Another 9-11 in which such a communication is one of the dots that were not connected?

    • Re:Sounds like a truly awful idea (Score:5, Insightful)

      by Chang ( 2714 ) * on Wednesday May 26, 2004 @11:18AM (#9259014)
      > 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.
    • The way I see it is that SPF and caller ID provide one service: they ensure that the From: header is "correct" in the sense that it really represents that user at that domain.

      My question is why we don't do this the same way we do it everywhere else: through authentication. If the would-be sender can't authenticate to the server (through PKI or password), they don't get to send mail. Now you know that when you get a mail from j.r.hacker@2600.com it was really someone who could authenticate to 2600.com as j.

    • Re:Sounds like a truly awful idea (Score:5, Informative)

      by FattMattP ( 86246 ) on Wednesday May 26, 2004 @11:25AM (#9259083) Homepage
      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.

    • 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.

    • isdnip says, among other things:

      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.

      I would think that it would not be hard, at all, to invent a sy
      • > forward it through your business's mail server.

        You're not reading the OP correctly. My business, like many small businesses, doesn't own a mail server. It owns a domain name, which works via a mail-forwarding service on mydomain. Outgoing mail goes via whatever ISP I happen to be on at the time; i.e., the one at home when I'm home, the one at the office when I'm at the office, or the one at the hotel when I'm at a hotel.

        My clients don't care where my mail originated. They know it's from me. I'm
    • > XML is hardly appropriate for a DNS function.

      I have to agree that *full* XML is inappropriate for DNS. Requiring an XML parser for all mail servers is undesirable (unless you're MS and have MSXML available as part of the platform).

      On the other hand, some kind of structured format is needed for the more complicated cases, which are currently badly served by SPF's somewhat clunky macro language.

      As someone who's written a complete XML parser I wouldn't wish such a thing on MTA authors. A reduced profil
    • 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 chan
    • This statement is simply wrong:

      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.

      I'll type out an example, to show you exactly how it is already working and rejecting forgeries TODAY, without being mandatory, and long before widespread implementation.

      Suppose your MTA receives a message from a spammer who is impersonating me. The message claims to be from "paul@pjrc.com", but it isn't. Your SPF

  • Lets hope they ditch the patent then. (Score:3, Interesting)

    by patthoyts ( 598899 ) on Wednesday May 26, 2004 @10:56AM (#9258793) Homepage
    having looked into doing an implementation of CallerID to add to an SPF parser -- I have come away with crossed eyes trying to work out if I'm allowed to release a BSD licensed implementation of this. I think maybe I can -- I'm pretty sure I can't release a GPL implementation though.

    Damn, now where did I put that lawyer....
  • ...in a comment I made here [slashdot.org].

    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.

  • SPF is harmful. Adopt it. (Score:2, Informative)

    by Anonymous Coward
    Check this article [tesco.net] for an interesting commentary on SPF.

  • Spam solution already exists (Score:5, Interesting)

    by Rashkae ( 59673 ) on Wednesday May 26, 2004 @11:09AM (#9258936) Homepage
    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.

    • Re:Spam solution already exists (Score:5, Insightful)

      by gclef ( 96311 ) on Wednesday May 26, 2004 @11:16AM (#9259002)
      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).


      • We've had 10 years to get signed email working, and it didn't happen.

        Huh. How long did it take to get internet email accepted as a commonly used service? How long for the telephone?
        • How long did it take to get internet email accepted as a commonly used service?

          Once people had access to it, signifigantly less than 10 years. Sure, email was around for a long time before it took off, but that's a function of access to the Internet, not a function of the usability or functionality of email.

          Email signing has been around for just as long easy access to email, if not longer. Once there was easy access to email, it took off in popularity. Email signing, which has been freely available


          • Once people had access to it, signifigantly less than 10 years. Sure, email was around for a long time before it took off, but that's a function of access to the Internet, not a function of the usability or functionality of email.

            It's also an issue of people realizing the need for something. Back in the 80's, I hadn't even heard of the Internet. But I did have access to FidoNet [fidonet.org]. I used email. I thought it was amazingly cool - even profound. Although my family and non-BBS friends had no idea what

      • Besides, how can you say it's failed for 10 years, when it was never *even* tried. Thunderbird is the first mainstream e-mail client I've installed that supports Encryption out of the box. But calling it mainstream is a stretch, and it doens't really include key management. If MS is serious about fighting spam and improving security, I think they should start with *Implementing* technology and standards that have been around for 10 years.
    • Good idea. Someone want to write up an RFC and submit it to the IETF?

    • it would stop even faster if all email servers simply had a rule that ignored any transfer requests from any machine that DID NOT have a Fully Qualified Domain entry and the top lever is not mail. or mail2. or mail3.

      users sending email send to the email server from INSIDE the provider's network and if you are a roaming road warrior then you are forced to use webmail or VPN into the network.

      this would solve a GOB of the problems and certianly stop all the emailing viruses.

      But we cant get most email provid
      • Well, I have to disagree with your proposal. I'm one of those stubborn bastards who sends mail through my own e-mail server.

        1) I really hate webmail.

        2) As the administrator for our small network, I prefer to have direct access to the e-mail server logs for security and verification purposes.

        3)Your suggestion would still not solve the spam problem.

        As annoying as the constant Viagra and porn ads are, not to mention offensive to some people, 3 years from now, those will be pleasant memories compared to wh

      • It would stop even faster if all email servers simply had a rule that ignored any transfer requests from any machine that DID NOT have a Fully Qualified Domain entry and the top lever is not mail. or mail2. or mail3.

        By extension, then, you figure if only ISP email servers could send mail, spam would be greatly reduced.

        Congratulations! You just explained why SPF is a good idea! The whole point of SPF is to point out which servers for a given domain are allowed to send email.

        if you are a roaming ro

    • if mail clients were configured to start using PGP (GPG) keys and signatures by default.

      If you reject messages without a PGP signature, spammers will simply sign their messages.

      If you reject based on the signing author being a known spammer, spammers will simply generate a new key for each message. This isn't a computational burden (as it is in PGP) if the keys aren't generated in a secure manner.

      If you reject all unknown senders, people unknown in your "web of trust" will be rejected.

      instruct unkn

  • IF the mailserver IPs have to be listed in the dns record of the from domain, then perhaps some records will contain hundreds of zombie hosts. Various parties would be interested in this information...

  • breaks forwarding (Score:5, Informative)

    by close_wait ( 697035 ) on Wednesday May 26, 2004 @11:13AM (#9258975)
    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...)

    • Re:breaks forwarding (Score:2, Insightful)

      by Anonymous Coward
      No it doesn't - SPF works on the _envelope_ headers and the fact that the forwarding machine is declared OK to send. Rewrite the envelope header (the one you never get to see in most mail clients) and make sure forwarding happens on a machine SPF-permitted for the rewritten address (or is routed via a mail gateway permitted by SPF).
  • ...since MS is part of it.

    I can only assume they'll eventually charge some sort of licensing of other kind of fee, and they'll force their way to approval to displace Yahoo's proposed system.

  • Caller ID (Score:2, Funny)

    by supe ( 163410 )
    WTF, I thought I owned the patent on that?

  • dynamic dns users (Score:5, Interesting)

    by tacocat ( 527354 ) <tallison1&twmi,rr,com> on Wednesday May 26, 2004 @11:40AM (#9259211)

    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...

    • Re:dynamic dns users (Score:5, Insightful)

      by ahodgson ( 74077 ) on Wednesday May 26, 2004 @11:58AM (#9259398)
      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.

  • XML ? (Score:2, Insightful)

    by defsdoor ( 737019 )
    Wasn't XML last century's buzz word ? The old saying that "when the only tool you have is a hammer - everything looks like a nail" seems totally appropriate.

  • What if. (Score:4, Interesting)

    by man_ls ( 248470 ) on Wednesday May 26, 2004 @11:59AM (#9259409)
    What if, say, businesses started showing up promising "unrestricted email" to get around SPF.

    They set their SPF to everyone/everyone...or something.

    Then it's an open relay with an SPF signature that matches.

    and we're back to square 1.

    • Re:What if. (Score:3, Interesting)

      by taustin ( 171655 )
      More likely is that spammers will take the doznes, or hundreds of domain names they register at a time now, and that they run their own DNS for now, and simply automate adding SPF records for, based on their current IP address.

      No "email for this domain is allowed to come from these machines" program that is under control of the domain owner has any hope of reducing spam, because spammers will just use it, and keep cycling through disposable domain names at $5-10 each. Only .mail solves that, and that's at
      • I take it you either don't operate a mail server, or you don't monitor it. At the present time, over 90% of the spam attempts against our servers come from open proxies around the world, most likely home machines that have been infected by SoBig, Netsky, or whatever worm-of-the-day is installing proxy software at the moment. The spam is coming with envelope senders not associated with spam, in general, because it's forged - heck, lately, nearly 5% of it is coming in with the envelope sender forged to match
  • Knowing microsoft, they're gunna toss this thing in there as an afterthought...much like real caller-id.

    In fact, how surprised would you be if it was just a 1200-baud half duplex signal leading every email?

  • AOL and MS say: publish SPF records (Score:5, Interesting)

    by wayne ( 1579 ) <wayne@schlitt.net> on Wednesday May 26, 2004 @12:50PM (#9259889) Homepage Journal
    AOL just added a webpage saying that you should publish SPF records if you want to be whitelisted with AOL [aol.com].

    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 [spf.pobox.com].

    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 [midwestcs.com] and the maintainer of the trusted-forwarder global whitelist [trusted-forwarder.org]. So, now you know why I have researched this stuff so much.)

  • Why XML is bad (Score:5, Insightful)

    by tacocat ( 527354 ) <tallison1&twmi,rr,com> on Wednesday May 26, 2004 @01:35PM (#9260389)

    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.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close