Slashdot is powered by your submissions, so send in your scoop

 


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

Spoofed From: Prevention 532

Posted by timothy from the web-of-trust dept.
An anonymous reader writes "It looks like the next promising advance in the war on spam is here! Introducing SPF: Sender Permitted From. A draft RFC is still being written, but the idea is simple: we can prevent forged emails by having domain owners publish a list of IP addresses authorized to send mail from their domain. It's no silver bullet, but how much spam can we eliminate by preventing forged mail from spoofed domains? Maybe we really don't need anti-spam legislation after all? The SPF site is chock-full of juicy info for our reading enjoyment. Bon appetit!" Interestingly, the to-do list mentions the possibility of seeking a defensive patent on this scheme, too.
This discussion has been archived. No new comments can be posted.

Spoofed From: Prevention More

Spoofed From: Prevention

Comments Filter:

  • great idea... (Score:4, Interesting)

    by AmigaAvenger ( 210519 ) on Sunday October 05, 2003 @08:19PM (#7140420) Journal
    Good idea, but the problem is the same as saying spam would go away if all the open relays were taken offline. In theory, it works great, in practice, there are admins who WANT spam moving...

    • Re:great idea... (Score:5, Insightful)

      by marnanel ( 98063 ) <slashdot@marnane ... inus threevowels> on Sunday October 05, 2003 @08:58PM (#7140647) Homepage Journal
      It doesn't solve the whole problem of spam, no. It's one possible way to deal with one particular aspect of the problem: forging From addresses will become harder. This is a major annoyance and it'd be good to have the hole closed.

      • This can already be done (Score:5, Interesting)

        by SuperBanana ( 662181 ) on Sunday October 05, 2003 @11:04PM (#7141312)
        It's one possible way to deal with one particular aspect of the problem: forging From addresses will become harder.

        ...something that can already be done with Postfix and other mailers. It's very simple. Postfix can check to see if the hostname you claim to be from matches your IP. It can also check to see if the IP reverses to the hostname you claimed(this one is not as wise, as there are perfectly valid reasons for not having a reverse entry, although you -should- have one). Further, Postfix can return not-authorized if you try and give a MAIL FROM address which doesn't match your domain; ie, if you're coming from a01.nastyspammer.com, you're not going to be able to say "MAIL FROM: niceguy@yahoo.com". It is -incredibly- effective against blocking spam, but the problem is that many ISPs and company just don't have properly configured mail servers, or hostnames set up for their mail servers(an even more common mistake is for the hostname to not match the name reported by the connecting server in the HELO command- most often Exchange servers). This would change quickly if more people configured their mail servers to block such shenanigans.

        Right now that RFC seems a)unnecessary and b)like a very thinly veiled attempt by ISPs to prevent their customers from running mailing lists and the like. I help run a VERY low budget mailing list that has about 3,000 subscribers in total, and we may end up using DSL again for connectivity. Said DSL provider could easily screw us over with this.

        • Re:This can already be done (Score:4, Interesting)

          by Robotech_Master ( 14247 ) * on Monday October 06, 2003 @12:10AM (#7141539) Homepage Journal
          And some of us have other reasons for spoofing our from addresses. For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me. It's neither my home Linux box, nor my local ISP. I keep it that way because I never know if I might need to change ISPs for some reasons, and that box is always up and always there. I use fetchmail to pull down my email.

          But as a matter of course, I have mutt configured on my desktop box to send in the name of my halfway-across-the-country account, even though it sends through my ISP's SMTP server. (It used to send through my home Linux box's own SMTP server, but then a lot of addresses started bouncing it because it was on a list of cablemodem IPs.) How would I be able to continue doing this under such a system?

          • Re:This can already be done (Score:4, Informative)

            by pjrc ( 134994 ) <paul@pjrc.com> on Monday October 06, 2003 @01:17AM (#7141703) Homepage Journal
            How would I be able to continue doing this under such a system?

            Two ways:

            1. List your IP number as a valid point of origin for that domain
            2. Do not list any IP numbers

            The "problem" (for you) occurs if you do not control the domain name, and whomever adds a list of valid sending IP addresses does not include the IP number you are using. In that case, you'd be out of luck.... but so will spammers.

        • That is, at the "MAIL FROM:" stage, my email server goes through most of the steps involved in sending a reply email back, to wit, finding a willing MX server, connecting to port 25 on it, falling back etc as you would normally do to send a reply, but do something like "MAIL FROM:id.3141592763@spamtest.mydomain.dom" when it came time to ID the sender. This will allow you to give positive responses to the other end if they in turn perform a similar check on you. If the SMTP process can't get up to "DATA" without a rejection of some kind, then the inbound mail is spam by definition. Either way, it then drops the connection so the return "mail" isn't delivered.

          Perhaps it could say DATA/If you receive this, your email server has been misconfigured./Please ask your system administrator or ISP to configure the server to discard incomplete email messages.// -pause- disconnect.

          That won't get them all, and there will be the odd false positive (550 unable to validate sender address), but it should get most, no worries. It'll certainly get the zillion or so messages spoofed as being from "@hotmail.com" "@yahoo.com" and so on. If you wanted to be a pedand, you'd check the embedded "From:" address as well as the enveloped one.

          I'd also appreciate some name-finding AI, so that when a message which programs like SpamAssassin become absolutely dead-set convinced is spam (ie, the filter doesn't say "maybe spam", the filter says "if this isn't spam, upload me to a microwave") arrives - but passes the above test - any email addresses mentioned in it get a score or so of vary different but realistic-looking "replies" based on the original message ("Re: P*E+N~I:S E|N-L=A/R'G\E!R/Dear Sexy Sal//Please send me four boxes of penis perpetration patches. My credit card number is 3141-5926-5358-9793 and expires on 04-04. My address is Australian Federal Police/Hay Street/East Perth 6001.//Please use plain brown wrapper on the parcel.//Fred Q Nurk esq") but from a variety of bit-bucket addresses and spread out over the next few hours. A bit sad if the spammer is spoofing from your address, but you can easily filter everything related to such spoofing - and otherwise forces the scumbags to work for their addresses. Even better if he wants to talk to a bot about invalid credit card numbers or mismatched expiry dates. Better still if you can arrange to get them done for credit card fraud, maybe by using numbers from your local supermarket's stolen-cards list. Working for their addresses is exactly what spammers don't want to do.

          You see, I've become convinced that a war of attrition - making it harder for spam to get through - isn't enough.

          The thing that makes spam work is that it's cheap to get addresses and cheap to send out mail. Since there will always be bad-apple ISPs (and dumbo-sucker ISPs) who let the canned-ham merchants send the stuff, the obvious step is to make collecting the addresses harder.

          Collecting addresses is a two-phase process. Phase one harvests addresses wholesale using spambots and/or people stupid enough to fill in random on-line forms accurately, phase two qualifies those addresses by sending stuff to them. Unfortunately, the same people stupid enough to fill in forms willy-nilly are the same people stupid enough to respond to spam. I guess it's just not a good survival characteristic.

          If it were possible to establish a contract by sending someone email, we could make the initial harvest very expensive, very quickly by simply embedding the email address in an offer of contract. Unfortunately, the courts have so far decreed that such an event doesn't necessarily entail a "meeting of minds" necessary to establish a contract - even if the email address says "email-to-this-address-costs-USD-1000-in-advance@m ydomain.dom". To me, this makes no sense, kind of analogous to releasing an automated tank and being able to claim that any damage done by it was not deliberate.

          Nevertheless, if we can make

        • This will prevent all mail spoofing. It wouldn't stop anyone from having a mailing list though, although you would A) need your own domain, or B) get your mailing list server authenticated by your ISP.

    • Another problem: (Score:3, Insightful)

      by BrokenHalo ( 565198 )
      I am a bit wary of that patent mentioned in the ToDo. I can forsee some ugly situations arising as a result of a select number of powerful corporations hijacking the protocol.

      I would be happier if he GPL'ed it.

      Actually, that brings something important to mind: Here in Australia a very large proportion of mail servers are Debian boxes. If that patent idea gets taken up, I can't see Debian including SPF; it'll be poison.

      • Re:Another problem: (Score:5, Informative)

        by Pharmboy ( 216950 ) on Sunday October 05, 2003 @09:15PM (#7140752) Journal
        Actually, that brings something important to mind: Here in Australia a very large proportion of mail servers are Debian boxes. If that patent idea gets taken up, I can't see Debian including SPF; it'll be poison.

        He refered to patenting it, and immediately releasing it as Public Domain. This means it can be used by anyone, in any license, even Microsoft. Actually, you NEED Microsoft to use it if you want it to work anyway. But there is already lots of PD in Linux, including Debian, so no worries.

      • Re:Another problem: (Score:5, Interesting)

        by qtp ( 461286 ) on Sunday October 05, 2003 @09:31PM (#7140864) Journal
        I am a bit wary of that patent mentioned in the ToDo.

        and

        I would be happier if he GPL'ed it.

        There is no reason that he couldn't distribute this under the GPL even if he patented it.

        The patent could be used as a method to could prevent a company from implementing an incompatible "one-off" that it distributed with it's own propietary, market dominating OS in order to prevent other systems from interoperating with it's email software when the feature is activated.

        On the other hand there is the issue of software patents in general. Even if you intend no harm, or are actually using the patent system to protect the freedom of your implementation, you are also endorsing software patents that are being used in far less benign ways.

        If that patent idea gets taken up, I can't see Debian including SPF; it'll be poison.

        Once again, the existance of the patent does not dictate how the patent holder distributes or licenses the patented invention. If this developer is concerned that this be widely implemented and thus chooses the GPL or similar to license the invention, the patent could ensure that any subsequent inventions that are dependant on or derived from this one be distributed under a similar or compatible license.

    • Think of the email virus/worm consequences... (Score:5, Insightful)

      by gladbach ( 527602 ) on Sunday October 05, 2003 @09:42PM (#7140916)
      This could do wonders... One of the ways that the latest email viruses/worms have been so effective, is that they tend now to randomly spoof the from lines after mining valid emails so that its harder to figure out *who* it is that is sending you the infected email.... If this system were globally in place, email worms like sobig and blaster would have never gotten as big as they did, so easily...

  • Won't work unless everyone implements this (Score:3, Insightful)

    by neonstz ( 79215 ) * on Sunday October 05, 2003 @08:21PM (#7140429) Homepage

    As far as I understood, unless everyone with a domain uses this, the spammers can just adjust their scripts/programs to just generate fake emails from domains without SPF. (or did I miss something?)

  • I don't like that idea. (Score:3, Insightful)

    by ixt ( 463433 ) on Sunday October 05, 2003 @08:21PM (#7140430)
    I have cable. I also run my own mail server. If that's implemented, then no mail server will receive my mail because my residential cable IP won't be allowed to send mail from my ISP's netblock. Thus we all need to pay just to run our mail domains, which is too expensive.
    • way too expensive? what is it up to, $4.95 /year at godaddy?
    • Er... do you have a domain already that's mapped to your home server? IF so, then you'll just have to publish your home IP as the proper one for your domain. If not, well, maybe free DNS services (such as Dyndns) will be set up so that they'll maintain a list of authorized IP's. Of course, this could be troublesome, since that would make these DNS services instantly targets of spammers who want to set up their own spamming systems. If neither of those two options work... what's wrong with using the SMTP o
      • It's a safe bet that dynamic DNS services will instantly pounce upon this as something worth paying for (and they'd be right). But more to the point, the problem with using your ISP's SMTP is that you generally have to be joeuser@isp.com instead of joeuser@joeuser.net. Don't know about you, but I want my From: line to use my domain, not the ISP's.
    • Or instead of probably violating your provider's Terms of Service by running a server (as I do too), you could just pony up the extra cash for a business account that will let you do anything you want.

      Hey man, I love abusing my cable connection too, but since I'm not willing to pay $100 instead of the $40 I'm paying now, I don't expect being able to do everything I want to.

    • I have cable. I also run my own mail server. If that's implemented, then no mail server will receive my mail because my residential cable IP won't be allowed to send mail from my ISP's netblock

      Not really. First, mail servers likely won't accept/reject mail solely on this criteria. This SPF compliance metric will just join many other anti-abuse metrics already employed.

      Second, if you run your domain there is no problem to begin with. The receiving mail server will look up your personal domain name and

    • Purchasing server from a provider does not imply in any way that, as a customer, you have a right to represent that provider in any form. They're providing a service to you: connectivity.

      One of the ways they do this is by providing inbound and outbound email services, through legitimate servers published through DNS. As a customer of the ISP, you're given rights to use those services, and they're responsible for ensuring your access to same -- that is, they're the responsible party for any given email a

    • I suspect you would still be able to send email through the smtp server of your cable provider. That way your cable provider can put filters in to trap any customer's spam mail.

    • Re:I don't like that idea. (Score:4, Interesting)

      by jhealy1024 ( 234388 ) on Sunday October 05, 2003 @09:11PM (#7140727)
      You're screwed already anyway....

      Many large ISPs (such as AOL) have already started filtering mail based on the IP of the relaying server. So if your SMTP server talks directly to AOL, then AOL may reject your mail simply because you're *likely* to be a spammer relay (even though you're not).

      Meanwhile, cable companies like Cox have already implemented a total blackhole on *outgoing* SMTP. Not only is this annoying for people who run servers, but it also sucks for those of us with POP/IMAP accounts... if I'm connected from home I have to set my outgoing SMTP to Cox, and when I come in to work I have to flip it back to my company's mail server. (I've since set up an automatic ssh tunnel to get around Cox, but the average joe has no hope of doing that for themselves.)

      Either way, this new idea isn't going to make sending mail from your own domain any harder than the cable companies are going to make it anyway...

      • Re:I don't like that idea. (Score:4, Interesting)

        by gregmac ( 629064 ) on Sunday October 05, 2003 @11:29PM (#7141403) Homepage
        Meanwhile, cable companies like Cox have already implemented a total blackhole on *outgoing* SMTP. Not only is this annoying for people who run servers, but it also sucks for those of us with POP/IMAP accounts... if I'm connected from home I have to set my outgoing SMTP to Cox, and when I come in to work I have to flip it back to my company's mail server.

        I've always thought that ISPs should add a default "smtp" zone for their customers that resolves to their mail server. That way, you can set your progarm up to use "smtp" and no matter where you are, it will resolve properly.

        Now, as far as blocking port 25, I've always thought that was a great idea as well, until last week. Our office has used BellZinc's DSL for connectivity. A few months ago, our smtp suddenly stopped working, and after calling tech support, they told me they had accidentally left port 25 on one of their racks unblocked (and I happened to be on that rack) so they had fixed the situation. (Actually, I had to call twice to find that out, the first guy had no clue whatsoever).

        So I switched the smtp server in the office to resolve to Bell's, and all was good. But we've had a few interruptions, espessially over the last couple weeks, where we couldn't send mail at all. After talking to tech, it turns out their mail server is being hammered by whatever virus-of-the-week was hitting windows, and was unusable. I was blown away by their lack of willing to help me: they wouldn't unblock port 25 for me (even to one specific IP), and they has no answers to "Well, what am I supposted to tell everyone in the office? No email for ... an unknown amount of time?"

        Of course, I could have just set up my server to accept mail on another port, but that would have been a pain for me - local change on every client, instead of one SMTP fix. Anyways, as of Monday, we have a new ISP. (I won't get into how Bell tried to tell us we had a 1-year contract and wanted to charge us 4 extra months for breaking. They couldn't send us any proof, but apparently it was a "verbal" contract. Wow.)

        Anyways, I'm a little mixed on blocking port 25. I don't know what a better solution would be. Perhaps not allowing a computer running Windows to directly connect to the internet. Or maybe monitoring the email sent, and setting either a limit on the number per day, or just watching for patterns of mass mailings.

    • I think this actually makes things better for you. Right now many DSL addresses are blacklisted, because they are major sources of spam. With this system, you can set up the name server from your domain to say that your DSL IP address is a valid relay for your domain, and then it should just work.

  • BAD Idea (Score:3, Insightful)

    by thedillybar ( 677116 ) on Sunday October 05, 2003 @08:21PM (#7140431)
    This is a BAD idea. What happens when I have 3 different email accounts that I use for different things, and I want to send mail from each of them from my home ISP? Sure, each email provider can provide a secure SMTP for me to log into, but this sounds like a lot of work.

    This is going to make a LOT of people's lives worse, and spammers will get around it anyway. After all...they can still send from another username@theirisp.com. The accounts they're sent from are garbage anyway, because many people notify the proper abuse@ based on the headers (as they should) and not the From address. Forging the from doesn't provide any cover for spammers anyway.

    • Re:BAD Idea (Score:5, Insightful)

      by sgifford ( 9982 ) <sgifford@suspectclass.com> on Sunday October 05, 2003 @08:29PM (#7140491) Homepage Journal

      Sure, each email provider can provide a secure SMTP for me to log into, but this sounds like a lot of work.

      Running a mail server is a lot of work; providing SSL and SMTP AUTH isn't much more.

      I'm not sure this would work very well, but having more ISPs support SSL and SMTP AUTH doesn't sound like a terrible thing even if it doesn't.

    • Re:BAD Idea (Score:3, Informative)

      by monsterlemon ( 713644 )
      > This is a BAD idea. What happens when I have 3
      > different email accounts that I use for different
      > things, and I want to send mail from each of them
      > from my home ISP? Sure, each email provider can
      > provide a secure SMTP for me to log into, but this
      > sounds like a lot of work.

      Actually it's a very good idea.

      A lot of work? For the ISPs? Or for you?

      Setting up an authenticated SMTP server is not hard, and the cost -- compared to the costs that ISPs are forced to incur to deliver spam, wou
    • You need to be using authenticated SMTP, regardless of who's responsible.

      If your provider is responsible for an email address, then they must provide you with a reasonable means of using their service to send mail, either by POP-validated SMTP or by authenticated SMTP.

      If you're responsible for an email address, then you have no excuse whatsoever not to be using authenticated SMTP. Repair your outgoing mail server immediately.

  • But *everyone* would have to do it (Score:3, Interesting)

    by doomdog ( 541990 ) on Sunday October 05, 2003 @08:21PM (#7140432)
    if you wanted this to succeed -- otherwise, you'd end up blocking mail from those domains that hadn't upgraded yet to the new techology... What are the chances of everyone upgrading at the same time? And how much mail would be lost during the transition?
    • There, is a difference between, it's registered and no one is allowed to send, and it's not registered at all (I haven't read the article or the RFC's, this is just the Engineer in me thinking of the obvious solution). I would say, that the default for a non-registered e-mail is to say: "E-mail can come from any IP in the world". Then people who get hit by nasty spoofing, will lookup how to deal with the problem. Come across a site the references this RFC, and will register. Thus, I believe you concern
      • > However, I have two concerns, I can't obviously solve. First, how widely distributed is this, and how much load can it afford to take? Clearly somebody who has an interest in anti-spam utilities not working has taken to DDos'ing them off the net. I'd be concerned about this.

        Well, if I understood right, before the mail gets accepted, a query is run from the DNS server. I would assume that if they did DDoS a DNS server, no mail would go through. Kinda sure that would qualify as a felony. And then w

    • Read the website. Everyone will *not* have to do it. Only those domain owners that want to restrict who is allowed to send email using their domains will have to add SPF DNS entries. Only those people who want to obey the requests of domain owners will have to check the SPF DNS entries.

  • Thumbs up (Score:3, Insightful)

    by Hamstaus ( 586402 ) on Sunday October 05, 2003 @08:23PM (#7140443) Homepage
    That seems like a really good idea. If the major MTA's adopted this and made it a part of the configuration files, then new installations would be easily configurable.

    If the big email services such as Hotmail and Yahoo adopted it, spammers would suddenly find that they have to spend more effort to send out spam by finding domains that didn't opt to use these rules. Even so, it would be a lot easier to filter a specific domain in China or Nigeria than worrying about every piece of mail from Hotmail.
  • http://www.tmda.net/

    Working wonders here.

  • There's another problem this could help with. (Score:3, Interesting)

    by rock_climbing_guy ( 630276 ) on Sunday October 05, 2003 @08:24PM (#7140451) Journal
    Although I would agree with the posters that this will not solve the problem of people who own a domain that they want spam sent from, let me point out something else.

    Perhaps this could stop spammers from spoofing the addresses of other internet users. However, I don't know if this will stop spammers from using whatever return address they want to regardless of what domain they send their spam from. Would it?

    • Presumably, the body responsible for the domain would be responsible for authenticating users to ensure that they are not spoofing before it comes out of their domain. Unfortunately, this would lead to even more ISPs taking the AOL-esque tactic of stopping anyone from setting up a mail server, forcing all outbound mail to pass through the ISP's servers.

      This would also cause serious problems for mobile users -- if I'm on the road, who knows what ISP I'll be connecting to. However, I probably want my From: address to stay the same no matter where I'm connected.

      This solution doesn't seem likely to make a serious dent in the flow of spam, and would likely add unwanted restrictions to the actions of users. As such, it seems unwise.
    • Maybe. If I put your email address on my spam, it would come back as good if someone queried your mail server. Your mail server would have to keep track of what it sent in order to validate properly.

  • pink contracts (Score:2, Insightful)

    by bob_calder ( 673103 )
    How can this help with so many pink contracts?
    Look at Bellsouth and OptIn.com for heaven's sake!
  • am considering taking out a defensive patent on this architecture for exactly one reason: I don't want to get sued for infringing someone else's patent, bogus or not. Patent it, then declare it public domain, and we sidestep a a quagmire of Intellectual Property issues. A patent will cost approx USD$10,000. If we can get ten major ISPs to contribute $1,000 each, we can jointly own the patent and guarantee there will be no legal liability. Contact me if you can help with this.
    Only in America do you have
    • Once a patent is taken out, the patent is good for 20 years. Period. The patent owner can state licenses will be available for no cost/no royalties, but that won't put it in the public domain. Once the time limit expires the patent will be in the public domain.

      The public domain means NO PROPERTY RIGHTS AT ALL exist. No copyright, no patent, no trade secret.
  • All one needs to do to defeat these schemes is set up a relay host that spoofs the originating exchange.

    STMP is inherently untrusted. You could simply claim that you don't accept relayed mail but wth, why even bother using STMP anymore if you do that..

  • not the perfect solution (Score:2, Insightful)

    by dhuv ( 241988 )
    the problem with this is the following, most users are told to use their isp as the relay for outgoing mail. this would mean that if the users travels somewhere else where their relaying server is not in the list of ips, their email would be marked as spam and be trashed.

    a solution like this would be all or none, either everyone uses it and follows those rules, or no one will use it.

    besides you now have to get all the people who own domains to get a list of ips together, not the most trivial thing for non
  • I have my own domain, and I send mail "from" it through my ISP's SMTP server which isn't remotely connected with my incoming server.

    So, that thing isn't gonna work for me.

  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Sunday October 05, 2003 @08:33PM (#7140514)
    Comment removed based on user account deletion

  • way too complicated... (Score:4, Insightful)

    by 3Suns ( 250606 ) on Sunday October 05, 2003 @08:33PM (#7140517) Homepage
    This seems WAY to complicated as an answer to a problem that's solved much better by PGP/GPG... Wouldn't it be smarter to get encryption and signing, a proven and implemented technology, merged into more email clients instead?

    • Re:way too complicated... (Score:3, Informative)

      by wayne ( 1579 )
      The SPF system is far less complicated than GPG in almost every way.

      That being said, the SPF system is not intended to be the only tool that will help create a more trustworthy mail system. I haven't heard anyone involved in the SPF system argue against using all appropriate tools.

      There is also the point that SPF is designed to help determine if someone is authorized to use a domain name, while GPG is designed to authenticate who is sending the email. These are different problems, so SPF and GPG comple

    • I'm having a hard time thinking of a system where PGP is the simpler solution.

  • RMX? (Score:4, Insightful)

    by Goonie ( 8651 ) * <.robert.merkel. .at. .benambra.org.> on Sunday October 05, 2003 @08:37PM (#7140536) Homepage
    Isn't this just like RMX [ietf.org]?

    If not, what are the key differences?

    • Re:RMX? (Score:3, Informative)

      by marnanel ( 98063 )

      Section 6.1 of their RFC [pobox.com] covers this.

      Briefly:

      RMX allows the recipient to look up information using a greater range of possible keys than just the sending IP address;

      SPF reuses a pre-existing part of the DNS (TXT records) rather than adding a new RR type as RMX does;

      the design of SPF lets the spoofed domain's admins know who's spoofing their address (because the spoofer's IP address is part of the lookup).

    • Re:RMX? (Score:5, Interesting)

      by wayne ( 1579 ) <wayne@schlitt.net> on Sunday October 05, 2003 @09:04PM (#7140677) Homepage Journal
      I have looked at quite a few of the various "designated sender" systems, and I think that the SPF system is by far the best thought out system. There is a reasonable good comparison of SPF vs RMX vs DMP [pobox.com] available on the SPF website.

      Basically, RMX has to critical flaws. First, it requires a new DNS resource record type, which is going to require everyone to upgrade their name servers if they want to use it. Secondly, there is a limit to how many resource records can be sent in a UDP packet and many important ISPs such as AOL, MSN, Yahoo, etc., have far to many. If I recall correctly, there are several thousand(!) IP addresses that Yahoo will send email from.

  • This will only make e-mail in general worse. First, I'm pretty sure spammers will find a way around it, so it'll probably end up useless before it's even widely implemented. The worst however, is that it prevents important legitimate use of e-mail: always sending e-mail with the same "From:" field regardless of where you are. A couple more "great ideas" like that and e-mail will end up being useless because everything will be restricted for spam reasons.
  • Simply, a federal law should be passed to disallow businesses from purchasing unsolicited email advertisement, which is the big chunk. You would still be allowed to send mail to previous customers, a la what Amazon does to make you aware of new products or services, but not to unknown parties. Those who break the law would be fined. Plain, simple.
  • I remember reading about this system "back in the day" when it was just a gleam in some nerd's eye. It is a good idea, from the perspective of protecting YOUR OWN domain from being abused. Doesn't mean you still won't get spam that abuses other domains that don't use this technology.

    As someone who hosts my sites from a dynamic IP address, I certainly hope this system can be dynamic-IP friendly... I would like to protect my own little domain as much as I can.
  • Hate to see what Hotmails DNS will look like with a few million: 1.7.168.192.in-addr._smtp_client.hotmail.com. TXT "spf=allow"
    entries in it . . .
  • One problem I see is one that I would run into. I have a domain somethingblah.com I use my ISP's mail server to send mail out, but I send it out from myself@somethingblah.com. This would result in all this e-mail being rejected... yes?

  • Not realistic, and not a complete solution. (Score:5, Insightful)

    by Elias Israel ( 182882 ) <eli@promanage-inc.com> on Sunday October 05, 2003 @09:02PM (#7140672)

    Yes, having information on which SMTP servers are the expected and typical mail "emitters" for a given domain would help reduce (not eliminate) spam.

    But the number of cases where users "forge" their from lines for perfectly innocent reasons is huge. Everyone here can probably think of a few cases. Here's one to get you started: "I'm working from home today about I don't want replies to my business email sent to my home account."

    Of course, they've covered that in their FAQ. Their answer boils down to: "Tough noogies. You have to suffer the inconvenience and change your behavior because I don't want to suffer the inconvenience of spam."

    This, alas, it typical of the disdainful, anti-user mentality that one finds in too many anti-spam efforts.

    Here's a clue: want an anti-spam solution to work? Then start from the idea that it needs to make the life of the end user easier, not harder.

    Of course, I'm biased. See my sig.

  • This still has the problem with mail relays and hosts not visable on the internet, just listing the IP address of good hosts isn't really good enough, IPs can be spoofed too. Servers need there own public/private key, every message they send on behalf of a domain is then signed with that key, relays don't touch the signing, but can still transfer the message, at the other end the signature is checked against the valid keys for that domain (which could be stored in the DNS or some other method). If the messa

  • *sigh* (Score:3, Insightful)

    by werdna ( 39029 ) on Sunday October 05, 2003 @09:06PM (#7140694) Journal
    Yes, this measure, by itself, will not remove all spam from the face of the Earth.

    Yes, this measure will operate to make e-mail somewhat less convenient and require authenticated SMTP servers and the like.

    But YES, Spam is awful and a serious problem, and if we wait for the silver bullet, we will accomplishn nothing ever at all.

    We need to take steps, a few at a time, that will help, a bit. Steps, a few a t a time, that will help a bit, even if it means some inconvenience.

    Eventually, the problem will be better.

    Eventually,m the problem will be much better.

    And maybe, the dollars will start moving to other ways to annoy us.
  • What about all the web hosting companies that suggest you use your isp's outgoing mail server for all your sending mail needs, even for accounts they provide? And what of the people who do their mail off of a dynamically allocated IP, such as from a DSL or Cable line.

    This assumes that all mail from a domain comes and goes from a central point of authority, but because of smtp's untrusted nature by design, people don't need to operate along those principles.

    The one way for this to work is for all of those
  • If mail can be decrypted with the public key, it was encrypted with the private key, hence not spoofed. If mail was not encrypted at all bounce it, explaining why.
  • The only thing I can imagine that would help against spam is something like the "web of trust", first used with PGP and GnuPG.

    Every mail server admin defines a list of people whom he trusts (those might also be institutions), and they delegate their trust further, with different levels.

    If spam appears, you kick the trusted person who is the first in the chain to the spammer from your side. He does the same, until the chain breaks ... the last one in the chain revokes his key, and that's it.

    Needless to

  • Interesting approach to the Essential Problem (Score:5, Interesting)

    by 87C751 ( 205250 ) <sdotNO@SPAMrant-central.com> on Sunday October 05, 2003 @09:39PM (#7140901) Homepage
    That problem, of course, is how to authenticate the entry point into the mail transport system. When the relay sequence is carried in-band, as with SMTP, spoofing the entry point is trivial. But even imagining an advanced system, where routing records are carried out of band and all relay points mutually authenticate, locking down the entry point is still a hard problem. If nothing else, Sam Spammer simply impersonates a server that's passing in-transit messages and forges the upstream transit records. Unless mail is redefined to be passed only by persistent hosts, the system has to allow for previous transit points to be offline except when actually passing traffic. That means authenticating back upstream won't always be possible, thus obscuring the forged transit records.

    Possibly, the system could require authentication all the way back to the message originator, but that implies some central repository of mail originator credentials (again, to allow for transient connections), which would have to be is-a-person credentials to be of any use in tracking and punishing spammers. Since TANSTAAFL, that means to send mail, you have to buy an admission pass for the network. That implies an infrastructure to issue and validate these credentials, as well as no provisions for unlinked mail nyms. Big Brother USPS, anyone?

    • I believe you have not understood how SPF works.

      Sam Spammer simply impersonates a server that's passing in-transit messages and forges the upstream transit records.

      Sam is going to have a very difficult time spoofing an IP address that is authorized for the sender address, because TCP requires at least one packet to travel from the destination back to the Sam Spammer before the TCP session is even established.

      Spoofing the DNS lookup the SPF uses is probably a weaker path, but also quite difficult for a

  • Web page defacer's delight (Score:4, Insightful)

    by QuantumG ( 50515 ) <qg@biodome.org> on Sunday October 05, 2003 @09:46PM (#7140938) Homepage Journal
    One unintended consequence of this that I see:

    What does this mean for the holders of vanity domains? Domain registrars that also provide DNS service will have to add a new field to their web configuration interfaces to allow customers to publish SPF lists; customers will have to figure out the IP address of their SMTP server, which could be their dialup/broadband ISP's SMTP server, or their own machine at home, in which case the web configuration interface should accept a dyndns-type hostname as well as a static IP address. Of course, if they choose not to participate in SPF, email will still work; it may simply be more likely to be scored as spam.

    Web sites on vanity domains are just the sort of thing people like to deface. But how to go about it? Usually there's so little chance that the owner of such a domain is going to be suckered by a mail bomb. Hmm.. what's this SPF record? Seems to point to the network where the owner of this domain connects up to.. that's useful.

  • what about ip6?? (Score:3, Insightful)

    by JDizzy ( 85499 ) on Sunday October 05, 2003 @10:00PM (#7141001) Homepage Journal
    from what i see into this, it is the notion of a white-list, which is advertised to the world. I duno, but I kinda like ot keep my white-list private if that is ok with you? Anyhoo... what about huge address spaces? I could be using ip6 one day, and how well would this scale up to something huge like that in years to come? Especially the large scale sites like hotmail, aol, yahoo, etc.. where users send email to all over the world.

  • Spammers *will* register with SPF (Score:4, Insightful)

    by po8 ( 187055 ) on Sunday October 05, 2003 @10:01PM (#7141007)

    The FAQ says...

    Throwaway Domains

    (From John Levine:) Or spammers can register throwaway domains of their own, since burning an $8 domain for a 10 million message spam run isn't much of a deterrent.

    Throwaway domains can be listed in sender blacklists which respond in real time to automated discovery methods.

    To which I can only add:

    Also, throwaway domains' neutron-flux reverse polarizer levels picophase technobabble shield reinforcers.

    Or is there something I'm missing here?

  • Travelling Mailman problem's solution's problem (Score:5, Insightful)

    by Todd Knarr ( 15451 ) on Sunday October 05, 2003 @10:12PM (#7141075) Homepage

    He mentions the Travelling Mailman problem, that of being able to use your home e-mail address while not on your home network. His solution, having your home mailserver use authentication so that you always send via it, has it's own problem. The problem is Windows malware that e-mails itself out. Several large ISPs have responded to this by prohibiting the use of any mailserver but their own from inside their network. This puts me in a quandry: I wouldn't be able to use my domain while on my ISP's (Cox Cable) network because SPF would reject it, and I can't use my domain's mailserver because my ISP won't let me connect to it. This is, IMHO, a fatal flaw in the scheme.

    • Traveling mailman problem:

      In this situation, wouldn't you just connect to the ISP's SMTP server and send the email? This system is designed to authenticate SMTP servers, not people connecting to them.

      Any mailserver internal to a network

      If your internal server tries to send email from reported to be from cox.net (or whatever their domain is) then yes, you'll have a problem. Don't do that.

      However, if you own mydomain.com, and have your SPF server report it's ip as an authoritative SMTP server for sendin

  • Verisign will assume they know better (Score:4, Funny)

    by ziegast ( 168305 ) on Sunday October 05, 2003 @10:13PM (#7141078) Homepage
    I can't wait to see this published by the GTLD servers:

    *.com. IN TXT "spf=deny"
    *.net. IN TXT "spf=deny"

    -ez

  • So the spammer just forges the source IP. (Score:3, Interesting)

    by nuckfuts ( 690967 ) on Sunday October 05, 2003 @11:48PM (#7141469)
    It's trivial to forge the source address of packets. You can even talk to remote computers this way if you can predict their ISN's and you don't care that replies won't get routed back to you. SMTP is a simple enough protocol that spammers could assume what the replies are and thus send mail from a faked address, something like... Connect to port 25 (Assume response was a ready message) helo somename (Assume some response) mail from fake@domain.com (Assume response is "Sender ok") rcpt to: somebody@somewhere.com (Assume response is "Recipient ok") ... So it seems the problem would just be changed to "are your sequence numbers predictable enough for a spammer to fake a TCP handshake on port 25"?

  • double edged sword (Score:3, Interesting)

    by xee ( 128376 ) * on Sunday October 05, 2003 @11:51PM (#7141479) Journal
    this could also help spammers. say a company publishes a list under this new recommendation. suppose their mail server is unsecured agains third party relaying. now the spammer has a list of valid domains they can use to bounce through the mail server. lets hope anyone smart enough to use this is also smart enough to secure their mail server.

  • two problems (Score:3, Interesting)

    by gunix ( 547717 ) on Sunday October 05, 2003 @11:53PM (#7141486)
    as I can see it.

    The *DSL user that has bought a domain foo.bar that is hosted on a server, somewhere in the world (that doesn't allow mail relaying). And this user want to send mail that originates from the foo.bar domain.
    Ehhh.. that user is screwed by this.

    And patent? Well, that will be very good for making it a technique that every MTA will use.... releasing it as Public Domain? Remember Rambus?

  • Do as I say, not as I do? (Score:3, Interesting)

    by wmshub ( 25291 ) on Monday October 06, 2003 @12:07AM (#7141529) Homepage Journal
    I signed up for their mailing list. Downloaded their perl test. Used it on their "welocome to the SPF mailing list message". The result:

    $ perl -MMail::SPF::Query -le 'print for Mail::SPF::Query->new(ipv4=>shift, sender=>shift)->result' 207.8.214.4 umbrella.listbox.com
    ...
    fail
    client umbrella.listbox.com[207.8.214.4] is not a designated mailer for domain of sender umbrella.listbox.com

    So apparently these guys don't have their own mailing list system set up to use their protocol properly? Or am I using their tool wrong? (I'm pretty much just typing in what the README gives).

  • What about... (Score:3, Funny)

    by SharpFang ( 651121 ) on Monday October 06, 2003 @03:36AM (#7142081) Homepage Journal
    adding obligatory header "x-spoofed-from" to email headers? Just like the new "evil bit" in TCP...

Slashdot Top Deals

Where there's a will, there's an Inheritance Tax.

Close