Microsoft and Yahoo! Fight Spam - Sort Of

kyndig writes "In a Forbes article, Microsoft claims that 90% of email on the internet is spam. To fight this, Yahoo! has teamed with Cisco in developing DKIM, a signature based email authentication. Not to be outdone, Microsoft is proposing SenderID, which examines an email to see if it is coming from an authorized server. Earthlink's chief technology officer, Tripp Cox, goes on to examine the pro's and con's of each specification and provides practical application results." From the article: "Critics have accused Microsoft forcing SenderID on the industry without addressing questions about perceived shortcomings. The company drew fresh criticism recently when reports claimed that its Hotmail service would delete all messages without a valid SenderID record beginning in November. While AOL uses SPF, many e-mail systems do not. If Microsoft went through with this, for example, a significant portion of valid e-mails would never reach intended Hotmail recipients."

Comments

delete all messages without a valid SenderID

[Anonymous Coward]

To delete all messages without a valid SenderID is not quite the same as to mark non valid SenderId messages as spam

Sender Policy Framework

[coolnicks]

There is also Sender Policy Framework (http://spf.pobox.com/), this is very simular to SenderID but it has the majour advantage that its open source, agreed microsoft is trying to push SenderID down everybodys throats, I myself publish SPF on a number of domains and it does a good job. The more people that use SPF the more power it will have over SenderID.

Re:Sender Policy Framework

[coolnicks]

I disagree with the false positives statement, I run web and email hosting and cant recall seeing any false positives.

Agreed SPF does a better job at fighting fraud and viri, but it does have a go against spam. A very high amount of spam is from fake or randomly picked real domains, now when all these real domains publish SPF nobody can send spam form them anymore, combine this with checking for existent domains and the only option left is for the spammers to root servers as you said or buy their own domains. Buying their own domains can be sorted quite easily by black lists, as soon as the world and his wife starts receiving SPAM from a new domain it can be blacklisted, and in regards to rooted servers, sure this is a way to get past the SPF, but if people secure their servers/get themselves onto black lists we should be ok.

Nick

Re:Sender Policy Framework

[tepples]

Does this now mean that SenderID includes SPF?

Yes. If you're publishing SPF records, you're already publishing records that are accepted as valid by any conforming SenderID processor.

Re:Let MS do it...

[DrEldarion]

If anyone had even bothered to read the linked article, they'd see that it said MS would "flag it as potential spam". They wouldn't just stop getting it.

Re:Let MS do it...

[pmsr]

You don't need an Hotmail account to use Messenger. Hotmail and Passport accounts are two very different beasts. Just register your Gmail account on the Passport.net site.

/Pedro

Re:Let MS do it...

[maotx]

Actually, what we need is a messaging protocol that isn't tied to some website.

Jabber anyone?

Why is this a problem?

[bad_outlook]

Seriously, why is this a problem? At home I have a FreeBSD box that runs mail through scanners and figures out what's what. Works like this:

incoming:25 -> Postgrey (greylisting) -> MailScanner -> ClamAV -> Spamassassin (with DCC, razor checks) -> DSPAM -> Postfix -> users_mailbox

All ClamAV definitions are updated via cron by Freshclam, all Spamassasin rules are updated via Rules_du_jour daily. Using this I get just about zero spam, with a VERY rare occurance of realy mail being labelled spam (and that's usually bad chain-emails sent around by my wife's friends - and I consider that spam anyway ;)). Seriously, I'm no genius, but why can't this kind of solution be bolted on? Even if a company is locked into Exchange, slap a box like this accepting :25, then have it relay mail on after the checks!

I fail to see why a solution like this can't be implemented on a large scale 'free-mail' company like Hotmail or Yahoo! If they could stop (and eventually block) spams, they could help turn the tables on spammers, making them less profitable. What am I not seeing?

Re: A blank check for Microsoft.

[FriendlyLurker]

This article "A blank check for Microsoft" more or less confirms the changes to spam policy I have observed while using Hotmail over the past few months:
http://blogs.salon.com/0003364/stories/2005/02/01/ aBlankCheckForMicrosoft.html

SenderID does not help spam... too much

[ChadL]

I was getting about 40 spam messages a day, before I implemented my new anti-spam e-mail server. Now I get about one or two... but SenderID only blocks about two messages a week. Much more effective are my set of 5 Blacklists, a URL Blacklist, and some simple rules. SenderID can stop fake from addresses, but the people sending the messages will just use servers that do not have SPF entry's, as all the servers will never implement it.

Re:Let MS do it...

[BeatRyder]

Hmm, trillian?

Re:"Leverage"

[Anonymous Coward]

The sticks could be on fire.

Re:Let MS do it...

[lav-chan]

Trillian is OK feature-wise (it supports most of the major protocols completely), but there's also Miranda, which is an open-source 'minimal' client. It's got a ways to go (their AIM plug-in still uses TOC instead of OSCAR), but depending on what you need it might be good for you.

Email Authentication Options

[SuperSanta]

I just got back New York and the http://www.emailauthentication.org/summit2005/agen da.html/ Email Authentication Summit that covered all of these topics. Here's the last one page summary on all 3 (SPF, Sender ID, DKIM)

How is validation performed?
SPF - RFC2821 MAIL FROM address, "Bounce" or "envelope from" address
Sender ID - RFC2822 PRA FROM address
DKIM / DK - Designated "singer" address/RFC2822 FROM address

Strengths
SPF - Reduces bounce messages where the victim receives errors for mail they didn't send
Sender ID - Validates the identity most users see and reduces the threat to phishing.
DKIM / DK - Provides end-to-end validation over multiple hops (i.e. forwarding)

MTA Updates?
SPF - Receiving update required.
Sender ID - Receiving update required.
DKIM / DK - Sender / Receiving MTA update required.

Weaknesses
SPF - Only validates the last hop
Sender ID - Only validates the last hop
DKIM / DK - Can be "broken" by imperceptible changes (and FWD: >'s in messages)

Publishing / Signing
SPF - Easy. Publish and maintain in DNS.
Sender ID - Easy. Publish and maintain in DNS.
DKIM / DK - Create keys & publish in DNS.

Mailing Lists
SPF - Easy.
Sender ID - Easy.
DKIM / DK - Hard

Forwarding
SPF - Hard.
Sender ID - Requires a header added.
DKIM / DK - Easy

Performance
SPF - Negotiable. ISPS may cache to improve.
Sender ID - Negotiable. ISPS may cache to improve.
DKIM / DK - 5 - 10% processing CPU