Microsoft Submits Email Caller ID to the IETF

NetWizard writes "Following on the heels of Yahoo submitting DomainKeys, Microsoft decided to submit their "Caller ID" anti-spam proposal as a draft to the IETF. This proposal tries to tie in IP addresses to the domain of the sender just like SPF does. To make things even more interesting, looks like SPF and MSFT's Caller-ID proposals are merging. On a related note, Yahoo submitted an IPR disclosure for DomainKeys to the IETF."

Comments

the origional

[millahtime]

Here is the origional

Re:the origional

[Anonymous Coward]

"Plan to submit" is not the same as "submitted." And the word is "original."

What this be detrimental to Linux in any way?

[Anonymous Coward]

What or coudl this be detrimental to Linux in any way?

Re:Hrm....

[Anonymous Coward]

When you run an email system that handles more email than hotmail and msn.com combined, then you can submit your own draft (get in line behind Yahoo and AOL).

Why XML ?

[Space cowboy]

First off - I'm a great fan of XML - as a configuration specification format, it's great and I love it. I don't however think it's the solution to every problem - the BIND format is inherently non-XML, why not (if the proposal is to specify outgoing nameservers in the same way as we currently specify incoming nameservers) simply have an MO (Outbound :-) tag with virtually the same semantics as an MX tag (obviously a different payload, though, in the same way as MS propose) ?

One of the reasons I love XML is that the configuration can later be extended without impacting on any parsers that only read version 1.0. Perhaps this *is* a good reason. Or perhaps it's a way of getting a standard out there that's easy to 'embrace and extend'. Paranoia? Perhaps.

I do think it's a nice idea though, and it will stop a lot of spam - it will also make it far more valuable to 'own' the mailserver, with all of the implications thereof...

Simon.

Re:Why XML ?

[freeze128]

Didn't Microsoft file a patent on XML a few months ago? This could be microsoft's way of leveraging everybody onto Exchange servers.
"Use Exchange or we'll claim patent infringment."

Re:Why XML ?

[nacturation]

One of the reasons I love XML is that the configuration can later be extended without impacting on any parsers that only read version 1.0. Perhaps this *is* a good reason. Or perhaps it's a way of getting a standard out there that's easy to 'embrace and extend'. Paranoia? Perhaps.

XML is great for extending *structured* data. I think you're right as far as DNS goes though... after all, coding for backwards compatibility in the current DNS format is as trivial as setting the server to ignore any unrecognized tags. Hey, just like XML!

Re:Why XML ?

[pyrotic]

SPF (Sender Permited From) is conceptually very similar to the MO mail outbound idea you're proposing. The syntax isn't very MX-like though. But as to having it XML - please no! I can't ever imagine having DNS info stored in XML, it's just bloated featuritis at its worst. It will mean having to upgrade MTAs and nameservers, and all the config rewriting, for no real immediate benefit.

See spf.pobox.com for more info on the SPF spec. God knows what it will look like after the changes they're working on with MS. Looks like changes to SMTP as well as DNS. Seeing as many people aren't even bothering to have reverse IP set up right, this could be a long time coming.

Re:Why XML ?

[Anonymous Coward]

But but it will be easier to write GUI DNS configuration tools.

Think of the newbies, you insensitive clod!

Re:Why XML ?

[PeeCee]

why not (if the proposal is to specify outgoing nameservers in the same way as we currently specify incoming nameservers) simply have an MO (Outbound :-) tag with virtually the same semantics as an MX tag

If I understood correctly, from the overview presented in the beginning of the IETF draft, it's because they want it to be as backward-compatible and quick to implement as possible. Adding a new tag would probably require supporting it in every nameserver and DNS client library, which would slow down and further complicate the adoption process. Using the pre-existing tag, only the relevant applications (MTAs, etc) need to be changed to use it. (Disclaimer: I am not giving an opinion on this design choice, I am merely clarifying with respect to what I understood from TFA).

Re:Hrm....

[AKnightCowboy]

As if Microsoft controlling virtually the entire desktop computer industry is not enough! Now they feel that they should control e-mail as well!

Maybe they feel kind of guilty since the majority of spam is relayed through trojaned windows boxes? :-)

Re:Hrm....

[epiphani]

I'll assume for the moment that you are being serious in your comments...

How does this imply microsoft control over the desktop? Its an IETF draft, publically availible. While microsoft might have incredibly "evil" buisness practices, not all of their technological developments are moot. Take DHCP for example - damn handy system, developed by microsoft.

This strikes me as one of microsofts better points.

How does this benefit Microsoft's bottom line?

[JessLeah]

Either in terms of money or market share?

They would not be doing it if it did not help them in one or both of those areas (and directly as opposed to indirectly, if at all possible)

Microsoft is not a charity. Even when they do give money to charity, they have reasons that have nothing to do with simple kindness.

Re:How does this benefit Microsoft's bottom line?

[spectecjr]

Either in terms of money or market share?

They would not be doing it if it did not help them in one or both of those areas (and directly as opposed to indirectly, if at all possible)

Microsoft is not a charity. Even when they do give money to charity, they have reasons that have nothing to do with simple kindness.

You're wrong. Sometimes they do things just because.

However, in this instance, they have MSN, Hotmail and Outlook. It'd be nice to have all of those services and apps spam free - it'd make their customers (who are complaining loudly about spam to them) happy.

Re:How does this benefit Microsoft's bottom line?

[the_2nd_coming]

oh, I don't now, maybe is savings from not paying for spamer's bandwidth?

Re:How does this benefit Microsoft's bottom line?

[sjb21043]

Lots of industry folks (MSFT, Dell, etc) have been reporting lately that a significant portion of their service calls come from either spam or spyware.

Cutting service costs will definitely help the bottom line.

Re:How does this benefit Microsoft's bottom line?

[platypibri]

If they solve the spam problem, what a huge PR boost for a company often accused to be overly agressive (Mike Rowe?). With Longhorn ever farther off, and SP2 for XP just meat thrown to ravenous dogs, they could use some positive press.

Re:How does this benefit Microsoft's bottom line?

[nacturation]

1. being able to filter out the bulk of incoming spam saves bandwidth, which costs money
2. potentially, they could offer this as a paid service
3. less abuse emails to wade through, meaning less support costs
4. Exchange Server upgrades to support this

etc. etc. The list goes on. Spam costs *everybody* money. Filtering it costs money. The ones that slip through cost money. Any way to reduce the amount of spam will directly add to Microsoft's bottom line even if you remove all revenue-generating aspects.

Re:How does this benefit Microsoft's bottom line?

[Trepalium]

Two ways, good will (positive PR) and cost reduction. Both can benefit the bottom line.

Re:How does this benefit Microsoft's bottom line?

[bergeron76]

Cutting service costs will definitely help the bottom line.

Particularly, when they have a very low cost capital outlay in the matter. If they were having to invest capital into this idea, they would easily tell the consumer where to stick it.

Re:How does this benefit Microsoft's bottom line?

[ShadowRage]

and to agree with you, and negate with the other response...
Microsoft gives out money or helps poor schools/communities for these reasons:
Stock pump
pushing the product out further
tax writeoff
license renewal 5 years down the road.

either way they win, and the people they "help" pay up or are mere pawns and arent helped too much at all.

Similarities

[swordboy]

I know that I'm just being stupid here but some history:

When callerID was invented, the phone companies were making money on two fronts: first, they charged consumers for the service (which eventually became free) and they charged telemarketters for an "Unknown" callerID listing. Money on two fronts.

It doesn't surprise me that Microsoft is behind this latest version of callerID for email. I'm sure that there's money in it for them somewhere.

Just kidding.

Re:Similarities

[Void_of_light]

I dont know about where you live but SBC charges almost 10 bucks a month to tell me who is calling.

Re:Similarities

[PCM2]

first, they charged consumers for the service (which eventually became free)

It did?

Re:Similarities

[DAldredge]

Sorry, but verizon charges about 8-10 per month to remove the software block that stops the caller id data from being transmited to my phone.

Re:Similarities

[the_2nd_coming]

but the difference is that we can easily block all mail that has an "Unknown" header

Re:Similarities

[Anonymous Coward]

Am I the only one who finds it ironic that telco Caller ID is easily spoofable? :)

Re:Similarities

[Zordak]

And then they sell telemarketers the privilege of having that software block selectively reinstated, and THEN (get ready to really feel used), they recently introduced a new "service" that identifies all callers (i.e., removes the selective blocking), which you can purchase for a nominal monthly fee. I hear the internal codename for this "service" is "Guido." Don't you feel safer with all this "Protection" they're offering you?

The real problem is proprietary ownership of this

[eric76]

What we really need is a solution that is completely non-proprietary. A solution that no one company has any ability to control.

Can you imagine what the network would be like today if Microsoft (or anyone else for that matter) had patents that allowed them absolute control over any of the common protocols (telnet, ftp, http, smtp, pop3, imap, ... )?

Re:Hrm....

[kemapa]

I'll assume for the moment that you are being serious in your comments...

Naw, I wasn't being serious, I was trying to be funny actually, but I failed evidently! I really did think the reference to "having a burger at Microsoft's" was funny though!

Why?

[burgburgburg]

It's usually obvious how Microsoft will benefit from an action. It isn't here. Other than controlling the direction of the solution in a way that won't surprise them and taking momentum away from others, what is the advantage to Microsoft in proposing their caller id as opposed to going forward with the solutions already out there?

The cynic in me is incapable of imagining that it is technical superiority that drives them.

Re:Why?

[taustin]

#1: They are patenting the idea.

#2: Their license is apparently not compatible with the GPF license.

