Danger: Authenticating e-mail can break it

CHICAGO--The promise of e-mail authentication is too good to ignore, but if it is implemented incorrectly it will break a company's mail system instead of fixing it, experts have cautioned.

"Deploy smart. Don't just do it," Erik Johnson, a secure messaging executive at Bank of America, said in a presentation at the Authentication Summit here Wednesday. "If you just do it, you may just break it."

For the past two years, the technology industry has been advocating the use of systems to guarantee the identity of e-mail senders. It sees such authentication as key to the fight against spam and phishing, as it should help improve mail filters and make it harder for senders to forge their addresses. The industry also likes to advertise that these systems have practically no cost.

Organizations have been buying into the promise of restoring trust in e-mail. The number of Fortune 500 companies that sent authenticated mail has increased, from 7 percent in July last year to 20 percent at the end of March 2006, according to Microsoft. The software giant is the main backer of a caller ID-like system for e-mail called Sender ID.

"Setting aside rewriting SMTP, e-mail authentication is the best thing we have today," Johnson said, referring to the Simple Mail Transfer Protocol, the basic technology behind e-mail. Yet adopting sender authentication and managing it is not simple, he said. It took Bank of America six months to deploy the technology.

E-mail ID cheat sheet
Here's the lowdown on the main technologies that are out to clean up e-mail by identifying the source.

Sender ID
Brings together two previous security technologies: Caller ID for E-mail, introduced by Microsoft in February 2004, and SPF, developed by Meng Wong. Sender ID compliant e-mail requires an SPF tag in a Domain Name System record to identify valid machines sending mail from that domain.

SPF
Short for Sender Policy Framework. Both main versions of SPF records comply with Sender ID, but they verify a different "from" address. SPF 1 validates the sender data contained in the e-mail envelope data, which is typically only read by e-mail systems. SPF 2 verifies the "from" name displayed to the user. Industry experts advise companies to publish and use both.

DKIM
Merges Yahoo's DomainKeys with Cisco Systems' Internet Identified Mail. DKIM, or DomainKeys Identified Mail, relies on public key cryptography. It attaches a digital signature to outgoing e-mail so recipients can verify that the message comes from its claimed source.

"It really is not easy to deploy sender authentication right. If you are in a large organization, you really can't just push the easy button," Johnson said. "This requires pretty much constant attention and activity...or else it will break and it will hurt you."

There are two main ways of authenticating e-mail: Sender ID and DomainKeys Identified Mail, or DKIM. Backed by Yahoo and Cisco Systems, DKIM relies on public key cryptography. It attaches a digital signature to outgoing e-mail, so recipients can verify that the message comes from its claimed source.

Sender ID is further along in adoption than DKIM. It requires Internet service providers, companies and other Internet domain holders to publish SPF (Sender Policy Framework) records to identify their mail servers. This usually does not require new hardware or software; the most arduous part is doing an inventory of mail servers and the subsequent maintenance of that record.

"The story is that (this type of sender authentication) is cheap to do. That is not true," said David Crocker, the principal at Brandenburg InternetWorking and author of one of the early e-mail standards. "The ongoing IT cost is huge."

The key problem for large companies is figuring out all the systems that send e-mail on their behalf, said Paul Judge, chief technology officer at e-mail security company CipherTrust. "If you are a large multinational organization, you may have e-mail gateways in 10 countries, you may have marketing companies that send e-mail on your behalf," he said.

[hadaso]

Avoiding Phishing

Avoiding mail that looks as if it came from your bank is easy: just give your bank an email address you don't use for any other purpose. Then you'd know that email that comes to any other email address you use and claims to be from your bank is not from your bank. It doesn't require the whole world spending millions and millions in changing the email infrastructure, and then losing lots of legitimate email because of poor implementation. And of course it requires that your bank doesn't use the info and "shares it with selected marketing partners". But then, if you do start getting spam on the address you dedicated to our bank, you'd know your bank cannot be trusted with your data, and that you cannot trust email sent from your bank because this is the way your bank works (I never get spam on the address I shared with my bank, or with AMEX, VISA, M/C, or almost any other entity. I only get spam on addresses that were made public by posting them on the web).

