Slashdot Mirror
Email Authentication Schemes - Friends or Foes?
jtprice writes "At a time when spam levels have exceeded 80%, there's growing momentum behind
Microsoft's email CallerID,
the SPF
effort, Yahoo!'s
DomainKeys, and the IETF's new MARID Working
Group initiatives to address various email abuse problems including spam, joe-jobbing,
phishing, and so on. Sendmail has already implemented DomainKeys and CallerID. 10,000+
domains have turned on SPF now. Where the heck are we going with this? Are these efforts at cross purposes, confusing at best or likely to be consolidated? Seems to be less about the end of spam and more about the end of open, uniform, standards-based email as we know it. Apparently the people behind these initiatives are getting
together for the first time for something called the Open Email Accountability Symposium next month, at the Inbox Email Conference in San Jose, with the intent of outlining their proposals and answering questions. Any thoughts about all of this, or hard questions that should be asked of these people? Is the email dilemma creating
just another monopoly opportunity to force email into proprietary territory?"
I think spam filtering should be left up to the user.
There are plenty of client side systems that work well; I use Apple's Mail. Maybe 2 spams a day gets through to my main inbox (out of several hundred incoming spams a day).
Even if we could completely revamp SMTP, it still sits on top of TCP/IP (etc.)
Not exact. If we are revamping there's no need to sit on TCP. It may be TCP or UDP or something completely new. Or it may be even just be a non problem.
- If the protocol assumes a connection and does not depend on it being anything in particular (technically: if it's an appllication level protocol), than it'll sit on any connection oriented protocol. That's exactly what the ISO layering is supposed to mean.
- It is possible to design a completelly new connection layer protocol. TCP is having it's own problems. True most of these have been addressed with a handfull of extensions. Reno is good and Vegas is even better. But big speed*RTT links are still problematic. And links are going to become much faster and with possibly bigger RTTs. We should not abandon TCP. But maybe we could start thinking alternatives.
and there will still be ways to get around any protections we could add to SMTP.
There'll always be ways to get around anything, probably. Down this line of thinking there's no solution at all. But we may come to a point where getting around is not worth doing.
I think it will take some major overhauling of the Internet and its core protocols to solve this problem.
Ageed. That is exactly the point in my post. But if we take that lane, we may get extra benefits. Mail-ng need not just be mail. We may think messaging here, instead of mail. Mailing lists can be designed in upfront. And news too. Maybe even chatting and instant messaging. And did you notice people is now using SMTP to do what FTP was designed for (remember FTP supports push and even sidewise transfers, even if today it's mostly used in pull mode)?
And that means lots of work, lots of new equipment and lots of new applications, all at enormous expense.
Maybe. Maybe not. We should keep those possible consequences in mind. Lots of work in SW development may be a non problem (not for the F/OSS community, at least. I do not care what that means for an individual company that's not going to share). Lots of equipment I doubt. If we can sit on IP and care not what version of it is below us, than the routing infrastructure need not change. The firewalling/natting/tunneling part may need some fixes. But these are mostly SW and generally very close to the endpoints, not really a big deal if we are doing a revamp. Expenses? Again: SW upgrade at the endpoints is not a big cost. Not if you are on the sharing side of the fences. It is not zero (not for large companies with thousands of servers and more clients, for example). But it needn't cost more than any other SW upgrade.
none of it possible until all the protocols are reworked, let's say, five years from now
This sentence is the one I agree upon. That's what I worried about in my post. This may take time. And the problem is now so much urgent that people may be unwilling to wait. The worse that can happen is a partial solution. It would slow down a revamp (NAT slowing IPv6 is an example. And we risk the mail 'solution' is much worse than NAT is).
Sorry if this is really OT but ... ...
I just was curious to see if Eric Raymond had some post/opinion on this subject. I went and checked it out and
Anybody noticed he's *completely disappeared* after posting "The Luxury of Ignorance: Part Deux" on february 29?
No more posts on his site. Neither in the writing section, nor in the blog. Cannot google out any reference to a travel or something. Nothing.
And looking at his back records, he's not used to being so silent for such a long time. Expecially not if we consider what's happened in this months. Not a word on MS vs. european antitrust. Nothing on latest SCO news. Nothing on the euro-patent issues.
Where's ESR?
Check this one:
..."Internet Mail 2000" ... no really. :^) Basically, you (user) don't receive the email. You receive a notification: "your email is available". Now: you have to download the email from the site that notified you.
...but, this scheme has the potential to conserve enormous amounts of bandwidth internet wide (mail is "fetched if desired", not "sent no matter what"). If too many reports of spam are coming from a particular server, blacklist that server. Boom. There are a finite # of IP addresses on the internet, and forcing a spammer to maintain servers so their messages are successfully delivered should eventually drive them further and further out of address space.
... use email! ;^)
... totally painless transition (apart from vulnerable browsers), until mail programs can be re-architected to fix it. ( if: is_im2k(): fetch( $url_from_message )
http://cr.yp.to/im2000.html
Imagine: I am a spammer. I must now host a server which has the capability to receive $millions of hits from all my wonderful spam-receiving customers. This is the first thing which begins shifting the burden of sending of email back onto the sender.
Obviously it's not perfect, if I were a spammer, I'd probably have all my malware-infected robots be the hosts for sent emails. Buuut... they'd only be active when that malware-infected computer is on. Notifications could obviously be cheaper to send (b/c it's not so bandwidth intensive, just "hey, joe@joe.com has an email available at bob@spammer.com/msgid/12345/hash-password/a1e2ff"
This speaks really to "trust v. ip address", how much do you trust a residential DSL IP to deliver mail? (not much). How much do you trust Yahoo Mail's IP? (a lot, all kidding aside).
So, what's the transition? Since it is such a drastic change (rather than sending mail, sending notifications), and directly impacts $zillions of installed mail clients, I couldn't wrap my head around a valid transition path until it hit me
Since most mailers nowadays support highlighting of http links, just send "Subject: regular", but make the body: "Internet Mail 2000 message. http://sending.server.com/msg/12345/hash/abc123"
Anyway, think about it.
--Robert
Imagine: I am a spammer. I must now host a server which has the capability to receive $millions of hits from all my wonderful spam-receiving customers. This is the first thing which begins shifting the burden of sending of email back onto the sender.
The problem with this idea is that, on a per e-mail basis, spammers actually need fewer resources than non-spammers. Compare a spammer whose domain sends 1 Million e-mails a day, and a legitimate domain who also sends 1 Million e-mails a day. For the legitimate domain, most of the e-mails sent will be unique, most will be read, and it is probably vitally importatnt that the readers be able to access the sending server at all uptimes. This means the legitimate domain must maintain a mail server which can store millions of messages, which has a very fast connection, and which has a very high availaibility. The spammer, on the otherhand, is going to send out many copies of the same message, only a few of which will actually be read, and really doesn't care if his server is down for a few hours (after all, the same suckers who read the e-mail the first time will probably read another spam sent to their address). As a result, the spammer can get by with much more basic hardware. Which brings us to the second point:
if I were a spammer, I'd probably have all my malware-infected robots be the hosts for sent emails.
Here we have the basic hardware. Since the spammer doesn't need much storage, the user won't notice their computer hard-drive is filling up. All they will notice is that (if the spammer is successful) their connection is slower than normal. This will probably be blamed on the p2p software of the week the user's teenage daughter installed.
Come test your mettle in the world of Alter Aeon!
HELO/EHLO wants a hostname, and usually one that can be resolved to the address that the connection is from
What about this ?
From (in SMTP), From, To, CC, etc in RFC822 expect either UUCP routes
What about this ?
Of course those links may be wrong. I'm no big expert. Surely they seem convincing.
Cisco not supporting something (relevent to their product line) means it wont become wildly used
This is sadly true. And that's probably a sign CISCO should either make an extremely strong public commitment into early availability (even before the standard is actually a standard) of new protocols or be ready to face antitrust the way MS is doing. Or both. And wether the aforementioned commitment is done making the platforms totally open or investing in-house for development that may never turn out to be required is not my problem (but I have an opinion).
New things happen on the edges.
Amen!
Five years is a very short period of time
True. I did not make that number. Just refused to comment. But since we are at it: I think that 10 to 15 years for the new generation mail infrastructure is more likely. And that's exactly one of the problems as many will not be willing to spend 4 or 5 years just for preliminary talks. They want spam killed now. And will, sadly, be happy with half baked (non)solutions.
There are two obvious reasons.
1. Very few people know about it.
2. Assuming that www.openpgp.org is the home page for this then there is too much digging for most folks to bother installing it.
Here are some obvious questions I couldn't easily find answers to.
1. Does it work with Kmail? (which I use at home)
2. Does it work with Eudora? (which is what I recommend for my windows using friends/family.)
3. I have a few Mac using friends, will this work for them?
4. Does it work with my ISP's java based email client?
5. Does it work with my free webmail accounts?
If it can do all that then it can handle all of my email needs.