If clueless idiots start blocking based on the lack of a Microsoft patented DNS record, you will not longer be able to use an open source mail server.

Step 3: Profit!

Microsoft certainly has plenty of underpants gnomes.

Re:Why?

[lkcl]

well going from previous experience, microsoft usually rolls out standards because they have an implementation which they're just about to release into beta.

so don't bother to attempt to report any problems with the proposal, because if you do, then microsoft will say "oh it's too late, we don't have time to fix that, we're going to have to ship with the broken protocol anyway".

at least, that's exactly what they did with the SMB protocol, just ... rolled over everyone and rolled them over.

Extend and destroy

[Smallpond]

Microsoft expects that when certain folks start needing new features
that are not expressible in v=spf1, they can publish their records
in XML and all the clients out there will be able to read those
records.

"certain folks" like Outlook developers, maybe?

Patent?

[Anonymous Coward]

I had thought MS maintained some kind of a patent on their "CallerID" method, which I recall is why it was recieved with a collective yawn when they originally discussed it.

Re:The real problem is proprietary ownership of th

[hpa]

Well, that's where the IETF comes in. Most Internet standards (or other standards for that matter) have been proposed by companies; that doesn't make them bad.

Note that the IPR filed by Yahoo is the clean kind: it says "we might have a patent on this, go ahead and use it for free as long as you don't sue us."

This pretty much translates to "keep some S.O.B. from trying to running this past the patent office's feeble checking and suing everyone."

How is this supposed to solve anything?

[KalvinB]

Spammers are just going to use a DNS server to tie the domain to the IP.

If I find an open relay in China I simply register a domain, use a DNS server (plenty of those around) to point the domain at the open relay and then fire away. This supposed "verification" is just going to check the domain and the domain is going to report that the IP is "legitimate."

For awhile I had linux.icarusindie.com pointing to the IP of MS's web-site and windows.icarusindie.com pointing to linux.org's IP.

MS's site fixes the url when you click a link on their site while linux.org kept my URL in the browser no matter where I went on the site.

Ben

Re:How is this supposed to solve anything?

[Smallpond]

That's fine. The goal of SPF is so you can't send mail claiming to be from paypal.com, or citibank.com. It isn't the end of all spam.

Re:How is this supposed to solve anything?

[the_2nd_coming]

it makes filtering spam easy.

Re:How is this supposed to solve anything?

[pjrc]

Spammers are just going to use a DNS server to tie the domain to the IP.

The registrars are going to love that, since domain blacklists will quickly list any new domain they register and use to spam.

Even at volume domain name pricing, it's going to add considerable expense and difficulty for spammers to constantly buy new domain names names... or reuse ones already on blacklists.

Of course, whitelists will also probably develop in response to widespread adoption of domain name authentication.

Re:How is this supposed to solve anything?

[thogard]

Spamers tend to take in $1000 to $10,000 for every bulk run they do. $20 extra in their costs is nothing. Remember the spamers con small businesses that pay them the money to send out the email. Its not the small businesses in most cases directly sending it, they just outsource thier marketing. In most cases they are told the mailing list is double opt-in.

Re:How is this supposed to solve anything?

[theCoder]

So would signing your email with GPG, but I don't see very many radical anti-spammers suggesting that. Because, you know, that's a simple solution that (a) can be gradually phased in, (b) doesn't require chaninging DNS, and (c) gives the end points of the network (the users) the power to decide what they want to do. No, much better to make the internals of the network smarter, because that's really more in line with the ideals of the Internet.

But as I've always said: "Spammers are evil -- they make email slow and hard to use and waste resources; radical anti-spammers are worse -- they actively try to destroy email for everyone else."

I sign all my email... why don't you?

Microsoft needs to merge with Taco Bell

[gphinch]

Because we all know that in the future, every restaurant is Taco Bell.

Re:Hrm....

[maelstrom]

Doing a 5 minute search on Google did not back up your claims that DHCP is a MS protocol. Please cite your sources else I'll believe it is a IETF standard.

DHCP was NOT developed at Microsoft

[hta]

From RFC 1531, the IETF definition of DHCP, authored by Ralph Droms, who was then at Bucknell University:

5. Acknowledgments

Greg Minshall, Leo McLaughlin and John Veizades have patiently contributed to the the design of DHCP through innumerable discussions, meetings and mail conversations. Jeff Mogul first proposed the client-server based model for DHCP. Steve Deering searched the various IP RFCs to put together the list of network parameters supplied by DHCP. Walt Wimer contributed a wealth of practical experience with BOOTP and wrote a document clarifying the behavior of BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail, pointing out several inconsistencies in earlier specifications of the protocol. Steve Alexander reviewed Walker's analysis and the fixes to the protocol based on Walker's work. And, of course, all the members of the Dynamic Host Configuration Working Group of the IETF have contributed to the design of the protocol through discussion and review of the protocol design.

DHCP was developed in the IETF. Microsoft was an early adopter.

Re:DHCP was NOT developed at Microsoft

[Anonymous Coward]

MOD parent up! +1 Informative
grandparent is smoking crack ;-)

Re:DHCP was NOT developed at Microsoft

[xanadu-xtroot.com]

MS an early adopter? You're kidding, right? Next you'll say NetBEUI was a good idea...

Oh, wait...

Re:Hrm....

[NanoGator]

"They've already taken a stab at the video game industry, remeber? "

So... you're afraid Microsoft will take over email, but you've already noticed they can't make a monopoly out of everything they touch. I can't tell if you're karma whoring or if you've written a rather amusing satire of the way a lot of people here on Slashdot behave.

Re:Hrm....

[Anonymous Coward]

Take DHCP for example - damn handy system, developed by microsoft.

I'm pretty sure that DHCP was just an update to bootp developed at a university.

Re:Hrm....

[Anonymous Coward]

How soon before I drive a Microsoft car or stop in for a burger at Microsoft's?

You mean McRosoft's? Or would that be MsRosoft? I can see it now...

me: I'd like 2 MsCheeseburgers and some MsFries please.

Spotty person at window: Would you like a MsCoke too?

Re:The real problem is proprietary ownership of th

[NanoGator]

"What we really need is a solution that is completely non-proprietary. A solution that no one company has any ability to control."

Call me cynical, but won't that mean 3 or 4 competing standards that nobody ever really relies on? There is such a thing as 'too much choice'.

Both implementations have problems.

[Anonymous Coward]

Both implementations have problems.

With Microsoft's, it's just a matter of spoofing IP addresses also.

Yahoo's idea is better, but it's worthless unless EVERYONE is using it. As long as there's one server out there not using it that you wish to receive e-mail from, you'll need to allow legacy e-mail, and thus spam through.

Re:Both implementations have problems.

[jbb999]

> With Microsoft's, it's just a matter of spoofing IP addresses also.

But luckily it's not possible to do that for tcp so that's ok.

Re:Both implementations have problems.

[YetAnotherDave]

>> yahoo...legacy email...

So I have my handy SpamAssassin give a healthy non-spam bonus to mail with the yahoo-version auth. The next spamassassin rev will do this by default for SPF.

Forget about having a single solution, focus on having a working system overall.

Re:Both implementations have problems.

[Smallpond]

DomainKeys is horrible. Not only do I have to do an extra DNS lookup on every mail message to get a key, I also have to do a cryptographic test. It adds no authentication better than SPF, since a spammer can generate cryptographic keys as easily as any other mail sender.

Re:Both implementations have problems.

[misleb]

With Microsoft's, it's just a matter of spoofing IP addresses also.

While technically possible, it is not practical. Spoofing TCP connections is tricky work not suitable for general use. In reality, it just doesn't happen much. Spoofing UDP and ICMP is common, but not TCP.

-matthew

Re:Both implementations have problems.

[Ars-Fartsica]

Not only do I have to do an extra DNS lookup on every mail message to get a key

Yes, because DNS requests are so expensive.

How many DNS lookups alone occur when you load the /. page?

I think you know enough to understand that DomainKeys uses DNS but not enough to understood that these lookups are inexpensive. A little knowledge is a dnagerous thing indeed.

Re:Both implementations have problems.

[Smallpond]

ps -e |colrm 1 13 |sort |tail -10
00:00:00 xinetd
00:00:01 named
00:00:01 sshd
00:00:01 X
00:00:03 gdmgreeter
00:00:03 kscand/Normal
00:00:04 init
00:00:05 named
00:00:37 named

Re:Both implementations have problems.

[tyldis]

With Microsoft's, it's just a matter of spoofing IP addresses also.

Any sane ISP block outgoing pakcets that does not match their IP pool. Spoofing is not a problem here. Besides, how would you go about with a TCP connection with the mailserver? You can't establish a spoofed TCP connection.

Re:Both implementations have problems.

[pdbaby]

Unfortunately ISPs tend not to drop non-them packets -- at least, not the ISPs in the UK that I know techs from.

They claim that it's too much work to update the list of their ips every time it changes (which, to be honest, I wouldn't think is very much)

More Anti-Microsoft FUD

[Rick and Roll]

All of the posts I see so far are ones complaining about Microsoft having control over it. This is an IETF standard they're proposing. Microsoft has not sued over Mono. As far as I can see, they're not going to.

Did it ever occur to you that Microsoft may be pushing for this because because they have some outstanding computer scientists working for them that want a name for themselves? Merging with SPF sounds like a great idea. The proposals will be inter-twined, and neither company will have absolute control over it. It will make Microsoft look good. That's all.

And even if Microsoft doesn't merge with SPF, would this be a bad thing? Some of you with tin-foil hats might think so. But I think to say Microsoft will make the servers reject e-mail from non-Microsoft servers is a little extreme. What will happen is there will either be a standard that everyone can use, or there will be more than one thing and servers will have to implement all of them, in it's e-mail verification process.

