Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Communications Microsoft Spam

Microsoft Will Submit 'Caller ID' To The IETF 42

Posted by timothy from the who's-calling-please dept.
An anonymous reader submits "According to a recent mailing list post by Harry Katz who is the Program Manager of Exchange at Microsoft, they plan to submit MSFT's "Caller ID" proposal to the IETF: 'I want to inform members of the MARID working group that Microsoft will shortly be submitting the Caller ID for E-mail specification to the IETF as an Informational RFC. We request that the Caller ID specification be considered an input document to the working group's deliberations.'"
This discussion has been archived. No new comments can be posted.

Microsoft Will Submit 'Caller ID' To The IETF More

Microsoft Will Submit 'Caller ID' To The IETF

Comments Filter:

  • Obligatory note... (Score:2, Informative)

    by FooAtWFU ( 699187 )
    Obligatory notes: a) What about SPF? b) The name sucks! c) Licensing issues exist.

    • Re:Obligatory note... (Score:3, Informative)

      by .@. ( 21735 )
      a) SPF is being considered by the same working group. Rather, the means of authenticating senders via DNS that both SPF and Caller-ID propose are being considered by the same working group. Caller-ID, however, is more focused on RFC2822 headers, whereas the working group is learning towards RFC2821 headers in its initial product.

      b) "Caller-ID" is copyrighted, and will almost certainly not be used as a final name.

      c) True. However, the working group will not be choosing one approach from whole clo
      • I think folk need to take not of the fact that Microsoft is not merely submitting their scheme to the IETF group, they are working with the group and are very likely to accept the end product. This means that instead of us having six different RMX style proposals we will hopefully have one.

        As for the cost of certificates, it really depends on what you are doing. If you are an enterprise of any real size or an ISP you are already spending hundreds of $ per month talking your way off various blocklists, and

    • Re:Obligatory note... (Score:4, Interesting)

      by BrynM ( 217883 ) * on Tuesday April 20, 2004 @04:55AM (#8914390) Homepage Journal
      c) Licensing issues exist.
      From the MS License for this submission:
      If you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the
      following notice be prominently displayed in all copies and derivative works of your source code and in copies of the
      documentation and licenses associated with your Licensed Implementation:
      "This product may incorporate intellectual property owned by Microsoft Corporation. If you would like a license
      from Microsoft, you need to contact Microsoft directly."
      By including the above notice in a Licensed Implementation, you will be deemed to have accepted the terms and
      conditions of this license. You are not licensed to distribute a Licensed Implementation under license terms and
      conditions that prohibit the terms and conditions of this license.
      You are not licensed to sublicense or transfer your rights.
      Hungh? Does this section mean that everyone who implements this must notify Microsoft that they are using it? If you're "not licensed to distribute a Licensed Implementation", then does each end user have to check in with MS? If I write, say an e-mail class in PHP that can use this spec for my personal web site, do I have to notify MS?

      I may just be paranoid of the MS grab it all attitude, but I don't like the implications of this. Is this normal wording for such a license that involves Patented works in RFCs?

      • The very first phrase answers all of your questions about the license itself:

        If you distribute, license or sell a Licensed Implementation

        Does this section mean that everyone who implements this must notify Microsoft that they are using it?

        Only if you distribute, license, or sell it.

        If you're "not licensed to distribute a Licensed Implementation", then does each end user have to check in with MS?

        Since you're not licensed to distribute an implementation, you'd not supposed to have "end users" at al

  • As an RFC? (Score:4, Funny)

    by Anonymous Coward on Tuesday April 20, 2004 @01:31AM (#8913700)
    Good. I have a lot of comments; and while I'm glad they want to hear them, I think they'll regret it...

    (Oooh. Bad punning and Microsoft bashing in the same post...)

  • Please come up with something .. (Score:5, Funny)

    by naden ( 206984 ) on Tuesday April 20, 2004 @01:33AM (#8913702)
    As much as Microsoft can't be trusted .. i do hope many of the bigger companies/organisations do collaborate on some sort of standard.

    Because all I need to be happy in this world is to fulfil my one last dream in life.

    I won't go into it, but lets just say it involves a blowtorch, a pair of pliers and a tied up spammer.

  • Hope it won't be as bad as Caller ID (Score:5, Insightful)

    by Bishop923 ( 109840 ) on Tuesday April 20, 2004 @02:19AM (#8913853)
    I don't know about other areas, but around here 90% of the telemarketer calls show up on Caller ID as one of the following:
    "Out of the Area", "Private", or the state of origin. "Oh boy, someone in California is calling, that only narrows it down to 40 Million people..."

    Doubt this will be different, just a few extra bytes added to every E-Mail, clogging up the networks worse than before.

  • What is an Informational RFC (Score:5, Informative)

    by MerlynEmrys67 ( 583469 ) on Tuesday April 20, 2004 @02:31AM (#8913894)
    Well honestly the bar is pretty low.

    No blatant typos and grammer can't completely suck
    Can't break the internet
    Must show adherance to RFC 2026

    Yup - that is about it, so they get an informational RFC out of it. Who cares if no one in the world implements it. I would be worried if they were getting a standards track RFC that implies that people actually had to agree that it was the right thing to do.

  • Won't work (Score:4, Insightful)

    by ogre57 ( 632144 ) on Tuesday April 20, 2004 @04:12AM (#8914273)

    If this scheme were magically globally implemented today it would reduce email spam by 50% at most, and for a few weeks at best. I see zero reason to believe that one month from now the spam rate would be even 1% less than it was yesterday, especially considering this years virus fun so far. Nor will it reduce the CAN-SPAM oxymoron of "legitmate spam", eg attempts to sell the political candidates.

    With no reason to believe this RFC will accomplish even its purported intent no one sane will waste time and money to implement it. Expect the few morons who do to block more legit mail than spam.

  • "Microsoft believes that it has patent rights (patent(s) and/or pending applications(s)) that are necessary for you to license in order to make, sell, or distribute software programs that comply with one or more aspects of the Caller ID for E-mail Specification."

    That's from the callerid_license.pdf document on their Technical Specification page...

    True, it continues with:

    "Microsoft and its Affiliates hereby grant you ("Licensee") a fully paid, royalty-free, non-exclusive, worldwide license under Microsoft

    • After reading that through four times slowly, I read it as:

      You can use it only if you agree to let us use it however we want for free.

      ...with one extra comma thrown in between "provided" and "Licensee" for no other purpose than to obfuscate. This looks like a one-way version of the GPL to me. What am I missing here? IANAL, but I have read the GPL more than once, and I understand that MicroSoft rarely allows anything to slip past that does not benefit them in some way.

  • Man, what a hack.... (Score:5, Interesting)

    by brianjcain ( 622084 ) on Tuesday April 20, 2004 @09:01AM (#8915360) Journal
    If you're going to use a hack, why not use SPF? MS's hack doesn't look any better than SPF, from what I can tell. They both leverage reverse DNS lookups. All we need is for Sun, IBM, Oracle and SCO to develop their own DNS TXT-mail domain identity hacks.

    "Long e-mail policy documents. Larger organizations with more complex e-mail topologies may need longer e-mail policy documents. If your organization has a large e-mail policy document, please refer to the Caller-ID specification for information on how to split it up."

    This is stupid -- DNS shouldn't have to be twisted into knots to get this to work. These solutions seem to be the lazy way of getting things done: "Distribution of trust is too hard. But we already trust DNS, so let's just mess with DNS until it does what we want it to."

    How about a new version of smtp that signs emails using a trusted certificate (yes, I recognize that it's pretty unlikely that I'm the first to suggest this)? If browsers come with lists of trusted root certs, why can't SMTP daemons? Current SMTP servers can ignore the signature, and subsequent SMTP servers could use it as a cue to bypass spam filters (or skip directly to a "domain is known bad?" decision point).

    While MS is mucking with stuff, why don't they have Windows automagically generate a cert for someone's identity when a new user is created, and then include email signatures by default in Outlook/OE? Outlook and OE seem to handle S/MIME just about as well as Mozilla/TBird do.

    (Cue boilerplate "your solution to the problem of Spam sucks because of..." here).
    • Hey, dumbass, certificates cost money. Lots of money. If you want to pay through the ass to get every little e-mail server a certificate, then your idea is good. Otherwise, it's pretty stupid.

      If you generate your own certificates, then there isn't much point in having the system, right smartass? Or do you think spammers would have a problem with generating a new certificate for every batch of spam?
      • Hey, dumbass, certificates cost money. Lots of money.

        Verisign Class 1 Digital ID: $14.95 per year. [verisign.com] I'm sure with some shopping around you can find a better deal.

        Or there's the "web of trust" model.

      • Hey, dumbass, certificates cost money. Lots of money. If you want to pay through the ass to get every little e-mail server a certificate, then your idea is good. Otherwise, it's pretty stupid.

        Certificates do not cost much. I can understand individuals being hesitant to drop $15 or so per annum per domain, but for many businesses across the world (I'm going to guess they're among the largest consumers in email traffic) this is well worth the cost.

        If you generate your own certificates, then there is

    • While MS is mucking with stuff, why don't they have Windows automagically generate a cert for someone's identity when a new user is created, and then include email signatures by default in Outlook/OE? Outlook and OE seem to handle S/MIME just about as well as Mozilla/TBird do.

      I'm sure that spammers are using these products for their mass emailing instead of custom applications to obscure header information.

      The reduction of spam (solution is too optimistic) will likely come from a multiple solution app

      • I'm sure that spammers are using these products for their mass emailing instead of custom applications to obscure header information.

        Are you serious? I kinda doubt it. I'm almost positive that there are custom spammer apps (some probably do web spidering too). I don't think they use them solely for obscuring header info. Anyways, that's not the point. I'm not suggesting that spammers couldn't mimic S/MIME, because they absolutely could. But assuming message-signing became so prevalent that it was

        • I guess I should have double checked my posting. I was writing it in between other task at my desk. Started out as sarcasm but obviously ended up the wrong way. It should have read as you pointed out (that custom applications are used rather than the MS mail clients...my bad).
    • Certificates could work at nearly eliminatimg spam. The full infrastructure required in not currently in place though. Currently certificates are cheap and easy to get. Using (stolen) credit cards spammers could buy certs and basically spam as normal. To eliminate spam it is necessary to positively identify the originator of the spam. To achive that certificates would have to be harder to get. Certificate purchasers would have to provide positive proof of identification. Certificate issuers would have to st

  • What's so special about "CallerID" anyway? (Score:3, Interesting)

    by parvenu74 ( 310712 ) on Tuesday April 20, 2004 @09:06AM (#8915411)

    From the MS website:

    Caller ID for e-mail would verify that each e-mail message originates from the Internet domain it claims to come from.
    Given that email headers indicate the IP address of the originating email server, and the 'from address' indicated the alleged originating domain, isn't this already possible by means of a simple DNS lookup?

    Or is that CallerID really is under the hood and MS is trying to 'license' it to folks?

    (Amd with all the money MS has, can't they hire tech writers who know not to end a sentence with a preposition???)

  • Caller ID suffers from most of the same flaws that SPF does (and is only marginally better than the latter system).

    I find it phenomenally frusterating that the single company best positioned to provide the only real long-term fix -- a worldwide PKI/trust network via Outlook and Exchange -- is bound and determined to stick with another short-term hack.

    Worse, this is a short-term hack that produces pain-in-the-ass side effects that will be with us for decades.

    • Re:Caller ID a broken system (Score:5, Insightful)

      by base3 ( 539820 ) on Tuesday April 20, 2004 @10:01AM (#8916076)
      PKI? You're kidding, right? I am most decidedly not interested in paying a tithe (either directly, or via my ISP) to RSA, Verisign, Microsoft, or whoever the root CA would be in order to send email. I doubt too many other people are, either.
      • PKI? You're kidding, right? I am most decidedly not interested in paying a tithe (either directly, or via my ISP) to RSA, Verisign, Microsoft, or whoever the root CA would be in order to send email.

        Thawte has free personal certificates, and an interesting "Web of Trust" idea for e-mail certificates.

        • That would be useful on an individual basis, but I can't envision a way that certificates could be used at an SMTP server level to decided to accept or reject email in the absence of some kind of centralized authority. And I'd rather deal with spam with other tools (stopping the flow of money by denying merchant accounts to companies who advertise with spam, for example) than to do something that would inevitable result in "postage" for email.
      • I am most decidedly not interested in paying a tithe

        There's no need to do so.

        The fees on certs for, say, web servers are justified by reason of verifying a RL ID/key mapping. There's no need for this in simply ensuring the trustworthiness of a key owner not being a spammer.

        I mean, sure, it's possible to have commercial signers (among others). If Verisign wants to endorse your ID not being that of a spammer and charge $50 to do so, that's fine. But even in such a scenerio, I wouldn't expect signers to
        • But if you're going to trust mail servers based on their signing keys, and there's no central trust provider (e.g. a root CA), then you have to decide to trust each mail server yourself--and there are many, many mail servers. I suppose SPEWS or another current RBL provider could trust server keys, then you could transitively trust them, but the RBL provider will also want to be paid for that service.
          • No -- you can have many root trust providers. The leaf nodes of the trust network would be users -- each user would sign their emails, not each server signing emails sent through them. You would use transitive trust, as you've pointed out. The task of a root trust provider can be very simple -- there might be, say, one that does nothing but sign four certs -- say one for an association that signs a cert for all registered businesses in the United States, one that does so for an association that signs a c

  • Eliminate spam: Use GPG (Score:4, Insightful)

    by aminorex ( 141494 ) on Tuesday April 20, 2004 @12:28PM (#8918039) Homepage Journal
    I have *never* recieved a spam email which was
    encrypted with my public key.

    If GPG shipped with every email app out of the box,
    there would be no spam. It's free, it's here now.

    I will not read your unencrypted email.
    • This scheme works great if all your friends happen to be hopeless nerds. Unfortunately, some of mine aren't :).
      • It continues to work great even with clewless
        lusers, if the nerds get their butts in gear and
        make using GPG transparent and default.
        • It may help for a while until the spammers start harvesting public keys together with addresses. One of the reasons spam is so hard to fight is that many of us want to be able to receive mail from people we don't know. That means we need our e-mail addresses to be public, and in a GPG world we'd need our public keys to be public also. GPG can easily be integrated in spamming software...

          X.
      • I have no friends. I also (almost) never get spam or virii. My cousin started mailing me a lot one time, but I kept telling her to stop sending me all that aol shit until she finally did and I haven't heard from her since.

        Every now and then I get an email telling me I sent someone a virus, but those are always being returned from the "russian women" mailing list I was on a year ago. Since every person I contact gets their own "from address" at my domain, I never see third party spam. Either folks like ebay

Slashdot Top Deals

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

Close