Welcome:
Login
|
Sign Up
|
About CircleID
Follow:
|
|
|
|
||
|
||
As most CAUCE supporters already know, forging ‘From:’ or other commonly seen email headers is trivially easy. It’s one of the most frustrating oversights in the creation of Internet email technology—though of course that’s only obvious in hindsight; it was just fine for the pre-Internet networks of the late 1970s and early-mid 1980s.
Since then, things have changed—and the most interesting recent technological advancements in email have been in the realm of sender authentication, which encompasses ways to verify that the apparent sender of a message actually is the entity which sent it. Before you can answer the question “can I trust this message,” you have to ask “who sent it?”—but before authentication, there was often no way to know for sure.
The first authentication technology to catch the interest of the industry was Meng Wong‘s SPF, which also formed the basis for Microsoft’s SenderID. In parallel, Yahoo! developed DomainKeys, which has now evolved into DKIM. All of these are free to use, though some have licensing requirements or patents which may prevent derivative works.
Having what looks like four entirely different technologies may seem confusing, and marketing tactics from some of the organizations involved certainly haven’t helped. Luckily, our friends at the Messaging Anti-Abuse Working Group have published a new white paper, Trust in Email Begins with Authentication [PDF], which should help to clarify things. It provides a much-needed substantive overview of the authentication methods and practices currently in use, without inappropriate bias or attempts at coercion.
CAUCE hopes that this effort will raise the level of debate within the email industry, and lead to faster adoption of authentication technologies. Sender authentication will not, obviously, solve spam—it has very little to do with spam, in fact—but curtailing the bad guys’ ability to send messages that look like they’re from your bank or other trusted institution will certainly help.
Some CAUCE Board members—including the author of this article—contributed to the MAAWG document, and are regular attendees of MAAWG events.
Sponsored byCSC
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byRadix
A World-Renowned Source for Internet Developments. Serving Since 2002.
Authentication without trust is a waste of time.
This was demonstrated by spam forming the majority of email passing SPF checks early in SPF life.
In the case of SPF some limited trust is/was indirectly provided by the DNS, to at least certify the ownership of the sending servers.
We are seeing interesting trend to a lot of our Spam email being from Google/AOL/Yahoo.
This I guess raises the issue of where trust should reside.
I think the large email providers must aim to push “trust” to the individual as their email servers are demonstrably sources of untrustworthy email. Sure I can trust these spam were sent by who claimed to send it, I have cryptographic proof, Yahoo are spamming me, great. I guess it might make automated abuse handling easier for Yahoo.
Transit authentication is a secondary issue. If OpenPGP/Mime were implemented widely, and all the (fake) emails from “[email protected]” came with a giant “this message isn’t signed - or this message is forged - signs, people wouldn’t send them in the first place.
The real issues here are I think;
Trust is expensive/difficult to manage.
We like to communicate with folk who aren’t yet in our network of trust occasionally.
There are too many compromised machines out there.
Backward compatibility is seen as a must.
Challenge/Response could be implemented to reduce authenticated sender issue down to “prove you get email to the address you are sending from” before I accept. It is conceptually simple, but the antispam folk bitch about it because implementation transition would (they believe) be painful.
This approach works fine for certain IM networks who only allow buddies to chat, and ask the user whenever someone wants to be a buddy.
Sure authentication is the first step to trust - but trust is essential. Systems must demonstrate how they will provide and manage trust, before we go to the trouble of deploying authentication, otherwise we might deploy the wrong kind of authentication system.
Any authentication system not relying on cryptography (public key) is probably not worth implementing. Not because public key cryptography is a “silver bullet”, but because the alternative technologies to rely on (like DNS lookup for SPF) are not yet secure enough for common purposes, and we would be encouraging the bad guys to attack the DNS, when I’d far rather they were pitched in a battle of wits with the mathematicians are the NSA (if it exists ;-), than me as a DNS administrator.
So I want trust, I want authentication, I want it per sender, I’d like it implemented in free software as well. Yes I already use GNUPG, but it provides a kind of trust network, it isn’t that specifically focused on whether I trust someone to introduce a new email correspondent, and my email system doesn’t yet reject emails which aren’t correctly signed (and like DKIM some mailing lists mess it up), and not many people are using it (and the most common email client on the planet still hasn’t implemented the relevant RFCs).
Simon that is the best comment I have read in a long time. Thank you.
>antispam folk bitch about it because implementation transition would (they
> believe) be painful
After 15 years of spam, I would take 1 year of pain if it meant the I would never have to deal with it again. I get disgusted when I think about how much time I have had to waste tweaking spam filter systems.
> Trust is expensive/difficult to manage.
I have been mulling this idea for a while now. This may seem elitist, but what if, to run a mail server you had to pay $500, for the privilege of registering their server with a trust authority Public Key server. The recipient server could verify the senders server before accepting email.
Tired of spam, only accept email from registered servers.
Spamming servers could have their keys revoked. This drives the cost of business up for everyone (slightly), but especially for spammers.
Most users use a providers server, as I spend more work time fighting SPAM, I gave up my home email server (too much work), and now use Google apps for my personal mailboxes.
There was a time before AOL and windows 95 popularized the internet, when there was a higher barrier to entry (technical, not financial). SPAM was not an issue then. As it got easier to connect, SPAM got worse.
We need to raise the barrier to entry on mail servers that we accept mail from.
The internet needs a cover charge.
Quite simply
Nice idea, except you don’t even need a public key server, you can do the whole thing in DNS. This is exactly what we have already been offered by Spamhaus with its .mail sponsored TLD.
That idea withered on the vine some years ago.