It seems like a lot of people who post here are from Red Hat.

By the way, I don't support mass adoption of C#, I would like to see the OSS community make their own bytecode environment that is comparable to Java. I do think Mono is a fine platform for developing OSS/Free software, though.

Re:More Anti-Microsoft FUD

[taustin]

All of the posts I see so far are ones complaining about Microsoft having control over it

Here's a compalint that has nothing to do with who proposes what:

This suffers from the same flaw as SPF. The records in question are controlled by the spammer, so it will do nothing to reduce spam. If anything, it will increase it. Spammers already cycle through dozens, even hundreds of domain names per month. All they need to do is add the necessary SPF/Caller ID domain records - which will be completely automated in their automated "sign up for hundreds of domain names at a time" scripting, and their spam will get whitelisted by anybody who swallows what is being spoon fed them by Microsoft or the people behind SPF.

Re:More Anti-Microsoft FUD

[Stevyn]

Are you kidding me? How can you be so naive? They're obviously trying to incorporate DRM into email. Do I have any evidence or basis for this claim? Well no, but then again do I really need any?

My guess is that if they get their way every time someone sends an email a penny will go right into Bill Gate's bank account. This will coincide with a baby seal being clubbed. Jeez, what's next? Corner the tin foil hat market? Then I'll really be up a creek without a paddle.

Face it, everytime microsoft does something, EVERYTIME, it's for purely evil purposes.

Another example I read in Tin-foil Hat Monthly is this time when Bill Gate$ was walking down the street and gave a homeless guy a few bucks. While this seems nice, he probably gave him a new DRM dollar bill and then this guy was later arrested when he tried to buy unlicensed coffee. Me thinks he's currently serving 6 years on the Microsoft Act of 2003.

Alright, well back to playing video games in my mom's house. I'll be back bitching next time microsoft does something.

Re:More Anti-Microsoft FUD

[Anonymous Coward]

Your new here arent you?

Re:More Anti-Microsoft FUD

[perlchild]

The fact that Microsoft hasn't sued over Mono is irrelevant. The fact that they legally can sue anyone over it, and have not, taken legal steps to remove their right to sue is.

The fact that Mono hasn't yet captured enough minds to justify the expense yet might be the likely cause they haven't sued, for that matter.

Think of this scenario:

You are medium-sized ISP example.com, you want to grow big, and offer a spam solution based on Microsoft's offering. The standard doesn't interoperate with the IETF's proposal. Fine you say, as long as you are a Medium ISP only, Microsoft doesn't sue you. The minute you sign up your 1000000th client, Microsoft sues you for a billion dollars. Did you do the right thing?

No, you should have expected this from Microsoft(they've done similar, yet not identical things, many times before). You deserve to lose your job.

Did Microsoft do anything particularly reprehensible? Not really, they've done worse, and only got a little slap on the wrist for it. Why should they stop?

P.S. I don't work for redhat, I'm self employed. I believe Microsoft already controls too much of I.T. and should forcefully lose that control, either by having to pay for it, or by giving it to other parties, so the IT world gets rebalanced again. I especially mind Microsoft's business model, because despite having been found in violation of trade laws, they still OWN the parts that were in violation.
It's like a huge dealer that gets caught smuggling cocaine into the USA on his boat, and the DEA seizes his boat, but leaves him his cocaine...

As much good as a software platform might be, I can't condone anyone using it unless there's some guarantee it won't increase Microsoft's control. This is principle, on my part, not business. You appear to have different motivations, more power to you.

Re:More Anti-Microsoft FUD

[Anonymous Coward]

If you don't absolutely *hate* Microsoft and
everything they *stand* for, you don't belong
here. Go away. I get enough Microsoft PR in
the magazines and newspapers.

Re:More Anti-Microsoft FUD

[pyrotic]

Usually DNS records take 24 hours for changes to propogate across the whole of the net. Some blacklists pickup spammers in the same kind of timeframe. So as a spammer, you'll have a very small window of opportunity from the moment your DNS records are valid to the moment you're on a distributed blacklist.

A lot of spam we see comes at work from people with no reverse IP address. I would dearly love to block all mail from sources without a proper DNS setup, but there are too many legit correspondents out there.

Greylisting is one solution we're looking at, where you give a temporary failure to incoming mail. Wait for a while, see if someone is still trying to send you that mail. If they are, chances are at least they're not a zombie ADSL PC.

If only the original authors of SMTP could have seen the mess we're in now.

Re:More Anti-Microsoft FUD

[pavon]

You misunderstand the purpose of SPF. It is not much of a solution in and of itself. It only garentees that email came from the domain it claims. The solitary benifits of this are small like you claim. However, once you have a garenteed method of tracking email back to a domain, you suddenly create the possibility for all sorts of measures.

Suppose spammers did set up SPF. If they follow the spam laws it is trivial to filter all their mail at the server. If they aren't, it is trivial to prove that they are breaking the law, and approach things that way. It is also now safe to blacklist them because you have proof that the incriminating spam came from them and wasn't forged. No more joe-jobs.

SPF lays the groundwork to make it useless to spam from dedicated servers, which is half of the total solution. The other half is dealing with hijacked machines. In my opinion the only solution here is to is get ISP's to start taking responcibility for firewalling hijacked machines from the network. When you sign up for a connection you either get their "home" line which they run a firewall on, and comes with mail etc. Or you get a "business" line that is static IP and is not allowed to use thier mail servers, so you are completely free and completely responsible for what you do with that IP.

Re:More Anti-Microsoft FUD

[taustin]

Suppose spammers did set up SPF.

Suppose spammers set up and SPF record for 0.0.0.0/0.

If they follow the spam laws it is trivial to filter all their mail at the server. If they aren't, it is trivial to prove that they are breaking the law

Suppose the spammer is using a DCHP IP address. Suppose the spammer is sending their spam through the corporate mail server at a major ISP (who let them, in a pink contract). Suppose the spammer is using trojaned machines in Europe and China, and other parts of the world where US law doesn't apply.

You've got nothing new. All these issues have been dealt with by spammers in the past, quite successfully.

SPF will have zero affect on the amount of spam being sent, and will most likely increase the amount being received, until mail admins figure it out.

Re:More Anti-Microsoft FUD

[taustin]

Usually DNS records take 24 hours for changes to propogate across the whole of the net.

Unless the spammer sets the TTL to, say, five minutes. You can override that, but there are hazards to doing so.

So as a spammer, you'll have a very small window of opportunity from the moment your DNS records are valid to the moment you're on a distributed blacklist.

About the same window of opportunity that they have with disposable dial-up accounts, which have been a standard spammer trick for years. At worst, they'll just register a hundred new domain names at a time instead of 50. Won't slow 'em down.

A lot of spam we see comes at work from people with no reverse IP address.

That is a valid and useful thing to block or filter on. I currently block any IP that sends me spam that has no rDNS.

Graylisting is at least more likely to stop spam than legitimate email, but it has its hazards, too. Not all mail servers are configured correctly.

If only the original authors of SMTP could have seen the mess we're in now.

The original authors of STMP would view trying to block spam as network damage, and built a protocol robust enough to handle it. They couldn't imagine what email has become.

Re:More Anti-Microsoft FUD

[Anonymous Coward]

If Mono is a fine platform for developing OSS/Free software; then YOU use it. I for one and many others don't see it being anywhere near free. Especially considering who's behind it. Hindsight is 20/20 and Microsoft as a corporation in and of itself has provided enough for a blind man to see what's down the road ahead.

Anyone who codes for fun and has a brain will not be using Mono in any serious capacity.

Re:More Anti-Microsoft FUD

[pr0c]

> If only the original authors of SMTP could > have seen the mess we're in now.

So ask Al Gore what he was thinking.. didn't he write the SMTP protocol right after the internet?
/joke

Re:More Anti-Microsoft FUD

[TaliesinWI]

Say it with me:

"SPF/Caller ID is not a 100% a spam prevention mechanism."

_ALL_ these two services do is verify that the E-mail in question is actually coming from the domain it claims it is. No more mails coming from a Chinese open relay that claim to be from Yahoo, and hence, no false bounces back to innocent sources.

If a spammer fires up a domain, publishes SPF records, and begins spamming away, you can pretty assuredly block that domain from your mail servers without worrying about stomping on anyone else. Plus the fact that a spammer will have to register a domain specifically to spam, and registrars are getting sticky about having legit contact information for domains, you now have an actual entity to track. If they steal a CC number to register the domain, they're committing a crime, etc.

It's not, by itself, going to stop spam. No one technology will. Use the right ones in combination and you can get your spam rate to practically zero with no false positives.

Re:More Anti-Microsoft FUD

[afidel]

Actually I think SPF will be FAR more valuable for curbing email born virus's then it will for curbing spam. As others have pointed out spammers can already register domains by the hundreds. The only kinds of spammers it will curb are the ones who use zombies to do their dirty work.

Re:More Anti-Microsoft FUD

[Openstandards.net]

I'm trying to understand why email I sent today to Compuware was rejected. It seemed to indicate that it didn't like that fact that the IP it communicated through resolved to a different domain than the IP it receives email on and identifies itself as.

I understand requiring that an IP resolve to a domain; but why do email servers reject it when this domain is different than the mail server?

This is a legitimate setup where an email server can connect through a proxied connection like any other internally initiated Internet communication. Another scenario is the initiation of a backup connection, where you can still send email, but perhaps can't receive it.

Separately, how are email servers that handle multiple domains impacted today? This means, they'll always send email for domains that are different than the mail server's domain, whether you resolve it through the mx record, or through reverse DNS.

I know one thing... I have experienced an unprecendented loss of business related email without any error notice. The only way I know is through phone conversations verifying that email was sent and not received. This applies to both incoming and outgoing email. Thus far, I have been able to receive incoming by telling the person to send it to me using a different account. I consider the restrictions on my mail server minimal, so usually presume they are having temporary DNS problems. Now, I'm not sure. It's clear that an seemingly obvious and simple restriction can have unintended consequences.

The pendulum is swinging to filter too much email today. Unfortunately, you can never know what you didn't receive, and cannot reasonably verify that all mail you sent was received. I have had to use the reliable phone a lot more because of the decreasing reliability of email communications.

Re:More Anti-Microsoft FUD

[Keeper]

Suppose spammers set up and SPF record for 0.0.0.0/0

No effect. Though I suspect you're trying to say "what if the spammers spoof the ip of a valid email server", which is an issue but not a large one due to the way sequence numbers are generated these days.

Suppose the spammer is using a DCHP IP address.

Also no effect. The spammer must send "mail" from an IP that is associated with the SPF record for the domain they are claiming to send mail from. In other words, this prevents spammers from sending mail which claims to be from domains they do not control.

Suppose the spammer is sending their spam through the corporate mail server at a major ISP (who let them, in a pink contract).

This in and of itself does not stop spam. It *does* make it one hell of a lot easier to filter it.

Suppose the spammer is using trojaned machines in Europe and China, and other parts of the world where US law doesn't apply.

This is the only real vulnerability left. This can be trumped by requring authentication before sending mail on an SMTP server (which is just a good idea period...). And if a certain domain has a problem with sending out spam, and you don't know anyone on that domain .. it's rather trivial to filter it out (per the previous point).

SPF will have zero affect on the amount of spam being sent, and will most likely increase the amount being received, until mail admins figure it out.

You seem to have a fundamental misunderstanding of what SPF is and how it works.

It is a mechanism to associate ips of valid mail senders for a domain name in the domain record. It is not a centrally managed list of ip's that are allowed to send mail for certain domains.

Re:More Anti-Microsoft FUD

[prshaw]

Just that in itself would cut my spam by about 75%. Seems like a worth while investment to me.

Re:More Anti-Microsoft FUD

[Malc]

It will do something to stop spam. Some spammers use other people's email addresses - I know, I've received batches of bounces on occasions. Some spam is from bounced MSFT Outlook email worms used forged froms taken from the victim's addressbook or inbox, which will also fail at the very beginning with this approach.

Re:More Anti-Microsoft FUD

[Vlad_the_Inhaler]

Starting at the back: If only the original authors of SMTP could have seen the mess we're in now: I don't know who they are, but suspect that they can.

My problem with this 'caller-id' stuff is completely different, and it is rather ironic that Microsoft is behind the proposal. An increasing amount of spam nowadays is coming from owned infected bots running Win2k or XP and on high-speed links. Ok, what happens if an owned bot sends off 10000 or more mails using a legitimate email address. If the email provider has a policy in place limiting the number of mails which may be sent, then that can be caught. I suppose we need all providers to adopt some kind of policy like this, although legitimate mailing-lists then get to be difficult for people who don't have their own email server.

Re:More Anti-Microsoft FUD

[Minna Kirai]

Microsoft has not sued over Mono. As far as I can see, they're not going to.

Why don't you think so? Suppose that Microsoft did want to kill Mono- if that were the case, they still wouldn't have sued yet.

The optimum procedure to sue a competitor for patent infringement is to wait as long as possible. That way the opposition wastes the maximum amount of investment on projects that you can legally stop them from deploying.

The chief example of this is the Polaroid-Kodak patent lawsuit. Polaroid waited until Kodak had spent multiple billions of dollars building new factories for instant-cameras before sueing to block them from selling any.

Re:More Anti-Microsoft FUD

[Doc Ruby]

Your post seems very naive. You trust M$ not to "embrace and extend" (hijack) email, once they dominate a standard they've developed as part of their new wave of DRM software. I don't trust them; I have no reason to, because they've destroyed that kind of trust in every way during our cotemporaneous 25 years in the computer industry. They'll start manipulating Mono when it suits them - just "not suing" is manipulation, as they retain control over a platform that's capturing lots of developers who otherwise have alternatives.

These "tinfoil hats" comments increasingly come from willfully ignorant people. Why paint as paranoid those who distrust criminal corporations like Microsoft? Especially when you then accuse Red Hat of astroturfing a discussion that clearly reflects the wisdom of a community that has rejected M$ flimflam in favor of diverse, constructive alternatives.

Of course!

[nizo]

This way, later on they can include an XML tag for windows boxes that says "this is good mail" whilst all other mailers won't have this tag, and will be seen as "this is evil mail" when opened with Outlook 2015. Then picture them patenting this idea of "secure" email.

Re:Of course!

[edoc]

". . . . . when opened with Outlook 2015"

What development plan are you looking at these features are surely not going to be available on such a quick schedule.

Re:Of course!

[nizo]

Rather than mod me down, please instead POST and clue me in on how good Microsoft is at playing well with open standards. Maybe take a gander at this first however.

Re:Hrm....

[FattMattP]

Take DHCP for example - damn handy system, developed by microsoft.

No, it wasn't.

Re:The real problem is proprietary ownership of th

[eric76]

Just one standard.

Microsoft, of course, follows their own non-standard, but they're going to do that anyway.

Re:Hrm....

[Anonymous Coward]

Take DHCP for example - damn handy system, developed by microsoft.

DHCP developed by Microsoft %-/ mwuahahahaHAHAHAHAHAHAHAHAAAAAAAAAAAAA
OK guys, give parent +1 funny

No Kidding...

[deadmongrel]

You might be right. This could take the same path as the "whitelist" feature(or whatever it was called). Look what happened to they they in-turn sold it to companies. Here's the previous story on /.

Re:Hrm....

[Anonymous Coward]

The Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF) created DHCP, and was derived from BootP. If you want to name an individual who can take a large chunk of the credit, name Ralph Droms, whom I believe work(s/ed) at Cisco.

