eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Although future server-to-server authentication and authorization dominated the discussion at the recent Inbox conference, Bank of America Corp., based in Charlotte, N.C., is moving ahead now with technologies that make it easier for customers to recognize legitimate messages from the bank using Sender Policy Framework authentication.
Use of the SPF authentication scheme, combined with Bank of Americas SiteKey Web site authentication technology, means the banks customers will likely be among the first consumers to get help in ensuring they are doing business with the intended entity and not a fraudulent Web site.
The banks use of SPF authentication and SiteKey will help customers recognize legitimate e-mail and Web sites, confounding identity theft and phishing schemes.
Although SPF and SiteKey have their weaknesses—mainly because of deficiencies in the underlying Internet protocols, which hamper all authentication and security systems—they are nevertheless an important step in the direction of more secure messaging.
Furthermore, it is likely that customers who are educated about how to use even rudimentary secure messaging systems will be better able to adopt the enhanced technology that experts discussed during the Inbox conference.
At the conference, eWEEK Labs Technical Director Cameron Sturdevant sat down with Dave Wright, senior vice president of e-mail infrastructure for Bank of America, to find out how the banks implementation of sender authentication technology is working.
What are you currently working on?
Sender authentication. We are sending a message to the industry that we are willing to support an authentication scheme—in this case, Sender Policy Framework, or SPF.
We are telling everyone that we are posting SPF records. This is not so much an adoption of SPF or endorsing any particular vendor. Its just one step toward getting to a sender authentication scheme that works.
During your Inbox presentation, you said Bank of America sends e-mail to about 20 million addresses. What steps did you take to get SPF up and running?
We identified all of our senders and got them under control. We ensured that we owned the records and that they were correctly registered in the Domain Name System. We then created SPF records for each one of them. We could then tell ISPs, “If it doesnt have an SPF record, the message is probably not legitimate.”
We use hard fail [when an SPF record does not match the authorized sending domain] for some of our third-party vendors—when we know without a doubt that, in this subdomain, no one other than this vendor is going to e-mail on behalf of Bank of America. We post a hard-fail record or some other accepted sender authentication record.
In other words, we ask the ISPs to reject any message that poses as a Bank of America message but doesnt pass that authentication test.
What are some things youd like to see in making decisions about how to handle messages?
Reputation. Were using [Yahoo Inc.s] DomainKeys for outbound messages with one domain to see what happens. For inbound messages, there has to be a wider adoption of standard authentication methods. We went with SPF to encourage standards. ISPs and vendors need to agree on a standard.
In these early stages, were not at a point where we can block based on SPF or identity records, but we plan to use SPF checks as part of our inbound anti-spam, e-mail hygiene measures in the near future.
I think that reputation services are going to be key in authenticating senders. Youre going to start seeing vertical markets of reputation services—financial, medical, as well as general Internet reputation services.
Now that the standards exist to verify that a message is coming from a particular domain, we expect to see reputation services built on top of them in short order.
You could use that reputation for any certification method that you trusted.