Danger: Authenticating e-mail can break it

(continued from previous page)

This was a challenge at Bank of America. "You have all sorts of different groups," Johnson said. "You need to really have a comprehensive, holistic look of your entire organization and know exactly who is sending mail."

"As you move along with implementing authentication...you are going to find that things will break, if some business unit goes ahead and sets up some host to send e-mail, and they don't register the hosts with SPF records," Johnson said. The problem is especially acute if e-mail service providers delete all the e-mail that fails an authentication check, he said.

But not all adopters of e-mail authentication face these problems. Dell, for example, did not see a major challenge. "There was some housekeeping that needed to be done," Erich Stokes, a systems engineer, said. "E-mail and SMTP was this great open standard, we just have to be a bit more responsible now."

The challenge of making an inventory of e-mail servers is apparent in the way SPF records are published. More than half of the companies that use SPF fail to tell recipients that their list of servers is complete--that is, that there should be no mail coming from other servers, according to CipherTrust. This leaves open a door for spoofers, as e-mail sent from an unidentified server can't just be deleted by filters.

"It definitely limits the actual effectiveness of the verdict," agreed Patrick Peterson, vice president of technology at IronPort, an e-mail security company in San Bruno, Calif. However, Peterson believes companies will get their e-mail servers in a row. "I do see that as a transitory period. When people first adopt, they are going to be very safe."

If adopted widely, e-mail authentication technology could help people make sure that a message claiming to be from their bank was actually sent by the bank. Authentication alone does not stop junk and spoofed messages, but it can make spam filters more effective by allowing filters to rate domains based on the e-mail that is sent.

But on the inbound side, filtering authenticated e-mail can be tricky, to the point where some e-mail security vendors are telling customers not to look at authentication when filtering their messages.

"We're big proponents of SPF, and all our boxes support it," said Dean Drako, the CEO of Barracuda Networks, a Mountain View, Calif.-based maker of antispam appliances. "But we have to recommend to our customers that they do not do any filtering on it, because there are too many false positives." False positives are messages wrongly identified as spam.

The ultimate benefits really are in the future applications of e-mail authentication, attendees at the authentication event agreed. E-mail security companies are working on accreditation and reputation services for e-mail. These systems look at the e-mail sending habits of a particular domain like CNET.com, for example, and include that in the decision as to whether messages should be junked.

[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. <a class="jive-link-external" href="http://www.essentialsecurity.com/products.htm" target="_newWindow">http://www.essentialsecurity.com/products.htm</a>

[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

<a class="jive-link-external" href="http://www.analogstereo.com/volvo_s80_owners_manual.htm" target="_newWindow">http://www.analogstereo.com/volvo_s80_owners_manual.htm</a>

[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.