Re:Hrm....

[edoc]

"I can't tell if you're karma whoring or if you've written a rather amusing satire of the way a lot of people here on Slashdot behave."

I for one have an excellent skill at detecting an attempt at karma whoring, and I can tell you without a doubt that this is one of them. By this I meant the post that you just finished reading.

Why Microsoft Wants This

[Anonymous Coward]

Microsoft cares about spam for a reason: Microsoft owns Hotmail. Any technology that helps get rid of spam increases the value and usefulness of e-mail overall. And if everyone uses e-mail more, then that includes Hotmail users. (If Hotmail can take advantage of some of these technologies before its competitors, then that doesn't hurt either.)

This isn't the only thing Microsoft is doing to combat spam. They have a number of PhD's working on the problem at MSR. For the web page of just one of them, see the following:

http://research.microsoft.com/~joshuago/

So relax! Microsoft realizes that improving the computing experience of their users is in their best interest. Fighting spam is just one way to do that.

Re:Why Microsoft Wants This

[Ianoo]

...and patenting those methods and licensing them in a way that is incompatible with the GPL is another way Microsoft wants to enhance computer users' experience: by making them move to Windows + Outlook!

Re:Why Microsoft Wants This

[Anonymous Coward]

One problem - the author of the proposal, Bob Atkinson, works for Exchange group not Hotmail.

Re:Why Microsoft Wants This

[Anonymous Coward]

Uh, No.

Actually, MSN/Hotmail generates a lot of spam for MS profit. One of the reasons richter was outed was his stupidity. He had a deal with with MSN that called for him for him to have access to User Lists and MSN IPs and some amount of bandwidth for which he paid 1M /month. Apparently, MS was going to up the rate to 5 Million / month, but offered him more bandwidth. Richter then went to qwest and tried to talk them into the deal. What he did not count on, is that qwest exec's are pretty much in bed with MS. Once the proposal went up (had to happen), the info was leaked back to MS. At that point, MS leaked the info to their good friends @ justice.

MS, Yahoo, and AOL make a LOT of money on selling userlists AND spam itself. Much of the traffic that people think they have from china, was easily spoofed right at AOL, Yahoo, and MSN. So you do not believe it? Register with an address at Yahoo business group and watch it get spammed. (also check up the stream and see where the packets really come from; not where you think). the same is true of MSN and AOL

Finally, MS does nothing for free and nothing short-term. they are always thinking how to leverage their software and create monopolies. As it is, they are getting nervous (did anybody notice that MS cut back on benifits to employees?). MS will be trying to create as many new monopolies as possible.

Personally, I say give the wooden horse back. It most likely has hidden attacks when you least suspect it.

How long...

[manavendra]

..before Microsoft releases a train of patches that exploit a vulnerability that allows the attacker to gain complete control over the host machine? And then how many more such patches every month?...

Ooh, just can't wait to find out...

Why not digital signature

[Anonymous Coward]

Instead of domains having to publish outgoing dns servers and update on continuous basis, why not just use digital signatures.

Let us say I am a small businessman and have a domain registered dsfkghsdfk.com. which is hosted by some well known firm hosting.com. The email that I send will contain hosting.com's digital signature (since I am a small businessman and I don't have certificate and public key). Now the recipient will see

From user@dsfkghsdfk.com
X-authenticated-by: hosting.com

The recipient email system can decide whether to consider this as a spam or not.

All mail gateway, relay, smtp server and everything in between need not be changed.

Re:Why not digital signature

[Openstandards.net]

And what Certificate Authorities (CA) will your email server consider acceptable? The problem is that certificates cost hundreds of dollars a year because they are commercially controlled by a few CAs (e.g., Verisign). Why should people have to shell out $150/yr just to run an email server? It's bad enough to have to do it in order to use SSL on websites without the user getting a prompt "warning them".

