Email Authentication Schemes - Friends or Foes? 54
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?"
It's worth it... (Score:4, Insightful)
Perhaps, but this doesn't make it a bad idea. Any good idea or technology can be taken advantage of; that in itself shouldn't keep those with good intentions from trying to bring about change for the better.
Re:It's worth it... (Score:2, Insightful)
This would have been first post.. (Score:2, Funny)
It still won't work (Score:2, Insightful)
Re:It still won't work (Score:5, Insightful)
Open standards and peer review are profoundly *good* things.
Re:It still won't work (Score:3, Funny)
Umm...
Re:It still won't work (Score:3, Informative)
Most email currently goes through Apache . . . I think that the open sorce community has done a pretty good job of creating the email server of choice. I think that they're probably the right group to also make it more secure.
To clarify someone's "ummmmmm" comment -- this is some sort of weird troll, right?
The Apache Software Foundation [apache.org] does support a project known as James, [apache.org] a "pure Java SMTP and POP3 Mail server and NNTP News server, but ummmmm...well, not a whole lot of people use it.
Are you perha
Re:It still won't work (Score:2)
Or else, it was just a typo over "email" meaning "http traffic". Because of greater fragmentation of the smtp server area, and greater specialisation of some of the parts, as well as several interpretations of much more complex standards(IMAP is certainly a standard with an awful
no real solution on the orizon (Score:3, Insightful)
IMO there main alternative is:
1) a solution compatible with original RFC (that is it does not rule out any sender that the original spec would permit)
2) a completely new and different system. Redesigned from scratch.
Obviously a solution is not a solution if it may have a false positive (block nonspam).
False negatives are just a matter of efficiency.
Methink option 1 is not possible. And this has the added bonus of giving us the chance for a visionary change. But it's unclear if we can afford the time it takes. As the problem is really becoming urgent (much more urgent than the 32bit limitation in IP adress space. Expecially because NAT is addressing it very well.)
There are MANY proposals that use SMTP and add up on the requirements actually ruling out cases that were originally legal. These I really think should be avoided. But I'm affraid that's were many will likely go because they are fast to deploy.
Re:no real solution on the orizon (Score:5, Insightful)
1) a solution compatible with original RFC (that is it does not rule out any sender that the original spec would permit)
2) a completely new and different system. Redesigned from scratch.
Even if we could completely revamp SMTP, it still sits on top of TCP/IP (etc.), and there will still be ways to get around any protections we could add to SMTP.
Unfortunately, I think it will take some major overhauling of the Internet and its core protocols to solve this problem. And that means lots of work, lots of new equipment and lots of new applications, all at enormous expense.
So, what's worse, loss of bandwidth, over-burdened mail servers and everyone spending time deleting junk out of their inboxes, or everyone spending a significant amount of money, users for new e-mail programs, companies for the same programs, new mail servers and routers, ISPs and backbone providers for expensive new infrastructure, and none of it possible until all the protocols are reworked, let's say, five years from now?
Re:no real solution on the orizon (Score:4, Interesting)
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).
Re:no real solution on the orizon (Score:3, Insightful)
Prehaps that is what it is supposed to mean, but two things
- IP and friends came out long before ISO and their layer model. IP is based on the DOD model; and while DOD has less layers they dont exactly match up. Not really important, however
- SMTP uses
Re:no real solution on the orizon (Score:2, Interesting)
What about this [tesco.net]?
From (in SMTP), From, To, CC, etc in RFC822 expect either UUCP routes
What about this [tesco.net]?
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 commitme
Re:no real solution on the orizon (Score:2)
Off topic, but... (Score:4, Insightful)
No, no it's not. NAT is a quick-fix that just complicates matters.
Re:Off topic, but... (Score:1)
Re:Off topic, but... (Score:2)
Oh? Try using VPN a lot and pulling your hair out because of address space collisions.
Re:Off topic, but... (Score:1)
Yes, I know. There are providers with routing that is not sufficiently transparent to let you VPN even between public IPs. But it's mostly broken configurati
Re:Off topic, but... (Score:2, Flamebait)
IANA should have the authority to reallocate addresses as a method of punishment. I.e., deallocate all of Nigeria's address space.
All of Africa, and most of Asia, for that matter.
Re:no real solution on the orizon (Score:3, Interesting)
http://cr.yp.to/im2000.html [cr.yp.to]
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 sende
Re:no real solution on the orizon (Score:3, Insightful)
The immediate down side I can think of is that the sender knows (by observing their web server logs) that you received and read that message (or at least that you received it with a POP3-equivalent offline mail reader, which would
Re:no real solution on the orizon (Score:1)
Eh? Just because somebody or something goes to fetch the "sent mail" doesn't mean that the mail is read by human. I don't care if the message is send directly to me or via some hosted
Re:no real solution on the orizon (Score:3, Interesting)
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 legiti
Alternate Solutions (Score:2, Insightful)
Spam Filters (Score:1, Interesting)
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).
Client-side filtering should be last step (Score:4, Insightful)
No, client-side spam filtering should be the last line of defense against spam. Spam should be killed off before it ever reaches a mailbox, final or intermediate, by the servers that handle the mail.
Re:Client-side filtering should be last step (Score:1)
SPF rules.
Dude, what are you smoking? (Score:2)
Are you paranoid?
The proposed solutions are [for the most part] standards based and they're also "open" in nature.
Personally, I'm going to orient my servers toward the IETF/Marid standard; but you have the "freedom" to choose and implement whichever standard you choose.
The fact that a pseduo-"standard" is being settled on in this realm is progress (in my opinion).
The question answers itself (Score:3, Insightful)
This article is just making something out of nothing.
Re:The question answers itself (Score:1)
The problem has no solution ... (Score:2)
What do we expect:
1. To be able to send email from anywhere
2. To be able to use various "from" addresses, irrespective of from where we are sending.
3. To be able to cheaply register new domain names. The problem can only be solved if we accept limitations on how we send email.
The fundamental problem is not authentication. A spammer can easily set up a valid domain name and use it to send email "from". The cost of this is minimal (an *.org.uk domain is about
Re:The problem has no solution ... (Score:1)
What do we expect:
Defining the expectations is a big task by itself. Those doing some serius work on it identifyed many many different requirements. And of course many of them are contradictory.
The fundamental problem is not authentication. A spammer can easily set up a valid domain name and use it to send email "from". The cost of this is minimal
Traceability. Autentication. Anonymous posting. Privacy. Each of these is a research task in and by i
CallerID for email boycott (Score:3, Insightful)
Stick to SPF, give DomainKeys a try once someone actually publishes some info about it. Skip caller ID.
PERHAPS: (Score:1)
OT: were's ESR? (Score:1, Interesting)
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
SPF is Email Authentication (Score:4, Informative)
As SPF adoption grows, there will be two types of email: authenticated and unauthenticated. Authenticated mail will consist of both spam and legitimate mail. Unauthenticated mail will be just like the mail we are sending around today.
What does authenticated mail get us? As we can track mail down to the owners, we will begin to set up a trust system. DNS block lists will become viable. The owners of domain names can protect or abuse their domain names as they see fit.
Eventually, there will be a system where domain names will have value again. If I don't abuse my home domain, and only use it for legitimate purposes, people will not add my name to black lists. If my domain has sent a large number of emails with a very low score of spam, it will be more legitimate than one who has sent only a few emails or has sent mostly spam.
SPF is only the first step in stopping unsolicited email. Once it is in place, the next step -- accountability -- is easy to implement.
The beauty of SPF is that it doesn't invalidate email as it is now. Participation is optional. Those who are early adopters get an early boost, so the incentive is there to adopt it early on. But email as it is now will not be stopped.
Re:SPF is Email Authentication (Score:1)
"If my domain has sent a large number of emails with a very low score of spam, it will be more legitimate than one who has sent only a few emails or has sent mostly spam."
What happens when $VIRUS turns your domain name into a spamfest? If you're supporting any normal users at all, you're likely going to find it hard to maintain that reputation.
Re:SPF is Email Authentication (Score:3, Insightful)
> into a spamfest?
You get blacklisted, as you should be.
> If you're supporting any normal users at all,
> you're likely going to find it hard to maintain
> that reputation.
Securing your domain is your responsibility.
Re:SPF is Email Authentication (Score:2)
What's wrong with OpenPGP? (Score:2)
Re:What's wrong with OpenPGP? (Score:1, Interesting)
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
OpenPGP plugins (Score:2)