Yahoo! Develops Anti-Spam Architecture
prostoalex writes "Yahoo!, the owner of one of the largest e-mail systems in the world, is said to be developing a cryptographic product that will be offered freely to mail servers. 'Domain Keys,' according to the Reuters article, would require the message sender to authenticate in order for message to come across a trusted e-mail network. The idea has been around for ages, however, it required someone from the big league like Yahoo! to step in." While Yahoo! isn't the first name that comes to mind when I think of trusted email, it's still a step in the right direction.
But ultimately one has to worry about the lock that Yahoo! might have on servers once they get it installed all over the place.
Could you imagine this becoming really popular and then Yahoo! getting bought by someone like oh say Microsoft? (or any other big commercial interest)
"Trusted email" and "Yahoo!" should not be mentioned in the same sentence, except perhaps to say that these two things should not be mentioned in the same sentence.
I can't see how they can "lock" anything since it is clearly stated that the initiative will be open sourced...
Of course, Microsoft will probably figure out a way to break it so that it only works with their products but that's a different story...
SpamCon's Barrett cautioned "It's a good approach for those that are willing to use it," he said. "Any kind of cryptographic solution is going to involve some computing overhead, and that's not cheap."
...
Whereas the latter completely true, I think the weakness of the argument is a testament to the idea being an excellent one. CPU horsepower is very very cheap. If Yahoo think they can do it, then who exactly will have a problem ?
Just as long as I can incorporate it into my server, I'll be a happy bunny - all the other proposals put forward so far seem to limit the mail providers to the big boys
Simon.
Physicists get Hadrons!
But how am I going to get my special penis enlargement information now? And what about that family matter I am resolving with Mr. Mobotu?
In all seriousness, I think this is a good idea. But, sadly, it's going to be cracked. Domain keys can be forged, and that will be the first thing that these spam servers will be focussing on right now. They'll set up a Yahoo acct and monitor traffic to see what the domain keys look like. They will then duplicate the acks and be back in business. It's only a matter of time.
This is a good step, no doubt. It is just that we should be looking at ways of putting spammers out of business, too. Hit their wallets, not their tech. Tech can always be worked around, especially by dubious people.
Instead of domain keys, I had a different idea that might work a lot better.
What if nobody sent email over the Internet?
Today we have the ability to use web forms to pass messages back and forth to other users on the same service. With that option, the server admin would be able to flag spammers and ban them. If you wanted to message another user of another server, you could type in their location as USERNAME@DOMAIN, and that would queue to be sent in batch to the other server after authentication.
No outside contact. No spam. One message per customer. If you send more than a certain number of messages in a day, they are held as possible spam.
Privacy goes out the window, but hey... it's not like there is any privacy in non-encrypted email anyway.
Does anyone know what software Yahoo's mailservers run?
Feel that power? That's mah MOUSING FINGER
You know I use Yahoo! Mail all the time... it does a great job in blocking spam... far better than Mozilla Thunderbird and Spam Assisian working together. While to two work great its a far cry from my Yahoo! Mail.
would they want to cut off 90% of their own customers? Mabee they will sell a new "technology" to circumvent the block system to the spammers. not like nobodys ever done that before.
"It's so convenient to have a system where everyone is a criminal" - A. Hitler
An end to the positively _medireview_ problems of proving your identity online.
Yay Yahoo!
I think the only way to make this work is to put control in the hands of an international body. Like ICANN, only with real teeth this time. Then it can't get 'bought' by a monopoly or someone looking to cripple a market segment for their own gain.
The other options is a consortium run along the same lines, with financial contribution by the tier 1 backbone providers, but the actual policy and control mechanisms managed by a either the above mentioned international body, or a non-profit corp.
RMW
flames > dev/null
...you'll only be spammed by Yahoo??
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
Oh, yes. Genius solution there. I'll just call each and every new member of my website when they sign up and tell them their account information and password over the telephone. And every four minutes, I'll update auction winners, losers and posters of the status of their auctions, instead of sending them a "you've won" or "you've been outbid" or "you've sold item" notices. And I'll just require that everyone call me to ask simple questions rather than emailing me for help on the site. And when someone loses their password, I'll just insist on them calling me to retrieve it. Sure, I run a free site and couldn't afford the time or cost of doing everything by phone - but hey, why not right? It's "more effective".
Lame luddite "solution".
> I have a better, more effective solution to the spam problem and that is I don't email Headache ..??? Chop off the head !!
As long as it's an open standard that eventually becomes RFC3821, I'll be okay with it. But if it's one of those proprietary "pay us to participate" schemes, they can go jump. Oh, and there should be no scope for someone to say "pay us or we won't accept email from you.
Personally, I'd like to see two things.
1. The software Yahoo! is developing should be open-source, so nobody can monopolize it. At the very minimum, the protocols involved should be well documented so open-sourcers can make their own implementations if they have to.
2. Give this software a few months to propogate to a good chunk of the ISPs out there. Then, Yahoo! should announce that they will NOT accept any email that is not signed with this software. I'll guarantee that everyone will be using this new protocol in a matter of weeks, since no ISP wants customers screaming because they can't get mail through to Yahoo! accounts.
Meldroc, Waster of Electrons
I'm assuming that what is sent out is an encypted token for which the public key can be used to decrpyt, so:
So, the token to be encoded will change from mail to mail, thus making replay techniques pretty much impossible, I think. At least, that's the way I'd do it, and I'm pretty sure I've seen it presented before as well...
On the other hand, I ain't a security expert, so there's probably a gaping hole in the above
Simon
Physicists get Hadrons!
Of course, Microsoft will probably figure out a way to break it so that it only works with their products but that's a different story...
or will they figure out how to put a backdoor in their products so that all spammers in the world will have a 'new trusted zombie' ?
--
#
#\ @ ? Colonize Mars
#
if they do not share the technology completely, this is a bad thing as yahoo will have some kind of power over all email servers. the article doesnt go into those kind of details... does anyone know any more, and like to share the knowledge?
It can be open sourced, but that doesn't mean anything about preventing lock-in.
Presumably a 'domain key' is some cryptographic element that authenticates that your domain is who it claims to be. To me this sounds an awful lot like SSL where a third party issues the keys, or acts as a clearinghouse for self-issued keys.
Either way, Yahoo could be the man in the middle acting as either issuer or clearinghouse. Think of it this way, OpenSSL is open sourced, but that doesn't keep the SSL issuers from having a lock on that market.
Obviously they must mean something besides the traditional notion of "private key" when they say "a private key is sent in the header, and the public key is used to decrypt it".
Is this a mistake, or is there some other terminology this is following?
Yahoo is taking a standardization approach...the technology will be shared with open source and commercial developers, and the keys themselves will be put into the DNS system.
I'll be interested to see how the details of how they attempt to protect the system from key forgery.
If someone announced a cure for all cancers, this crowd would immediately dismiss it because it could possible be bought by Microsoft. You pimply-faced pessimists remind my of Eor from Winnie the Pooh.
One guy's take on why it won't work
If the spammer...or anyone for that matter is spoofing a header anyway, it shouldn't be difficult to find out the encrypted private key, since it is sent out with every message originating from the domain.
I could, presumably send an email from my secure email address to a non-existent email address of the domain whose encrypted private key I wish to find out: eg bounce@email.com. The bounced message should have it in the header.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
The first time that I heard about a teergrube to use as a way to block -- or at least make it damned difficult for -- spammers I was intrigued at its simplicity. And tho' I find references to it all over the 'net, I don't think that it has been mainstreamed yet, and frankly I don't know why. Have spammers developed a counter to a teergrube? Or do mail admins simply not know enough about them?
Mit der Dummheit kämpfen Götter selbst vergebens.
What's wrong with Yahoo email? I honestly don't know, so can someone tell me? Are they letting spammers abuse their servers? Are they spamming people outside of yahoo.com? Are they continuing to spam users after they've opted-out? Is their system in-secure, letting script kiddies crack it regularly? ...
tmda
when you think about it, BUT this should come from IETF or some other body not from a company. A few important points:
...
1) Who will issue the keys?
2) Is anonymous mail possible if the receiver allows it?
Furthermore spamming is a social problem emerging from our commercial world and technical solutions can never be 100%. What if:
a) I send spam from a "secure" domain?
b) forge certificates?
c) the certificates are too expensive? (like SSL, I think it should be included with a domain)
I like the "Bayes" spam filters best. You get 99.5% spam protection and keep anonymous mail.
We all see the need for authenticated senders (biz communication, etc.), but we should be careful
>They'll set up a Yahoo acct and monitor traffic to see what the domain keys look like.
If you would have RTFA, you would know that it will work similar to SSL, with public and private keys. It will be open source. They are trying to make a standard. However, I can't quite see MS embedding this into exchange. They want their own system of trust based around everyone paying them money for licenses to communicate with the world.
Me personally, if spam makes it through my filter, I ban off the offending address working my way up towards the class c - b - a. All attempts at a port 25 connection is drop point blank, http, https, etal are kept open. I also have dontspam#somefreemailaccount.com's to use for form shit. Once in a while when registering for say an upper-crust website account, I'll use something like msndoesntspam@mydomain.com to see who exactly is sharing my addresses, then null the account if I see anything odd coming in to that account, and never trust the site again. Procmail works the most wonders though.
MoFscker
First let them implement some user account verification, so that a RCPT TO: results in a 550 reply when that user does not exist.
This enables SMTP callbacks to stop spam being spoofed "from yahoo", just like everyone else does.
I've used my Y! acct as my main (personal) e-mail acct since sometime in late 1998/early 1999, so I'm very glad to hear about this. Hopefully it will help combat the 100-200 SPAM msgs I get per day. The Bulk Mail folder was a step in the right direction, as it does catch the majority of the crap, and allows me to delete it with a single click.
Thanks! Again! Yahoo!</elRegStyle>
-bZj
.sig
Wonder if it will it stop all the crap mail that Yahoo sends.
Okay, so they're developing a system that they'll release to open-source developers.... why not DEVELOP it in the open in the first place?
Ed R.Zahurak
You know, oblivion keeps looking better every day.
Hello crypto expert (who as read the same books as everyone here)... how do you they aren't going to hire (haven't already) hired some good crypto people. Maybe even people with degrees -- there are thousands.
The article is obvious wrong, you should not send the private key with each email, rather sign the email with a checksum derived from the private key.
That checksum can then be verified by requesting the private key through dns. This way it is possible to block domains that are sending spam (and be sure the domain not is spoofed).
What a horrible way to create the death of email. I mean that literally. Users DO NOT respond to these assine confirm-you-identity requests. Hell they don't even respond to our requests from our Helpdesk to clean out their over-quota home directories before we do it for them. TMDA is not a solution for anyone other than those people that don't want to get email. I mean that literally. TMDA also can't handle auto-acks from unknown addresses. For example Newegg and Amazon email invoices to you after a purchase and also email you shipping info. Neither Newegg or Amazon can respond to mail sent back to the From address because it's a list bot and set to bounce. TMDA can't handle this. The user will have to be able to add that address in advance. Just imagine what it would be like calling Amazon to ask them for the address that they'll use to email you. I bet that would baffle their CSRs. The same can be said for mailing lists that the user actually subscribes to (or agrees to be subscribed to). If they expect the world to conform to their whim and ack their auto-request then they have another thing coming. They are intentionally making email even less of a reliable medium than it already is. Personally I blacklist all people I find using TMDA. There is nothing worse than posting to NANOG or some other mailing list and getting 3 TMDA responses from people you've never heard of. Most of them don't quote the message that generated the TMDA request. You're left to wonder 'is this some new spammer trick to get my email address?'. I see it happening in the near future IMHO. Don't use TMDA and the rest of the Internet won't have to blacklist you.
Bala Krishnamurthy at AT&T Labs has given a number of talks recently, including to the IETF, on a spam disincentive program he calls SHRED. My understanding is that it uses offline cryptographic computation to amortize this overhead and distribute it to parties willing and able to devote the computational resources.
In any case, the tag line for this article had it right, standardizing this will be hard and heavy-hitters like Yahoo will need to take the lead. But a key problem is getting the new system to interoperate with the old.
Mencken had it right. So glad that's old news.
From the article: Yahoo said its "Domain Keys" software, which it hopes to launch in 2004, will be made available freely to the developers of the Web's major open-source e-mail software and systems.
But later: Garlinghouse also argued that Yahoo's proposal should be attractive to other e-mail providers because it is free and comes with no special restrictions. Is the GPL considered a "special restriction"? Will it not actually be GPL, just available to open systems?
I'm guessing that you'll need to be a GPL mail server to both require the private key for receipt, and to be able to use the system to give the email the private key for sending. So, what will this do to non-open mail systems?
Is Yahoo trying to break MicroSoft's mail service? Will this work? What's MSFT's option--reverse this and include it in their system anyways? Switch to an open system for a mail server, like, say, something based on a BSD license? Or ignore it, in an attempt to deprive it of critical mass?
Indeed, this might all be moot; Yahoo might make it free and available to everyone, either on a free system or a non-free system; the article isn't clear as it says both. It could also be that MSFT already uses an OSS mailserver in IIS for all I know about MSFT product. But I suspect this is a power-grab, like everything else these days. And, I have to say, if it is I wish Yahoo the best of luck--this would be another demonstration of the power of OSS; it allows the community to change together on a dime and play well together. Whereas makers of proprietary systems each have to modify their own systems with their own coders.
--
$tar -xvf
I don't see how lock in will be an issue. Imagine the following scenario:
I can't see how this would neccesitate a clearinghouse.
Anyone see the seinfeld episode where kramer refuses to get mail and puts bricks in the mail box? -1Troll
Consider the common scenario in which a user marks his outbound mail as coming from domain X -- but X is only a forwarding service for inbound e-mail, like, say pobox.com or arrl.net. The outbound e-mail gets sent out through some other ISP. From the description in the article, it appears that somehow someone with the private key for domain X is somehow supposed to add something to the outbound e-mail; but that e-mail never goes anywhere near domain X.
So you claim a company with millions of users not knowing about cryptography...
Which school you got points?
SCO to announce lawsuit insisting that they hold the copyrights to all encryption.
Berrik
Current karma: Terrible (due to mods without a sense of humor)
Ye gods, untoot that horn boy-o.
Detail the rookie mistakes if yer gonna denounce em...
a thing to remember is that if someone can prevent a spammer from communicating based on identity (or lack thereof), you can be silenced as well.
This is why I have put my efforts into sender-pay systems and specifically the camram project. We invite you to please come and join us in the effort to build a decentralized, user-friendly, freedom-of-speech supporting antispam system and hit spammers in the pocketbook.
camram antique documentation (too busy writing code to write new documentation)
Warning -- moderators on crack. Anyone who read the last sentence of the parent post and though it was "interesting" probably failed Fingerpaint 101.
Its a race between those who send and those who wish not to receive, and lets be honest with ourselves it will continue to be. As we get more better at filtering so do they. Random subjects, spoofed headers, hacked relays, etc. In my spambox once a day for the last month (its annoying even going there), and funny I can't seem to unsubscribe and its coming from China: 2004 will be your year! VP-OIL Instant, Rock Solid Erections - Immediate Rock-Solid Erections - Total, Oversize Arousal - Double-Strength Orgasms - Super Staying Power - Maximum Sexual Health - Increase the Size and Intensity of your Erections! - Completely Safe and Effective Lubricant! CLICK HERE TO FIND OUT MORE No More Promo's ...how 'bout stop F%$@ing spamming me!
Yahoo is a spammer favorite for dropboxes because their (decimated-by-layoffs-of-the-clueful) "abuse" desk is legendary for failing to nuke them even when presented with copious documentation which proves that, yes, they are spamming, and yes, they are using Yahoo.
Yahoo's mailing list mechanisms are frequently used for spamming because they allow the list-owners to forcibly subscribe victims -- and because, once again, the Yahoo "abuse" desk takes no action.
In addition, subscribers to Yahoo mailing lists can look forward to spam, because somehow, addresses that are subscribed to them but never exposed anywhere else end up on spammer lists.
And of course Yahoo Stores is a cesspool overflowing with spammers of all descriptions.
And then there's the nagging question of just how newly-created Yahoo accounts end up getting so much spam. It doesn't happen every time: but it happens often enough.
You can read about this in more detail than you'd ever possibly wanto know just by browsing Usenet's news.admin.net-abuse.email.
And so now Yahoo, which can't even come close to keeping its own house in order, is going to trot out The Cure For Spam.
I don't think so.
Yeah, I read Applied Cryptography a few times as well, and that doesn't make me a crypto expert. Bruce Schneier himself said "A colleague once told me that the world was full of bad security systems designed by people who read Applied Cryptography".
So, care to enlighten us about what exactly is wrong with their system?
How many AOL Chatroom members does it take to change a lightbulb?
Two. One to replace the lightbulb and one to make sure that the other person doesn't say "nipple"
Well I'm a Network&Telecommunications Engineer, and their plan makes a lot of sense and looks solid to me.
This is basically SSL tagging for emails. Have a mail server and domain, have your own private key, sign every of your email and they'll be distributed across the certified network. Abuse the system and your key is revoked/refused by the rest of the network. Don't have a key and domain, or forge the header to abuse your ISP's mail service ? No cookie for you.
Maybe we deserve this world ?
CNN link for your enjoyment. GoogleNews is your friend.
Maybe we deserve this world ?
If they're offering it for free, BEWARE. IT'S A TRICK. There's some hidden patent they're going to decide to enforce once the entire world adopts the architecture.
*waves hands ominously*
Seriously. This solution needs the cooperation of most. It is the exact solution I have been longing for, and to be successful when it is released it needs every significant domain to follow suit. Your ISP won't use Domain Keys ? Rant to them till they do ! They still won't ? Set up your own MX and sign in to the certified network. Have your friends and relatives get aboard too.
As soon as the certified network is considered a valid alternative to the current spam-ridden, scam-infested open email exchange system people will switch boards in a blink... provided it is easy enough to get a certificate.
Maybe we deserve this world ?
Would you rather choose a Yahoo product over an open standard that is under development? I'm speaking of AMTP, of course. (See AMTP author's site).
Yahoo's size doesn't give that much weight to their proposal. Yahoo's email is not used in business to business communication (do not count hot dog stands as businesses), so businesses can just aswell block everything that originates from *@yahoo.com if it is not directed to their consumer service department.
Also, reverse mx records provide much of the same benefits with minimal alterations needed to current email infrastructure. One DNS record added and small change in MTA software.
If Yahoo would really like to do a service to the internet community, they should rather consider looking AMTP and reverse mx records.
I joined two users too late.
- Generate a keypair.
- Upload the public key to some server (Operated by whom? It'll cost much bandwidth to operate such a server, and I guess the owner could be held responsible if keys are compromised (=stolen)). That's risky.
- Bind the public key to one or more IPs and one or more email adresses that'll be allowed to send.
So this will cause a hassle for those on dynamic IPs (like me) and in it's core it is mere PGP signatures additionally bound to IPs. So why not force everybody to use PGP in the first place?Tread softly because you tread on my dreams. -- Yeats
Under Yahoo's new architecture, a system sending an e-mail message would embed a secure, private key in a message header. The receiving system would check the Internet's Domain Name System for the public key registered to the sending domain.
If the public key is able to decrypt the private key embedded in the message, then the e-mail is considered authentic and can be delivered. If not, then the message is assumed not to be an authentic one from the sender and is blocked.
For every message, I have to check and unpack the header, go out to some PK server, and validate the keys, before I decide to accept/reject? That introduces a big latency into SMTP.
Also, this doesn't do anything to stop 'legitimate email marketers'. There's a death penalty (blacklist) for a site or particular sender's key, but nothing to stop a spammer from changing keys and starting over.
Or will everyone have to get their own key pair? Who's going to validate them, and at what cost per key pair?
This won't do a thing to stop spam, and imposes too big a burden on the infrastructure and on the 99% of us who don't spam.
sigs, as if you care.
Read: trusted network == commercial network
Why do you think this is in the "Money & Investing" department (see the linked article). No, this isn't for me. Businesses may well choose to use something like this for their communications, but they will not have the pleasure of communicating with me. While SMTP has its flaws, it still allows any IP host to send mail to any other IP host and that is a good thing.
To gain insight into what's going to happen with email and Internet communications in general over the next couple of years, you have to adopt a business mindset to see it from their eyes. There is a big problem (spam) hence a potential to make money. Various companies are going to try and cash in on this situation by offering a solution that might very well decrease spam -- some sort of commercially controlled communication network -- but this is definitely not in the best interest of the Internet. Of course, it's in the best interest of the company that's peddling the solution (duh!)
The Internet isn't Compuserve, or AOL. It's a network of IP hosts, and those are the entities which should have a facility for sending communications back and forth. There is no need for a central carrier for communications
The right question is not whether cycles are that cheap, but rather will you gain more cycles from spam reduction than you will expend in checksum calculation? Given the rising tide of spam, you don't need to reduce it much in order to make mail-signing a worthwhile proposition.
As to interoperability: during the adoption period, one would have to accept both signed and unsigned mail, but as soon as it becomes obvious that mail-signing is a way to get legitimate mail past ever-stricter automatic mail filters, and to the eyes of less and less patient mail recipients, I think you will see adoption of the new scheme take off. At some point it will be clear that if you want someone to take your mail seriously (or to even see it in the first place), it will have to be signed. That point will come when the major e-mail service providers start giving their subscribers the option of discarding unsigned mail automatically.
The proposal is very simple and most of the posts are just plain wrong about what it means.
All mail servers will have a public/private key of some type. The public key will be stored in the DNS system as extra data.
When an SMTP server connects to another SMTP server, the sending server will encrypt something (likely a checksum) with the private key for the domain the mail is from (likley the envelope from, not the From: header) and place it in a header.
The receiving server will then grab the public key for the domain in the envelope and verify the message is being sent by a server that is authoritative for that domain name.
Very simple. Now spammers can't send spam and make it look like it came from my domain. I'm currently getting flooded with bounces from a spammer doing this, so I really want this proposal adopted.
The implementation can be phased in, too. The mail server could add a header saying if the domain was verified and spamassassin could then adjust the spam rating of the message appropriately. Eventually servers would be configured to refuse mail from unverified domains.
So if you own a domain name, you just have to generate a key pair, add the public key to DNS, and add the private key to any SMTP server you send through.
Once this is required, you theoretically will always be able to contact a person responsible for the sending of the spam (whoever is listed in the whois database for the domain). Contacting them (or abuse@) would solve the problem with any major email provider, and you can just ban email from any small provider that doesn't give an adequate response.
Aside from the possible computational requirements for all the crypto work, I don't see any downsides to this. If by some chance a spammer broke/acquired your private key, you'd just generate a new one and update your DNS entry.
My ISP was a while back taken over by Yahoo, so my email now resides on 'website.yahoo.com'. And for that I pay them a decent 15 bucks a month. However, for my money I enjoy the pleasure :-) to receive 10 times more SPAM than regular email. Including multiple 141 kB "Microsoft Security Update" viruses per day.
:-(
When I asked Yahoo why they didn't do any SPAM filtering and even not deleted those very well known virusses, their reply was that I should upgrade to one of their small business offerings, which provide SPAM filtering as a service. Yeah, great!! One of my registrars (domaindirect.com), for which I pay $30 or so per year (!), throws in some email boxes for free and those even include some pretty decent SPAM filtering.
Which makes it very clear to me that Yahoo and other big ISPs, for whatever reason, just love the existence of SPAM. Probably they still make money by filling up all our email inboxes with garbage. So, let's not start with Yahoo as the big saviour of the world in the fight against SPAM.
Browsers shouldn't have a back button!! It's all about going forward...
It's good to see something like this coming from Yahoo. Yahoo is a reasonably neutral participant on the Internet -- they don't own an ISP (like AOL or Microsoft), or an operating system (like Microsoft), or their own mail client software (like, oh, say, Microsoft) -- so they won't feel inclined to lock particular parts of the world out.
It's in Yahoo's best interest for this to become an open standard. And I'd much rather see an open standard than something like Palladium become a de-facto standard that the free world can't play with.
Godspeed, Yahoo.
Tired of FB/Google censorship? Visit UNCENSORED!
It flags authentication requests sent from my TMDA system as spam. Way to go yahoo...fight spam by breaking other antispam solutions.
I say no thanks to your keys. You've been known to suddenly change your policies at will which to me says you can't be trusted.
A large "trusted-mail encryption" database?
Maybe the people at Verisign are drooling over the fact that they didn't think of it first!!
X-D
Yeah, I know we wouldn't be locked to Yahoo!, but I'm pretty sure they would have found a way to monopoly.
they should simply shut down,...
Press release is here.
The way the IETF and other standards bodies have worked is that some organization wouldtry out a new concept for a technology and once they feel the concept is working, they will create a Request For Comments (RFC) which allows others to implement and offer feedback. Over time the RFC gains support and ultimately becomes a recommendation.
This process was used to create the internet today, including all of the network protocols and services that run on top of it. Even SMTP was an RFC first.
Brennan Stehling - http://brennan.offwhite.net/blog/
Hushmail ( http://www.hushmail.com ) has been doing this for years. I've had an account there forever it seems, and am quite happy with the service.
What's great about Hushmail is there SpamTools. I haven't had a piece of Spam in my Inbox for over a year now.
As far as being secure, I have read numerous articles that point out that not even Hushmail itself is able to read my mail. It's a completeley secure infastructure.
Just my $0.02
Cook
From a home system to his mail server, nothing get's encrypted. ISPs that block port 25 forward the requests through their system and to his mail server where it's actually sent out. HIS mail server encrypts the message. Reciving servers then check the message based on the HELO or whatever. It only traces it back to the mail server it alledgedly came from. Not the person who sent the e-mail.
Even if the ISP is for some reason taking over the whole job of sending the e-mail, it's very trivial to set up RinetD (or similar) on the server to forward a second port to the SMTP server. That's what I use. I then set up my mail accounts that are for my domains to send mail to the SMTP server on the alternate port.
If he's trying to run a mail server on his own system behind a port 25 block he's breaking his AUP.
This doesn't negativly affect anyone who's running their own mail server. It only affects people who don't know how to configure a server.
Ben
Work Safe Porn
I think your first mistake is believing anything you read in Applied Cryptography. Its a well-known fact that Bruce Schneier is regarded as a leftist kook in the cryptographic community. Trust me, I got my PhD from UC Berkeley in cryptographic studies so I know what I'm talking about. Although we must give him credit for writing PGP, Mr Schneier has since then used his name to promote all sorts of snake-oil get-rich-quick schemes, and is a blathering font of anti-government propoganda. I'm sorry, Mr Schneier but had we not listened to your objections about such things as the Clipper chip installed in phones we may have learned about the 9/11 plot before it happened.
C - A language that combines the speed of assembly with the ease of use of assembly.
Whoah there! What you discovered is not a bug in qmail.
So what's new with this initiative? Isn't it just like digitally signed email? My opinion is that there's no need for Yahoo to do us users any favors, all that needs to happen is the price of digital signatures should drop to something more reasonable, like a few dollars. That sum can be worked into the ISP's fee, as the ISP is usually the one supplying the email. If everyone just had dig-sig then spam would never had been a problem in the first place. Also, smtp is ancient and should be replaced.
The power of Christ compiles you!
Why don't MTAs do a reverse lookup on the source IP of an incoming email, and reject it if the From: address domain and/or the HELO domain doesn't match the reverse lookup result?
The basic idea, as I understand it, is that the DNS for a domain holds a public key, and mail sent with a "from" address in that domain must be signed with that public key. That's an old idea, and not all that bad. You create your own public/private key pair; you don't have to buy a "certificate" from somebody. (I think.) If you control a domain's DNS info, you can send mail from anywhere with that domain listed as the sender, as long as you know the private key.
For the free-mail services, it's fine. All their mail is authored via web applications and sent from their own servers. Only the service has the private key. Only the outgoing SMTP servers need to know the private key. That's the Yahoo Mail case.
If you own a domain, you should have full control over your own public and private keys. But adding additional info to a DNS record is not well supported by most hosting services. If you're not running DNS yourself, you may have problems setting your public key. Hosting services have to support this.
Signing can occur either in the original user agent (the SMTP sender) or in a mail forwarder. It's easier to implement this in mail forwarders, but if you want to send using a return address other than the one of the mail forwarder you're using, your user agent has to know how to sign mail.
If you're downstream from an ISP and don't control a domain, the ISP owns the key for the domain and can control what they sign. That has implications. They might force you to use web mail, for example. Or run their client software on your machine.
Spammers can still register domains, run their own DNS, sign their mail, and spam. It doesn't really stop spam.
Your public key is now valuable, and a target for spyware and viruses. Expect to see viruses that steal public keys from (inevitably) Outlook and send them to spammers. Or just send spam from the attacked machine.
What this really does is provide a clear way to identify joe-jobs using addresses from major mail services like Yahoo Mail. That helps Yahoo more than anybody else.
If you RTFA closely, you'll see that the key distribution is an extension to your DNS server. It says "the receiving system would check the Internet's Domain Name System for the public key". Presumably it is up to each domain to publish their own public key. If MSFT takes over DNS, we have bigger worries.
Just before that, I'm hoping that the article got it wrong, and they meant that a token ecrypted with the private key is in the message.
i've notice this as well. it seems i'm getting more spam in my inbox as well. i believe that yahoo is capable of catching what is now seeping through, but they allow it (say if a random .30 then allow spam through) to try to make their advanced spam filtering from a paid account more desireable.
yahoo just wants us to buy mail accounts.
----
http://www.hellection.com
If we postulate a crackable DNS server, then many things fall apart. Anyone who cares to put up a public key for mail authentication is likely to care enought to keep their NS secured.
Yes spammers can and do have their own domains. The Domain Key provides accountability, not a panacea. It does help with the spam filtering though when you can verify that the mail came from the domain claimed. And the registrar theoretically can trace down the owner of the domain (assuming they didn't pay cash), so you can leverage some of those anti-spam laws.
I don't know if anyone's interested, but over the weekend I put together a white-list, white-phrase, auto-response human-sender verification system which has been 100% effective so far. Meaning that everything it identified as spam was (which in now bounces instead of holding for my perusal) and every email from both human strangers and machine generated email from companies I wanted to hear from got right through. I wanted to write a program that would do this automatically for my web host, but even though it wasn't an option (they used off the shelf Ipswitch software that they couldn't reprogram), I was still able to set it up using existing filters. Which means you probably can too.
If you want to know how it works, either to use it or to find a flaw, say so and I'll post the specs.
FYI, here are the (4) proposals that I know about:
RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).
DMP - No change or update since this was posted back in August 2003.
DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.
SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.
Anyone have any inside track on where these proposals stand?
Wolde you bothe eate your cake, and have your cake?
how will this affect anything? i mean if there is no third party signing them (if there was it would mean that even running your own mail server would cost alot of money probably) whats to stop them from regenerating new keys? and whats to stop them from changing domains too?
Is this the deal where the sender gets an email back asking to authenticate? I work in customer service get a lot of emails like that. I usually authenticate, but not always. You could prevent yourself from getting a lot of important stuff. Like e-bills or other automated stuff. I'd never use it.
(If you doubt this, consider the way things are going with ASRG.)
Meanwhile, someone who skipped the design-by-clusterfxxk step will quietly crank out a foundation to build upon, leaving the squabblers behind. With any luck, a few people will crank out a few options.
Discussion is good, but there's a hell of a lot to be said for implementation, and the real-world evaluation of functioning implementations.
On the other hand, this significantly increases the resources needed to deliver and receive e-mail. Not only is more processing time needed, but significantly more bandwidth as well. Every single e-mail message, including NDR's and warning messages, would have an extra hundred bytes (guesstimate) for the key in the header. Plus the MTA's would need to do additional DNS queries in order to look-up the keys.
Sure it's a pretty small increase in resources on an individual scale. But when an ISP is processing 100,000 messages a day it adds up. Overall it means more e-mail would be delayed.
One could hope that the trade-off in extra bandwidth and CPU resources would balance out with significantly less spam. But Spammers have already shown their willingness to do anything illegal to get what they want. Breaking into servers to steal private keys would certainly not be above the ethics of spammer, nor beyond their technical abilities. Sure they may not be able to break into Yahoo's server, but Joe Sixpacks home-business server?
Here's the other big gotcha with this scheme... Assuming this is done at the level of the domain names and not just the MTAs, we could see a situation arise where users wouldn't be able to send e-mail out except with the domain name of their ISP provider. Right now I use RoadRunner's SMTP server to send all my e-mail but I'm not using my RR e-mailboxes (except to collect spam). Of course this is why spam is so easy to do in the first place... the SMTP server doesn't attempt to validate my username OR domain name.
Maybe the aim for "Domain Keys" is to allow the MTAs to verify each other's identities and won't rely strictly on the domain name. But would it hurt Yahoo! or AOL if users of their networks were locked-in to using just their e-mail addresses?
In the darkness of future past, The magician longs to see. One chants between two worlds, "Fire, walk with me!"
Public keys aren't valuable. They're already public. Spammer can get them from DNS. The only thing they can do with is encrypt something that only you can decrypt.
Your paragraph makes more sense if you were talking about private keys. This is always an issue with private key crytpo, it only works as long as the private key is kept private.
End of Line.
It would be possible for the spammer's ISP to ignore the incoming mail. But then a legit ISP that couldn't deliver mail to such an address could then refuse all further incoming mail from the spammer ISP for some predefined time interval (say 4 hours). This would help to limit spammers but not legitimate mail hosts that might have got somehow used.
Spammers using viruses or worms on other machines won't do much better - they'll have to at least enable incoming smtp on the machines and any firewall along the way would need to be set to allow incoming smtp, or the outgoing mail would be refused (by the above).
The sender has to have the private key, and that's vulnerable on the sender's machine.
If a change is going to be made why not make a simpler change that works as well? Instead of encrypting anything why not simply have a DNSWL - a DNS white list? You get on to the list by adopting a policy that prevents spam (and get thrown off if you later allow spam.) If you're on the whitelist you're trusted. No decryption overhead, and you should be able to skip all filtering for email from whitelisted sources, saving additional time.
There's even variations of the idea that could automate adding (and removing) IPs on the white list (which probably would then have to be a cooperative venture.) Remember that you don't need to block every single spam message to kill spam - just block enough so spam doesn't pay. The point of view isn't the false "if one spam gets through the system has failed" but the accurate "if 99.9% of the spam is rejected the system succeeds." Probably it doesn't have to be 99.9%, either.
Obviously, don't drop other countermeasures until spam is dead - and then be vigilant forever.
Thinking about how to survive with a permanent spm problem hasn't worked - it's time to think of eliminating spam. That's a different thought process (it won't center strictly on action at the receiving server and beyond) and should expose many possible modes of attack.
(Re: spam doesn't pay. Yeah, I know - the spammers sell spam services so they get paid even if the buyer loses money. That's only for a while - the buyers will run out of money eventually. And I doubt there's an infinite pool of potential buyers.)
It makes me think about the fuws.org mail service.
Users have to be authentified at least once before to send an email to your account. But they don't use keys... This authentication system is only done through http.
Yahoo, annoying Yahoo. Viewing a Yahoo group causes my browser to be force fed 2 cookies before logging in, and 4 more before I get to the first message. So whaddaya spose we'll have to eat to use their anti-spam creation?
-Turnip Onion --- Neither micro nor $oft. Linux is a fine tool.
I'm not actually sure that what they're talking about is a digital signature, or at least not a signature of the message. I don't get the impression they are sending a function of the message content, but instead guaranteeing the bona fides of the sender. Perhaps there's actually a way to do this without a new encryption for each message: send a certificate that says IP address a.b.c.d is known to belong to host ABCD and that host is believed not to condone spam. Others can't reuse it from a different IP address since the 2-way communication would break.
Mencken had it right. So glad that's old news.
Here's an article that gives an overview of doing this with smart cards.
End of Line.
While authenticating smtp servers will prevent some spam, why invent a completely new system? Use ordinary certificates and STARTTLS to authenticate mail servers. My company has been doing this for 3 years. It's a well defined, well known standard available on most MTA platforms, with strong cryptography and backwards compatible with normal SMTP. You would have to get certificates from a CA, but Instant SSL will sell you certificates for US$50.
Combine this with "sending MX" DNS schemes, and you make make a big dent in spam.
Yes, it won't stop all spam, but will catch a lot. For example, my company's SMTP server is configured to reject email that doesn't have a valid domain in the "From" line. Even though it's trivial for a spammer to fake the "From" line to a real domain, over 500 spams per day get blocked from this.
Personally I think digitally signed email standards is a horse race with most of the horses being invisible.
I wouldn't bet on Yahoo being the winner,
but I would be happy if they at least crossed the finish line.
-- this is not a
Could you imagine this becoming really popular and then Yahoo! getting bought by someone like oh say Microsoft? (or any other big commercial interest)
My dear god. Can any thread on Slashdot last two messages before totally unrelated Microsoft dissing? Oh how smart, real smart discussions around here.
OpenBSD ships with spamd.
I'll try not to duplicate my very recent detailed post on qmail-spamthrottle.
Basically, hosts/networks are tracked by messages/second, and rate-limited by slowing down response time to RCPT commands.
Works a treat against dictionary attacks.
I do not deploy Linux. Ever.
It seems like Yahoo's proposal will allow alternate/fake 'From' addresses to still work - it just depends on the policies of the sender's ISP. It requires the sender's SMTP server to digitally sign each email it delivers - the receiver can verify those signatures via public keys stored in the DNS.
So if the ISP of the person who created the email is OK with his 'From' address, it will sign and deliver the email to the receiving SMTP server (mail transport agent). The receiving SMTP server then verifies the signature from DNS records. So it is really a transport level (not sender-level) verification.
This way, email-forwarding (which is quite useful) will still work. I believe this may also be a requirement for organizations that delegate mail delivery to servers in different domains (eg: mail from 'john.smith@att.com' delivered through 'attmail.com') or outsource their email management to other companies.
So I believe the important thing about this proposal is not sender verification - it is the digital signature - evidence toward non-repudiation of sending the emails that can stand in a court of law.
The intriguing thing is the requirement for the signature in the header of *each* email, rather than in the *SMTP* protocol exchange itself. If the signature was sent at the start of the SMTP protocol exchange, (perhaps in HELO
However, since Yahoo's proposal puts the signature in the header of *each* email, each email *client* (mail user agent) can now do the verification with a simple DNS lookup, and has evidence for non-repudiation available to it - intriguing. So a plug-in for Outlook or pine could do the non-repudiation check.
Of course, the signature means that the sender's *ISP* (not the user) cannot deny that the message originated from it - at least it cannot repudiate that without updating it's public/private key pair (which will be logged in DNS caches around the world). Depending on the sending ISP's policies, this could be the basis of non-repudiation of authorship of the email.
Seems like we're moving toward a world where you can't send email unless you:
So no more "cool" demonstrations of "telnet port 25" to show how easily email can be forged.
Unfortunately, Yahoo's solution probably won't help much. The bar for spammers is raised only a little - they may now have to spend double the money they spent earlier. This is why I think so: up until now, a spammer only had to control an ISP user account - then spam and ditch the account. Now they have to control a user account, and a domain. With prices for both being identical per spam/ditch incident ($30/ month for user account, $30/year for DNS entries), their costs double at worst. The costs for generating the public/private keypair, cryptography, are essentially zero, being done open-sourced software. Safeguards like checking the age the domain as per whois records can be defeated by the spammer bulk-buying domains, keeping them 'dormant' for a long time, then using them up one-by-one.
The only solution to spam is generating a fresh email address for each end-party that you communicate with. When one address is compromised, send an email notifier to the end-party saying the address used to communicate with you is changing (the end-party would need to authenticate this). Then ditch the old address.
Bruce Schneier isn't always right, and he's often more than a slightly alarmist, but he's a more reliable source than pseudonymous slashdot users from Berkeley.
I do not deploy Linux. Ever.
It's actually a pretty simple variation of the white-list approach, and frankly I'd be surprised if no one else had ever tried this. But it just makes more sense to concentrate on describing the emails you do want. First, because it's always easier to describe a smaller quantity than a large one. Secondly because spammers are adaptable, and can easily avoid sending an email that looks like "spam", but they can't easily send one that looks like it was sent specifically to you, because all they know about you is your email address.
I think the best way to describe exactly what I set up, is to tell what abilities my email server actually has, and how I used those few abilities to eliminate 100% of the spam I'd been getting.
The email server software is off the shelf Ipswitch stuff, which my webhost (HostMySite.com) makes available to it's customers through a web interface.
-You can set up "Filters" through which email will pass. The filters only allow to look at one of the 6 fields, Subject, To, From, Sender, Header or Body. Within that field, you can say it either contains or doesn't contain a list of words or phrases (which unfortunately must be manually typed in). When an email meets the condition you specified (ie, the "From" contains "@Slashdot.com"), you can then take 1 of 5 actions: "Move the message to this mailbox", "Send with Copy to", "Forward the message to", "Bounce", or "Delete this message". You can specify as many filters as you want, and they will be run in sequence (ie, if an email triggers filter #3, it will not be examined by filters #4 on down) However, it's important to know that an email can only go through one filter in it's lifetime - so if a filter forwards an email to another mailbox or email address, it will NOT be subject to any of that mailbox's or email address's filters.
-You can set up as many email addresses as you want, or mailboxes (ie subfolders) for a given email address as you want.
-You can set up an autoreply, with the option of having it forward any emails to another address.
1. The first thing I did was to set up two email addresses, "Me@RandyHamilton.com" and "Spam@RandyHamilton.com". I deleted the "webmaster@RandyHamilton.com" address, because that would act as a catch-all address, and I need the ability to forward emails to a non-existent email address in my domain so I can generate a bounce message in some situations. In the "me" address, I set up a mailbox subfolder called "verified", and I set my email program, Netscape Mail, to only look at that mailbox (the Inbox mailbox will be empty).
2. On the "Me@RandyHamilton.com" account, I put filters which first check for the word "FuzzyKitty" in the subject line, then to see if the From address contains any of the full or partial email addresses I specified like "Girl123232@hotmail.com" or "@thinkgeek.com" that I got by exporting my "Collected Address" folder from netscape mail, and finally to check the body of the email for my full name, or phone number, company, bandname, ect. If an email meets ANY of those criteria, it is moved to my "verified" mailbox. If it does not, it hits the last filter on the list, which will forward anything with an "@" symbol in the email address to "spam@randyhamilton.com"
3. The "Spam@RandyHamilton.com" has an autoreply which, whether an email came to it directly or was forwarded, will respond with an email asking the user to write back with the word "FuzzyKitty" in the subject line, and it then forwards the email it received to the non-existent address of "boing@randyhamilton.com" which will generate a bounce message. Note that when I first set this up, I didn't forward the emails in this way because I wanted to look at them and make sure they were all spam before bouncing them.
4. The spam@randyhamilton.com has 2 filters in addition to the autoreply. The first forwards anything with "FuzzyKitty" in the subject line to the "verified" mailbox of Me@RandyHamilton.com", and the second bounces anything with an "@" symbol in the From
I understand all this crypto talk, although I believe inventing new stuff just for the sake of having your own name on the rfc is just plain silly as there are many well-thought out ones out there (dnssec?).
But where does it leave us? So we have signed mails. How would that help us with spam?
What most people forget is that spammers already violate a handful of acceptable use policies with their ISPs and probably a couple of local laws as well. They break into systems, write viruses and exploit a non ending stream of Outlook bugs to do find and create open proxies (and relays) to do their dirty work. These are guys that register 10 companies at a time and buys internet lines, domains and web sites in bulk. They are already crooks.
A system that scales to Internet wide use would not make it any harder for the spammers. They would attach the needed signatures to their mails just like today.
The sad thing about it all is that any crypto anti spam system would seem very effective at first, until most people have it and then it does no good at all. Then we are stuck with an even more complicated protocol to send e-mail than today for no good reasons as nobody can be the first to leave it.
I see only one scheme based on cryptography that would work to reduce spam: Use trust network signatures. I am speaking of course of pgp. If the sender has a trusted signature path to your keys, it is most likely non-spam. No other scheme would scale to full Internet use.
Yahoo positively should shut up when it comes to mail.
I run online games and other sites where you sign up using your e-mail. There are 2 services which suck so much that I've banned one (hotmail) and contemplate banning the other - yahoo.
They just don't cooperate well. For example, you can't verify if an address actually exists at yahoo. They will accept any and all mails up front.
Yahoo should go and implement the existing standards first, before they go and invent new ones.
Assorted stuff I do sometimes: Lemuria.org
You don't have to block ALL spam from the beggining.
;)
You just have to lock-out spam-mail after a certain treshold, after serious amounts of users have reported e-mail from that domain as "spam".
If the "enemy" spammer keeps changing domains, it wouldn't be so hard to link IPs/MACs with domains if they just keep registering new mail domains on same machine to override it (hard enough), let alone having to switch machines for new domains.
Ihe ideea is to REDUCE spam significantly, not downright eliminate it...
What bothers you more?
"You have 5 new messages, 5691 in bulk mail"
or
"You have 5696 new messages"?
hehe
By reading this signature you agree to not disagree with the post you just read.
...you really need to get a life.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
I do something similar every time I give my address to a web site, and what's surprised me is that they don't lead to spam. The only spam I've ever had from filling a form is a site newsletter - relevant, clean, and identifiable - and that's only happened a couple of times. I've never had any 'real' spam via that route; it must all be from a handful of usenet posts from years back, and a couple of people who had my address on their web sites until I spotted them and asked them not to.
Ceterum censeo subscriptionem esse delendam.
I agree that there is a serious problem with the lack of overhead argument, but lack of cost for CPU horsepower is not it. I have heard estimates that 50% of all email traffic is spam. To counter this flood of spam, most companies are starting to use spam filtering. CPU hosepower might be cheaper than before, but "everything counts in large amounts" and spam is getting larger and larger. Is it cheaper to check every message against an ever increasing set of rules, including checks for patterns, or to just check the message header for a key and to process that key. Once that key is processed all messages from that server could be (more) trusted, at least for that session.
The grass is only greener, if you don't take care of your own lawn.
> But ultimately one has to worry about the lock that Yahoo! might have on servers once they get it installed all over the place.
?Could you imagine this becoming really popular and then Yahoo! getting bought by someone [...]
Or for that matter, someone encouraging/forcing Yahoo to insert trap doors into it for their own purposes (aka Home Security, UN, or some other group).
Dear irc.xchat.org morons, what will you do to find and moderate my posts with -1 stuff if I send in another name?
Its a real funny claim to tell Yahoo doesn't know about security since they have like 300 milllion users. I repeat it. Moderate this down for fun too...
I believe slashdot did everything to prevent abuse but none of coders believed such childish morons would be here.
They would probably count that as a win.