This whole CA thing is out-of-wack IMHO. We need free CA's that can accomplish the same goal, namely verifying the integrity of part of certificate information. The theory is that if you used a credit card to purchase the certificate, then at least the info relating to your CC is valid. So, how do we fund free or low cost CA's and how do they verify that you do legally exist and are reachable via valid contact information?

It is possible, and much more feasible, to simply use public keys without digital cretificates. This is the old fashioned approach where the host itself verifies its own signatures. Hosts can verify they actually sent the email.

I'm not sure what this accomplishes though. If a PC is infected to become a spam bot, then why wouldn't its SMTP server sign its outgoing messages? How does it know that one of its clients is infected? And, if it signs the messages, then receiving email servers will validate the signature without a problem. Thus, spam will still get through because it is coming from a trusted client through a trusted SMTP server.

Re:Why not digital signature

[MavEtJu]

Why should people have to shell out $150/yr just to run an email server?

Or have to buy two certificates, one for the incoming mail and one for the outgoing mail (yes, you can't use server certificates for outgoing mail).

Re:Why not digital signature

[pjrc]

Crypto-based signatures are really good at answering the question "is this message truely from the claimed sender?" That's nice to know for many applications, like on-line banking, submitting payment information to a merchant, and so on. Saddly, the answer to that question isn't very useful for filtering out spam and other junk.

The important question is "is this message almost certainly forged". Signature checking can tell if that is _might_ be forged (the signature was missing or didn't match)... but unless you're among a very small minority of anti-spam activists, what you definately don't want is a "false positive" that accidentally filters out legitimate messages.

For crypto to be useful in filtering out junk, many things all have to work perfectly. You have to be absolutely certain that the claimed sender transmits ALL outgoing messages with valid signatures (high cost to implement, especially for large organizations with many servers). The signed portion of the message must not be modified by buggy servers or communications. You have to be able to get the public key. The sender has to manage their keys properly (keep expired ones around for delayed checks, keep the private key secret, properly update them as needed, and so on). If any of these things are less than highly reliable, the result is the signature does not match on an otherwise valid message.

Re:Why not digital signature

[Anonymous Coward]

Because not even SpamCop's people will give you the time of day if you bring up such a proposal!

They hit you with 'not invented here', 'who would trust us' etc, etc. .. and they are not the only ones!

_You write to your email provider and ask them about this and I bet you a k that you too will get the run-around.

Seems the powers that deny you anon access to anon mail servers (no accessing hushmail through anonymizer etc) are not looking to fondly at anything supporting pki ... underhandedly pushing a silly commercial infrastructure on us.

Even sane proposals such as that by the good dr (educate yourself if you dont know about 'single store with receiver notifications') which would require infrastructure adjustements just the same (but without the commercial tie-in) don't seem to go anywhere.

123

Re:Why not digital signature

[zoloto]

instead of some cert authority, how about just use PKI on the server level. You get the email with the digital signature of that particular server, that servers public key is available via a mesh network of keyservers, then you only accept from people on your whitelist, and only from those on your whitelist.

just my knee-jerk reaction.

Good for Microsoft!

[Mustang Matt]

I say let them do whatever they want.

If nothing else it will encourage us to come up with our own standard that's open and better.

Re:Good for Microsoft!

[Daltorak]

That's the great thing about standards -- there are so many to choose from!

PATENTS?

[IGnatius T Foobar]

Doesn't Microsoft hold a patent on their 'Caller ID for email' specification? Are they dedicating the patent as part of their submission of this spec to the IETF?

Or is this Microsoft's attempt to not-so-subtly obtain a lock-in on email?

This question must be VERY CLEARLY answered before anyone moves forward.

Re:PATENTS?

[thogard]

Of course they have a patent on it. And even if they agree not to charge for it, they can always revoke the license later or sell it to someone who does. They will use this to get more people to move back to their server software.

Re:My list of reasons why this should not be adopt

[Kryxan]

I really don't like microsoft either, but just because they make something doesn't mean it's not worth getting.
Take a look at the Xbox, its the best gaming console currently on the market. Sure it doesnt have as many games as PS2, but the PS2 gets more games because it already has its nitch in the market because it was out for over a year before the Xbox.
Yeah windows does have its problems, but would computers be as widely used as they are now without it? I highly doubt it; If not for windows computers would still be mostly a geek and business thing. Yeah Linux is great, but its not very good for being user friendly.
Everything from microsoft is a lot like other software in that it has bugs, even some major flaws, but it has a clean look, and it gets the job done (most of the time). They don't make the best software out there, but they get that clean look down so thats why they are so wealthy, but is that any reason to hate them?

Extensibility

[Anonymous Coward]

I don't extensibility is really all that good a reason for choosing XML. I mean, why not just use something simple like LISP s-expressions? Surely they would be sufficient for something like this and avoid the complixities of writing/parsing the XML.

Re:My list of reasons why this should not be adopt

[techno-vampire]

Yeah Linux is great, but its not very good for being user friendly.

Linux is very user friendly. It's also very fussy about who it makes friends with.

Just because M$ profits does not mean

[Archfeld]

every one else can't as well. I 'trust' an entity will an obvious reason for their behavior, ie profit, much more than I trust a so called altruistic entity, fanatics are SCARY.

Not to say that there is not cause for concern or need for extreme watchfullness but a stable net profits everyone, reducing spam to a manageable level in which a bulk nugget might even catch the light is profitable to everyone concerned, even the legit bulk mailers. I think the answer is to build an authenticated mail infrastucture at the tier-1 peering level, working with the DNS managers, and system and provide link points to the existing system...You could receive authenticated mail from a validated sender, marked as such, and continue to receive un-authenticated mail should you choose to. Gradually legitimate sources will migrate to the authenticated side, if it is worth snot that is, and the 'evil' spammers will be left dishing traffic that can be ignored or dealt with as user/provider see's fit. Much like they have done with news feeds today. The key issue I think if a wild user land style net is to survive, is to both let and force the businessess to assume much of the burden of the infrastructure and deal with the costs behind the scene. IE the big banks and VISA to make and provide a financial network, and allow vendors to establish a presence at their expense. Their motives are crystal clear, they are federally regulated on the use and disclosure of information, and they have a relatively good track record on security. I'd trust a bank or a casino to manage security and money long before I'd trust the government or another private interest. The thought of the UN managing somthing like that scares me silly, they'd decide it was in our best interest and for humanity as a whole to be 'gattica' marked or somthing equally pernicious. Oh well Cheers all and TGIF :)

Salute to the Flames, MY HATS OFF AND HEART STILL WITH THE SHARKS, way to go guys, next season !!!
5 year season ticket holder and true believer

Re:Just because M$ profits does not mean

[JessLeah]

So I guess you don't trust RMS, since he's just a "so-called altruistic" person...

XML good. For some things.

[MrChuck]

the BIND format is inherently non-XML

which might be part of why there are SO FEW good managers for named (the binary via the config file) and DNS (the data within zones). There are things that WANT to do it, but they are few and far between.

Me? I find that XML is often a hammer and oh, look at all the nails! This one is a nail.

Mostly, you're right. It's GREAT for many config files. It's easy to parse, it's non-binary, the structure is self describing and it's EASY to present forms for managing something via web or curses or GUI.

And that's a win.
I'm tired of writing tools where each tool has to be intimate with the details of a config file and application. I'd rather be familiar with the DTD and use the "meta data" available. It doesn't make apps automatic, but it sure makes it easier to manage them.
A stylesheet can easily convert managable XML data file into an inetd.conf file. (trivially easily).

And perl/php/java can easily read in and write out XML files. My program just has to deal with the data structure that's been read in.

Now, that said... XML is wordy and large.
DNS (not BIND, DNS) struggles with large anyway. It's an ugly ugly hack/misuse to shove XML into several TXT records. Anyone remember trying to get PGP keys into DNS? We should it would be a great way to distribute them at least internally (where we controlled all the DNS servers). But TXT records won't HOLD a 1200 character blob.

Doh!

Again, we're looking for an LDAP type solution or at least in need of some infrastructure tools beyond DNS's hostfile replacement capabilities.

If only they'd set their bloody HELO/EHLO properly

[Zey]

Yet life would be so much simpler if all those Microsoft Winders boxes were identifying themselves properly in SMTP connections by using HELO/EHLO with fully-qualified domain names with working forward and reverse-lookups.

Seems to be the Microsoft way though. Fuck up the implimentation of a simple protocol and introduce an absurd and obtuse replacement.

q-Stal is the answer. Look into it.

[Giant Panda]

First off - I'm a great fan of q-STAL - as a configuration specification format, it's great and I love it. I don't however think it's the solution to every problem - the BIND format is inherently non- q-STAL, why not (if the proposal is to specify outgoing name-servers in the same way as we currently specify incoming name-servers) simply have an MO (Outbound :-) tag with virtually the same semantics as an MX tag (obviously a different payload, though, in the same way as MS propose) ? One of the reasons I love q-STAL is that the configuration can later be extended without impacting on any parsers that only read version 1.0. Perhaps this *is* a good reason. Or perhaps it's a way of getting a standard out there that's easy to 'embrace and extend'. Paranoia? Perhaps. I do think it's a nice idea though, and it will stop a lot of spam - it will also make it far more valuable to 'own' the mailserver, with all of the implications thereof...

Re:q-Stal is the answer. Look into it.

[Anonymous Coward]

This sure seems alot like sed s/XML/q-stal/g from
http://slashdot.org/comments.pl?sid=108454&c id=922 0535

this is all good, but what will it cost me?

[hawkbug]

What I mean is - what it will cost me to upgrade to Exchange XX so that I can use these new features on my mail server at work? For my linux mail servers, no prob - I'll just upgrade to the latest version of sendmail when it supports these new spam fighting features. But, I have a feeling if my company were to purchase Exchange 2k3 right now, we'd just have to buy the next version that has all this built in. Damn closed, non-free software.

GPF license ?

[Animaether]

You're posting to Slashdot.. don't you mean the Kernel Panic license ?

Re:Hrm....

[Anonymous Coward]

Microsoft feel guilty?

You must be new here!!

Patents?

[MrChuck]

Er, no. Not "on XML" but on their SCHEMAE - their USE of XML. Their data format within XML. Google for "patent xml microsoft" and wait 3 seconds.

To steal from a news.com.com.com.com.com site The proposed patents apparently seek to protect methods other applications could use to interpret the XML dialect, or schema, Office uses to describe and organize information in documents. Microsoft recently agreed to publish those schemas and is looking at opening other chunks of Office code.

XML, basically, allows you to define your own "language" within it. That language is what they are endeavoring to patent. Which is just annoying. And off topic.

Re:The real problem is proprietary ownership of th

[_Sprocket_]

Well, that's where the IETF comes in. Most Internet standards (or other standards for that matter) have been proposed by companies; that doesn't make them bad.

From http://www.openbsd.org/lyrics.html:

The IETF community proposed work in this direction in the late 90's, however in 1997 Cisco informed them that they believed some of Cisco's patents covered the proposed IETF VRRP (Virtual Router Redundancy Protocol); on March 20, 1998 they went further and specifically named their HSRP "Hot Standby Router Protocol" patent. Reputedly, they were upset that IETF had not simply adopted the flawed HSRP protocol as the standard solution for this problem. Despite this legal pressure, the IETF community forged ahead and published VRRP as a standard even though there was a patent in the space. Why? There was much deliberation at all levels of the IETF, and unfortunately for all of us the politicians within eventually decided to allow patented technology in standards -- as long as the patented technology is licensed under RAND (Reasonable And Non Discriminatory) terms. As free software programmers, we therefore find ourselves in the position that these RAND standards must not be implemented by us, and we must deviate from the standard. We find all this rather Unreasonable and Discriminatory and we *will* design competing protocols. Some standards organization, eh?

Keep email simple and platform independant.

[iamcf13]

Read about it here.

Me: http://www.cf13.com/ Slashdot: Not newsworthy. You decide. PS: Read first before emailing me.
(Because if you violate CF13's email policy, your email WILL be treated as spam and processed as such.)

Re:Keep email simple and platform independant.

[olden]

iamcf13: "Me: http://www.cf13.com/ Slashdot: Not newsworthy. You decide."
Thank you for letting me choose! Your Highness is too good!

Seriously iamcf13/Bryan, I hope I won't offend you in saying that, but the solutions you present as new, effective and/or unobtrusive are IMHO anything but.
Examples:
- "Relayed email is not accepted.": decision based on untrusted headers, I presume. Even if these were reliable, this would reject messages processed by any corporate internal relay(s), while leaving spam (sent from spammers-controlled servers or cracked PCs) unaffected.
- "No anonymous senders"... Right. Hey, my name is Enl4rgeItNow! I swear!
- "no Bcc mail": like in 'no mailing-list' I guess.
etc etc...

That said, I don't think that MS' proposal is much better...

Re:The real problem is proprietary ownership of th

[hpa]

No argument that RAND is a Very Bad Thing. It is. The Yahoo IPR is, however, a Royalty-Free (RF) IPR, which doesn't have that problem.

Would forwarding companies please get in touch

[mengwong]

This message is intended for organizations that do a lot of forwarding, like acm.org and ieee.org, as well as the vanity domain providers.

During the development of SPF, we have tried very hard to accommodate your perceived concerns, because the biggest problem with SPF-against-2821, as many people have noted, is that it breaks forwarding. But your perceived concerns might not be your actual concerns.

It would be really great if the people who might be hurt by what we're planning could get involved in the discussions, so we could ask you whether we guessed right, and if there are better ways to reduce your pain.

So, if the postmaster at acm.org happens to be reading this, or if anyone reading this knows the postmaster@acm.org, please ask them to subscribe-spf-discuss@v2.listbox.com

Postmasters at other places like acm.org too.

Thanks,
meng
from Redmond

Re:Would forwarding companies please get in touch

[0x0d0a]

I want to know how SPF/Caller ID (systems with severe side effects) can be seriously proposed without any reasonable attempt to deal with the throwaway domain problem. The SPF folks have some vague hand-waving about trust networks theoretically being a fix, but if we allow a trust network infrastructure, we can provide much better systems (such as signed-by-the-user email) that would eliminate security problems, not have many of the nasty side effects that the Caller ID/SPF proposals do (like the inability to forward, the inability to run one's own mail server, poor (domain-level) granularity when it comes to blacklisting, etc).

I'm particularly frusterated because Microsoft is a crucial element in making something like this come together (without support for signing and trust metrics natively in Outlook/OE, it won't happen) and instead aiming for another "this will slow down spam for six months" hack -- and one that will severely inconvenience "innocent" users once again.

Better, but still not enough

[14erCleaner]

This is a step in the right direction (and maybe we should be practical and take what we can get), but...

Spammers can still use zombied PC's or throwaway ISP accounts to send out their spam, and they'll look good enough to pass the "caller-id" test.

I've thought about this problem some (although I'm not an email expert), and I believe that what is also needed is a way to throttle the email output of individual users (so that joeblow@yahoo.com can't send out thousands of emails a day). This would necessarily have to be done by each user's ISP; as a new user, only allow a few emails per day, and gradually raise the limit as the user gains trust (by not abusing his account).

The big problem with this approach is that every system that originates email has to cooperate. Those that don't can eventually be blacklisted by the rest of us, but it can only work if the big hosts like Yahoo, AOL, MSN lead the way. Also, this can only work if spammers can't forge the return address and/or origin of their emails, and the MS proposal seems to address this part of the problem at least.

Re:Better, but still not enough

[MavEtJu]

Spammers can still use zombied PC's or throwaway ISP accounts to send out their spam, and they'll look good enough to pass the "caller-id" test.

What the problem is about is more that SMTP doesn't allow some kind of verification of the source. With these proposals the source verification is added.

In your first case, that's a matter of host security, not SMTP security. In your second case, that's just plain evil of them but nothing SMTP can do about it.

Edwin

Re:Better, but still not enough

[prshaw]

>> The big problem with this approach is that every system that originates email has to cooperate.

And to point out the problem even more, most of the virus out there (maybe all of them now?) use their own SMTP internal server. They don't send through a big host like AOL or Yahoo.

So when you can get the virus writers to throttle their output the rest of world can follow along.

Rambused..

[Anonymous Coward]

Yes but will they patent it Rambus style?

Re:My list of reasons why this should not be adopt

[ezzzD55J]

Wow, that's an old joke you got all those moderators to laugh at..

Re:Hrm....

[pHDNgell]

Take DHCP for example - damn handy system, developed by microsoft.

Whence did this misinformation originate? I had a similar statement from some MS weenie at my last company. I showed him every bit of protocol documentation I could find at the time and asked him to show me the word ``Microsoft'' in any of it. The closest I found was a windows-specific extension somewhere.

DHCP is an extenion of bootp. They didn't do that, either (see RFC 951, 1534, 1542, 2131 etc...)

A better suggestion than Caller ID/SPF

[0x0d0a]

And what Certificate Authorities (CA) will your email server consider acceptable?

Any of them.

Two things need to work different from the current system for obtaining web server certs, which is primarily designed around enriching CAs and has a number of flaws when it comes to actually being secure (like, for instance, the look-alike name problem).

First, anyone must be able to produce a certificate endorsing an address as a "non-spam" address and have them publically published. Root CAs and an "email tax" are unacceptable for many, many reasons. A company could have a cert signed by their domain authority and sign off on each employee.

Second, trust must be non-binary (this is where GPG comes up short). People that endorse people that spam have their trust reduced. This is transitive -- people that endorse people that endorse people that spam have their trust slightly reduced. An email would be accepted if it is above some spam threshhold.

While not absolutely required, I would recommend signing on the client (and optionally signing on the server -- the benefit is that companies can quickly switch to a trusted email system without immediately transitioning and changing their clients at the risk of allowing people within their company to impersonate someone else if the company lacks authentication on outbound email.

Most people would probably trust a number of "root authorities" by default, like "ICANN" or the domain name registrars (though I'd guess that such folks would be trusted a relatively low ammount). They'd probably trust their business, which would sign off on businesses that they have business relationships with. This would not require much by way of user-visible functionality.

What happens if Bob's account at Acme Widgets gets compromised and he starts sending out spam? Bob quickly gets lots of certs saying "Bob is a spammer" from folks clicking the "this is a spam" button in their client. Bob's email quickly becomes ignored, and Acme Widgets is trusted somewhat less.

What if Acme Widgets' user-cert-granting system is compromised, and a spammer starts making new "trusted by Acme Widgets" IDs and spamming with them? Eventually, Acme Widgets loses their trust, and mail from their system starts bouncing.

The system could even be modified to avoid horribly blacklisting a company that is badly compromised once -- make such "this is a spammer" certs have a short lifespan at first -- say, a week. Exponentially increase this lifespan by default in clients. If a normally well-trusted domain sends out masses of spam once, they're only "offline" for a week. If they keep doing so, however (say, email security sucks at this place and the email server is rooted once a week), they are rapidly made unusable.

This doesn't rely on a single central authority, doesn't favor businesses over individuals, doesn't make an "email tax", doesn't not require a change en-masse (though people who haven't switched don't recieve the benefits of the system, and such a system becomes more useful the more people are in the system), does not inconvenience those who want to run their own mail server or forward (in fact, it facilitates folks doing exactly that, since they can sign things using their work certificate through their home certificate). The only drawbacks that I can think of are in increased CPU and network usage for normal operation (though the decrease in spam may more than cancel at least the network load out), and the folks who nobody knows or trusts may initially have trouble sending to people. The side effects are *positive* rather than negative -- people lose the ability to spoof email (why email is used as a business tool when it's so easy to intercept and spoof is beyond me), and a distribution system for signing keys could just as easily be used to distribute encryption keys, providing end-to-end content encryption for all users.

So many people seem adamant about converting DNS into some kind of addressing-and-securi

Re:A better suggestion than Caller ID/SPF

[Openstandards.net]

It frusterates me greatly, because I see many features that I and others use and rely upon (like running my own mail server, being able to send things with a different return address than the machine I'm mailing from, not needing to own a domain to use such functionality, etc) being sacrificed for very little actual benefit against spam.

LOL, I might have just experienced that today. Basically, I got a response from Compuware's email server refusing to forward an email I'm trying to send to one of their employees. It rejected the client host, which in this case was the reverse DNS of the public IP my email server routes out of. Here's the error message:

Client host rejected: Use your providers mailgateway 20020809

Unfortunately, since it didn't say what it didn't like about the client host, I can only speculate on the possibilities. Here are some of them:

• Not matching mail host name. Based on what you said about being able to host your own email server and not needing to own a domain, I think you understand the difficulty of the IP of your outbound traffic not resolving to the domain of your mail server.
• Blacklisted domain. Since it reverse DNS'd the public IP my network routes through, it obtained the domain of my ISP. I know for a fact that pleny of computers resolving to my ISP's domain have been infected, because I've had countless logs on my websites resolving to the domain.
• Blacklisted IP. I used to have an compromised NT box, which I wiped out and replaced happily with FreeBSD. However, it may have never forgiven me since. I think I remember indications that I couldn't send Compuware email a long while back, so this could be a case where I was blacklisted for being compromised a long time ago, and Compuware does not have a forgiveness program in place.

Regardless, I currently created a new subdomain for that IP. As soon as it goes live, I'm going to create a reverse DNS for that IP. This way it will resolve to the same domain as my mail server. However, it won't actually resolve to the domain of 99% of my outgoing mail, as I use the email server to send and receive email for multiple domains, and the one the mail server is defined for my MX records is rarely used. The domain for my mail server is used primarily for infrastracture.

Re:A better suggestion than Caller ID/SPF

[Russ Nelson]

DomainKeys.
-russ

Re:A better suggestion than Caller ID/SPF

[prshaw]

I thinnk Compuware uses a public rbl, and it is probably your ip address that is listed somewhere. So a new sub-domain on the same ip address probably won't help much.

Re:A better suggestion than Caller ID/SPF

[0x0d0a]

Yahoo's DomainKeys proposal, unlike Caller ID and SPF, eliminates many of the drawbacks that Caller ID/SPF have. If I *had* to see one of the three used, I would call DomainKeys the technically superior of the three, and push for it. Caller ID and SPF both use host-address-based authentication (Are the lessons of yesteryear so quickly forgotten?). Because of caching, they have a delay period while mail hosts can be moved around. DomainKeys uses key-based authentication -- a much better system. The only disadvantage of DomainKeys versus Caller ID or SPF is its greater CPU load. DomainKeys does not break forwarding, unlike Caller ID and SPF. DomainKeys was actually designed with consideration for needing to move mail servers to new IPs (and the fact that hosts cache) and will not cause mail to bounce as "unauthorized" for some period of time after you change your mail server IP.

DomainKeys still imposes some of the drawbacks of Caller ID/SPF. It is generally not possible to run your own mail server. It's technically possible to have multiple servers, but this requires copying the domain private key to the other servers. It's possible to have multiple servers, in Caller ID/SPF by adding those servers to the DNS record as authorized servers. However, with DomainKeys/Caller ID/SPF, one must be on good terms with one's DNS admin to do so, as all require the addition of DNS elements. If I work for Chrysler, I can easily send work-related email from home in a system that checks signatures on a per-user basis. If I want to do so with Caller ID/SPF/DomainKeys, I have to convince the admins to add DNS entries (which is going to require months of meetings in any large company).

DomainKeys *still* passes the security buck off when it comes to DNS (with a vague "oh, people should start using DNSSEC soon anyway"). There are known and clear holes in DNS that make it currently unsuitable for authentication procedures (it's spoofable, its caching can cause successful spoofs to be much more damaging, etc). DNS was *never* designed to be a secure authentication system, and DomainKeys/Caller ID/SPF try to retrofit it into doing so.

DomainKeys/Caller ID/SPF do not handle the throwaway domain problem.

DomainKeys/Caller ID/SPF all follow the "the entire system works only as long as there are no security breeches anywhere within the system -- in such an event, everyone may be negatively impacted" model. All mail servers are considered trusted sources of mail for their domain. If I can beat the local security within *any* domain from the MUA to the local mailserver, I can send spam to everyone. There are a lot of ways to do this -- compromise a host on the network, an account or a mailserver. This security model does *not* work on large-scale systems like the Internet -- if it did, we wouldn't *need* any anti-spam systems because there would be no open relays in existence (the last time we tried using such an approach) and hence no spam.

Caller ID/SPF/DomainKeys all use domain-level granularity rather than user-level granularity. If I compromise a user's computer (let us suppose it is at ford.com), the only option the rest of the world has is to ban all of ford.com, since there is no guaranteed way for them to ensure that a user at ford.com can't just spoof other users at ford.com to the mailserver.

The problem is that Caller ID, SPF, and DomainKeys all fall far, far short of what is necessary (and the "well, it's better than before" argument does not hold much water when severe limitations are being imposed). Every one of the three is aimed at solving a single problem that does *not* encompass the spam problem -- ensuring that mail from a domain passed through that domain's mail servers. There are times when legitimate mail does not do this (and removing this allowance would break functionality that cannot otherwise be provided). Furthermore (and probably of more concern to the masses) there are many ways to still send spam with such a constraint. None of the three, for instance, attempts to deal with throwaway domains (though the SPF people do some vague handwaving about "trust networks" -- ignoring the fact that if trust networks are put in place, there are much better solutions to spam than SPF).

Re:A better suggestion than Caller ID/SPF

[Openstandards.net]

How do I find out if my IP is on a public rbl, and how I can get off it? I went to spamcop.com, and there's nothing there for checking or removing your IP.

Re:A better suggestion than Caller ID/SPF

[Openstandards.net]

I just checked spamcop.net and 6 other public rbls, and am not listed in any of them.

The reverse DNS should be live by midnight tonight, so I'll test it then.

Re:A better suggestion than Caller ID/SPF

[prshaw]

Try this site, enter your ip and see if any of them have you listed.

http://rbls.org/

Getting off the list is different for each list, you will have to read their site to see.

Re:A better suggestion than Caller ID/SPF

[Russ Nelson]

A few misconceptions.

o It's far from trivial to spoof DNS queries. If spoofing is a concern, then run djbdns instead of BIND. djbdns's cache uses 32-bit identifiers by incorporating the source port into the id.

o DomainKeys allows user-level granularity. You can use as many keys as you want to administer.

Re:A better suggestion than Caller ID/SPF

[0x0d0a]

o It's far from trivial to spoof DNS queries.

I'd say that's one of the more trivial things in the IP world to spoof. I guess what we call "trivial" is relative.

If spoofing is a concern, then run djbdns instead of BIND. djbdns's cache uses 32-bit identifiers by incorporating the source port into the id.

Aside from the fact that "oh, it works, just replace all instances of the most popular nameserver on the Internet with another" isn't going to be very popular (if we're going to be ripping up major infrastructure, as I said above, I'd rather be doing things right, and fixing more problems that allow through spam than just impersonating servers), a lot of folks are going to have firewalls that can't handle djbdns' technique, and they then need to be told that they need to replace their firewalls, also not very popular. Spam is bad -- replacing the mail, DNS, and firewall daemons throughout the Internet to fix a single issue that does not even come close to stopping spam is unacceptable.

o DomainKeys allows user-level granularity. You can use as many keys as you want to administer.

I am open to the possibility that I am drastically misreading the DomainKeys proposal. I have only seriously taken a look at DomainKeys recently, and while I'm reasonably sure that your statement is not true (at least in the straightforward sense of not requiring a domain-per-user), I am quite open to having my mind changed.

Reading through that document, this is my understanding. DomainKeys-related authentication is entirely done for the benefit of the receiving server, and authorizes the sending server. It seems that one may only set a DomainKeys authentication rule of the following format: "if message is signed by one of the set of keys registered for this domain, then accept the message". There is no way to say "If message is signed by one of the set of keys registed for this user:domain tuple, then accept this message". DomainKeys provides functionality for multiple keys per domain (the design of which I must give the Yahoo folks a hand for -- they worked around a number of DNS-related issues here, including some subtle ones, like the problems of rapidly switching keys due to caching). However, every one of these keys authorizes every user. If a user's account is compromised, he may send spam that appears to the remote system to be valid mail from any user, as is also the case if the source mail server is compromised.

trust metrics

[lkcl]

y'know, i really don't see what all the fuss is about. there's a very simple protocol, an implementation of which is on advogato.org, called trust metrics.

when combined with digital signatures, and when you can choose the centre of the web of trust, you get a powerful mechanism to vet spam.

an automated or semi-automated declaration "i trust this person not to send spam" is the basis of the web.

Pedantic offtopic

[phliar]

on their SCHEMAE

The plural of schema is schemata. Greek roots vs. Latin roots, etc.

Or, if you don't want to be called pedantic, just use schemas. If we borrow a word from another language there isn't really a good reason to follow its rules.

(And virii is never correct. It would be the plural of virius, not virus. cf. radius, radii. Just say viruses.)

Re:Pedantic offtopic

[Anonymous Coward]

The United States of America : The Microsoft of the English Language

SPF + Caller ID are merging

[jgardn]

According to recent posts by Meng Weng Wong (author of SPF) to the spf-discuss list, the "new SPF" will incorporate features of Caller ID.

In general:

* The RFC 2822 FROM header will be duplicated in the RFC 2821 header. Mail servers will say:

MAIL FROM: <original@original.com> RFROM: <me@me.com>

* SPF rules (which were basically the same as Caller ID's) can specified in either text or XML.

* A new DNS record type for SPF will be used rather than TXT.

But don't take my word for it. Go read the posts here:

http://archives.listbox.com/spf-discuss%40v2.lis tb ox.com/200405/0198.html

MS and secure E-Mail

[Anonymous Coward]

Since when did M.S. give hoot about secure E-Mail?
It seems MS does everything in it's power to make E-mail a useless tool. The very fact that the dot net framework is so hard to secure, is a deliberate attempt by MS to outdate WindowsXP and all it's insecure varients. There never has been a reason for computer mal-ware and viruses. I believe that when MS cloned Norton system tools and proceeded to get their ass sued off, the need for anti-virus software was born. The hole in the middle of Windows could have been fixed, but insecurity is the price we pay , every time we use MS software and this insecurity is there on purpose.

Helping out

[hkb]

I see a lot of posts saying that Microsoft "is just trying to create a better user experience". On the face of things, this appears to be a good thing, but don't forget about the Windows 95 interface, Microsoft Bob, Clippy, the Search dog, Personalized Menus, the Windows XP/2003 default start menu, NetBEUI, Internet Explorer 3rd party extensions, AutoCorrect, uPnP, ISAPI, vti_printers, and so on.

Sometimes I wish they'd just be a brutal monopolist and leave the user friendliness to folks who are better at it: Apple, Palm, and the fvwm and LISP developers...

Breakable

[mr100percent]

Would this break forwarding?

I can see Spammers getting around this, all they would need to do is make viruses that make YOU send signed spam from your mailbox, or just somehow make you forward the stuff.

Sabotage

[ahdeoz]

Microsoft and Yahoo are trying to sabotage SPF. Because they *WANT* to send spam. Only it's spam from more "reputable" companies.

Re:XML good. For some things.

[Anonymous Coward]

Mostly, you're right. It's GREAT for many config files. It's easy to parse, it's non-binary, the structure is self describing and it's EASY to present forms for managing something via web or curses or GUI.

XML? Easy to parse? Hell no.

S-expressions are easy to parse. Flat text files are easy to parse. INI files are easy to parse. CSV or tab delimited text is easy to parse.

XML is *hard* to parse, it's just that you don't have to write the code to do it. XML is good because it's standard and universal, not because it's easy to parse.

Re:Hrm....

[pyrrhonist]

Take DHCP for example - damn handy system, developed by microsoft.

No it wasn't.

However, Microsoft is referenced as an author for the following DHCP related RFCs:

• RFC 3004 - The User Class Option for DHCP
• RFC 3456 - Dynamic Host Configuration Protocol (DHCPv4)Configuration of IPsec Tunnel Mode

You were probably thinking of Dynamic Configuration of Link-Local IPv4 Addresses, which was developed partly by Microsoft, but is an Internet draft, not an RFC.

Re:The real problem is proprietary ownership of th

[Russ Nelson]

The problem is that somebody could then patent it. So, then, you say "Well, Yahoo should patent it, and put the patent in the public domain." That's nice, but if you read the patent grant, it says that if you use DomainKeys, and somebody thinks you're infringing their patent, and they sue you, *Yahoo* (deep corporate pockets) can sue them for infringing Yahoo's patent license.

The trouble with the patent office is that they have completely lost the concept of unpatentable subject matter.
-russ

Sigh, no.

[Russ Nelson]

Sigh, no. First, it's worthwhile to Yahoo, because so many people forge Yahoo email. Because Yahoo will be an early adoptor, anybody who is blocking Yahoo but would really rather not need merely check the signature on Yahoo email, and refuse it if it's unsigned. Second, it will be worthwhile to Paypal, because you'll be able to trust email From: service@paypal.com because it'll be cryptographically signed. Third, even before everyone is sending signed email, you'll be able to hold unsigned email to a higher standard. If it's not signed and it smells even a little like spam, it's spam.
-russ

Re:Hrm....

[Krach42]

2 minute search through Google yields:

http://en.wikipedia.org/wiki/DHCP

Microsoft introduced DHCP on their NT server with Windows NT version 3.5 in late 1994. In addition to most server operating systems, many devices, like Ethernet routers and DSL routers, provide some sort of DHCP server.

IGNORE MY PARENT POST!!!

[Krach42]

I was lead astray by the grandparent of the parent post.

I repent my ways, but ask you to see how one could be lead to such a conclusion from the Wikipedia entry.

I should submit a patch.

Re:If only they'd set their bloody HELO/EHLO prope

[prshaw]

You lost me.

What does Windows have to do with the string my OSS email server uses for HELO? Is MS watching the network packets and changing it?

I can see complaining about the DNS problems though. You are right in that MS should be running the entire DNS system to make sure that forward and reverse lookups work. That is what you want right?

Bills Syndrome :-)

[Anonymous Coward]

This man suffers from a condition pretty similar
to that of people with eating disorder.
This one is monetary though

Something in the same line from the "innovative" psychatrist banging on the geek:

http://www.kuro5hin.org/print/2004/5/17/172914/5 76

Uhmm... what?

[Sethus]

Hm... *loads up my hotmail account*

*Pop-ups appear*

#%!#^ing Microsoft hypocrites.

Re:Hrm....

[TeknoHog]

Take DHCP for example - damn handy system,

Great! Now I know what the D and H stand for :)

Deja Vu

[Per Abrahamsen]

> Microsoft has not sued over Mono. As far as I can see, they're not going to.

I read that before. Back when FSF was urging everyone to avoid LZW compression (used by "compress" and "gif"), because it was patented by Unisys. FSF even introduced their own patent free "gzip" utility, and zlib library to be used in other apllications (unusually for FSF, even proprietary ones).

There were also people harrasing the FSF for that, claiming they were fanatics creating unnecessarty disruptions (compress was the de-facto standard), and refering to low-ranging Unisys people the think had said they were only interested in LZW build into hardware like modems.

Of course, this changed once Unisys out of the blue started demanding royalities for gif creation tools.

The FSF demanding paperwork for contributions to their code is a similar case. Long time before the SCO case.

The sad thing is, when it comes to "intellectual property right", the paranoid tin-foil hats unfortunately tend to be right. And the "happy go lucky" people (like your argument: nothing bad has happened YET, so nothing bad will happen EVER) tend to get burned.

What's 2822 2821

[tacocat]

I read throught this briefly and have one question. What do they mean by 2821 and 2822 checking? Validating the email against RFC's?

From the sounds of the article, that alone would accomodate most of the trapping that they need to do. If that's true, then why don't we just reconfigure the mail servers to be fully RFC compliant in their expectations and if you're email isn't going to be fully RFC compliant then you get bounced?

Why don't we just have the mail senders do what they are expected to do for starters?

Re:My list of reasons why this should not be adopt

[Anonymous Coward]

It is also fussy in who it accepts as users...

What I would really like them to have done

[rikkards]

Add the ability to block a whole domain name in the Junk Email feature in Outlook 2003.
It has the ability to add a whole domain as Safe Senders but nothing for adding a domain as Rejected.
However it is decent as it is right now

Re:If only they'd set their bloody HELO/EHLO prope

[Zey]

You lost me.
What does Windows have to do with the string my OSS email server uses for HELO? Is MS watching the network packets and changing it?

You've misunderstood. Enforce strict HELO/EHLO checks on your mail server and you lose incoming email from all those misconfigured NT/2000 mail servers which identify themselves as "exchange.local" or "ntbox.company" etc instead of something like "mail.companyname.com" which exists in DNS.

I can see complaining about the DNS problems though. You are right in that MS should be running the entire DNS system to make sure that forward and reverse lookups work. That is what you want right?

Ah, you're being intentionally bratty. Nope, I'd settle for Microsoft providing a readily accessible documented method for NT administrators to fix their servers so they identify themselves correctly at the HELO/EHLO portion of SMTP exchanges.

When the real mail servers identify themselves properly, we can more easily nobble the spam from unsecured desktop systems which aren't so likely to have properly installed mail servers which readily identify themselves by simply rejecting invalid HELO/EHLO or those containing strings identifying the IP as dynamic space.

Re:If only they'd set their bloody HELO/EHLO prope

[prshaw]

Enforce strict HELO/EHLO checks on your mail server and you lose incoming email from ANY misconfigured mail server.

As for them providing a documented way to change it, it's one of the configuration fields. A quick search in yahoo found several pages showing how to set name sent. Several of them pointing to pages on microsoft.com.

Now admins may not know what name should be set and enter the wrong one. Nothing server software can do about that.

And all this scales how?

[Anonymous Coward]

And this is going to scale to mail systems processing tens of
millions of messages a day today how? Even if you assume
that 50% of that is spam, that's still a boatload of crypto effort.