Slashdot Mirror


IETF Approves SPF and Sender-ID

NW writes "According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards. It remains to be seen whether any of them will actually put a dent into spam." At the same time, the FTC has opened a central site about email authentication.

4 of 220 comments (clear)

  1. Not about spam, it's about joe-jobs. by khasim · · Score: 5, Informative

    Before the rush of posts about how this won't do anything about spam, this is not about spam. This is about stopping spammers from using your address which results in your email servers dealing with the mass of bounces and spam reports from clueless admins.

    Of course, only the admins with a clue will correctly implement either of these so ...

  2. It's one SMALL step by realmolo · · Score: 5, Interesting

    Both SPF and Sender-ID solve only one problem: faked sender domains.

    That's a problem that needs to be solved, but it doesn't account for a lot of spam, and spammers will just stop faking domains in their mass emails.

    What we need, and what will NEVER happen, is a central database of mailservers. If you aren't in the "registry" of legit mailservers, then other mailservers won't accept your mail. To get in the registry, you'd have to pay a fee, and prove that your server are secure, and that you aren't a spammer. Obviously, each "legit" server would have to append some kind of digital signature to outgoing emails, so that the verification coudl take place.

    In other words, a total revamp of the mail system protocols. ;) We can dream.

    1. Re:It's one SMALL step by bunnyman · · Score: 5, Funny

      This article advocates a

      ( ) technical (x) legislative ( ) market-based ( ) vigilante

      approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

      (x) Spammers can easily use it to harvest email addresses
      ( ) Mailing lists and other legitimate email uses would be affected
      ( ) No one will be able to find the guy or collect the money
      ( ) It is defenseless against brute force attacks
      (x) It will stop spam for two weeks and then we'll be stuck with it
      ( ) Users of email will not put up with it
      ( ) Microsoft will not put up with it
      ( ) The police will not put up with it
      ( ) Requires too much cooperation from spammers
      (x) Requires immediate total cooperation from everybody at once
      ( ) Many email users cannot afford to lose business or alienate potential employers
      ( ) Spammers don't care about invalid addresses in their lists
      ( ) Anyone could anonymously destroy anyone else's career or business

      Specifically, your plan fails to account for

      ( ) Laws expressly prohibiting it
      ( ) Lack of centrally controlling authority for email
      ( ) Open relays in foreign countries
      ( ) Ease of searching tiny alphanumeric address space of all email addresses
      (x) Asshats
      (x) Jurisdictional problems
      ( ) Unpopularity of weird new taxes
      ( ) Public reluctance to accept weird new forms of money
      ( ) Huge existing software investment in SMTP
      ( ) Susceptibility of protocols other than SMTP to attack
      ( ) Willingness of users to install OS patches received by email
      (x) Armies of worm riddled broadband-connected Windows boxes
      ( ) Eternal arms race involved in all filtering approaches
      (x) Extreme profitability of spam
      ( ) Joe jobs and/or identity theft
      (x) Technically illiterate politicians
      ( ) Extreme stupidity on the part of people who do business with spammers
      (x) Dishonesty on the part of spammers themselves
      ( ) Bandwidth costs that are unaffected by client filtering
      ( ) Outlook

      and the following philosophical objections may also apply:

      (x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
      ( ) Any scheme based on opt-out is unacceptable
      (x) SMTP headers should not be the subject of legislation
      ( ) Blacklists suck
      ( ) Whitelists suck
      ( ) We should be able to talk about Viagra without being censored
      ( ) Countermeasures should not involve wire fraud or credit card fraud
      ( ) Countermeasures should not involve sabotage of public networks
      (x) Countermeasures must work if phased in gradually
      ( ) Sending email should be free
      (x) Why should we have to trust you and your servers?
      ( ) Incompatiblity with open source or open source licenses
      ( ) Feel-good measures do nothing to solve the problem
      ( ) Temporary/one-time email addresses are cumbersome
      (x) I don't want the government reading my email
      ( ) Killing them that way is not slow and painful enough

      Furthermore, this is what I think about you:

      ( ) Sorry dude, but I don't think it would work.
      (x) This is a stupid idea, and you're a stupid person for suggesting it.

  3. There is no "Experimental Standard" by pyrrhonist · · Score: 5, Informative
    According to the records in the IETF's database (here and here), both the SPF and Sender-ID anti-spam proposals were tentatively approved by the IESG (the approval board of the IETF) as experimental standards.

    There is no such thing as an "experimental standard". The term "experimental" is a "non-standards track maturity level".

    See "The Internet Standards Process":

    Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor.

    Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense.

    The IETF has NOT approved either SPF or Sender-ID as an Internet Standard.

    --
    Show me on the doll where his noodly appendage touched you.