Slashdot Mirror
Microsoft Will Submit 'Caller ID' To The IETF
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.'"
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...)
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.
Funtage Factor: Purple
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 cloth. Rather, it will be producing a DNS-based means of sender authentication, which other working groups will then build upon to produce a full-fledged mechanism, which may or may not be an existing mechanism, a combination of several, or something new.
.@.
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.
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.
I have mod points and I am not afraid to use them
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.
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?
US Democracy:The best person for the job (among These pre-selected choices...)
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).
From the MS website:
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???)
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.
One CPU cycle wasted on digital restrictions management is ONE TOO MANY.
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.
-I like my women like I like my tea: green-
This scheme works great if all your friends happen to be hopeless nerds. Unfortunately, some of mine aren't :).