[209979377489953107664053243186]

it doesn't HAVE to be that difficult

There are other alternatives than having to integrate a risky authentication system into your existing email server, and without the high cost setup and maintenance. Look to peer to peer authentication and encyption solutions, such as Essential Taceo, that easily integrates with Outlook. Both sender and recipient are authenticated. http://www.essentialsecurity.com/products.htm

[Heebee Jeebies]

I really don't see the point...

Spammers will just jump and get do it too. This won't stop spamming or anything else. Sure you will have the spammers real information but when they won't stop sending you spam what good is it. Personally, I don't trust half of the known companies that are doing this either. B of A I don't trust... why should I what have they done to earn my trust. Just another money hungry company like all the rest. I don't want e-mail from them either.

Robert

[Ipod Apple]

Just another money hungry company

http://www.analogstereo.com/volvo_s80_owners_manual.htm

[Marcus Westrup]

Not good enough

The trouble with all these "solutions", are that they are about making money for the company that supplies them and not about fixing the problem once and for all.
Seriously, a complete re-write of SMTP is what is needed (and perhaps a faster migration to IP6). Such an overhaul would take years to implement and pay for, but I really think it is the only way.

[dlemex]

SPF now enforced in M$ mail server software

Although I do not know if it is the default or if it just being
enabled by ignorant mail admins but while tracking down a
different mail problem, I found a bunch of mail in our queue that
was pending because of an SPF failure. We did not have an SPF
entry in the DNS.

At minimum, SPF is causing a failure if the domain does not have
an SPF entry when the default CLEARLY should be the reverse for
a long period of time. At least in this way, sites that had SPF
entries would be checked and the protocol flaws could be found.

The far better solution for sender validation, e-mail certificates
from approved roots or using PGP, is already available AND
proven although Microsoft support is marginal at best.
Certificates not only prove identity but also insure the mail
contents are unchanged. And some companies such as Thawte
and now CACert offer free personal e-mail certificates. Apple
mail software handles P7 certificates off the shelf and PGP
certificates with a mail plugin.

I chose not to add an SPF entry for our domain because after I
reviewed the specification some months back, I realized that SPF
was a bandaid at best and not well thought out. I analyzed the
protocol before I knew it was a MS brainchild. I learned that only
as I was about to report it's many flaws. It doesn't even address
that fact that many SPAM mail servers do that for a living and so
they clearly would add an SPF entry. Other SPAM is sent when
either a mis-configured or broken into mail server is used. SPF
does nothing useful in either case where as the existing
certificate approach solves both. The design also poorly
addresses mail gateways AND cases where a user automatically
forwards e-mail to another account OR uses an alternate from
line such as when they want a reply to go to their home mail for
example. SPF will cause their e-mail to be undelivered for
reasons that the end user WILL NOT understand. We have seen
this happen many times as the company president forwards
copies of all his office mail to his home e-mail. Over the years,
various ANTI-SPAM ideas implemented by ISPs, Yahoo, etc. have
caused his forwards to fail... resulting in a lot of extra work for
the IT staff, trying to troubleshoot the problem. As with SPAM
filtering, any e-mail measures implemented at the site level
without providing users with a way to override it are destine to
fail. SPF will be another but until then it will be a problem even
for administrators that rightly choose not to implement it.

One final note, I cannot even send an email to the postmasters
of sites that turn SPF on as messages fail for the same reasons.
I wish that sites that fail to accept AND read e-mail to
postmaster/abuse were disconnected from the net until they fix
their software and procedures. It would greatly ease my
workload.

I have been a postmaster on various systems since 1985 on
ARPANET.