Building Trust

CAN-SPAM – Looking Ahead & Looking Global

This week OTA / the Internet Society joined nearly 90 individuals and organizations submitting comments in response to the US Federal Trade Commission call for comments in regard to the CANSPAM Act.  By most accounts, the interactive marketing industry and email community have demonstrated a commitment towards compliance and the overall user experience.  Based on OTA’s own research businesses are unsubscribing to user requests well within the 10 day requirement.  Since CAN-SPAM came into effect nearly 15 years ago we have seen email and interactive marketing flourish, with increased precision and relevancy of the marketing messages being sent.  Both industry and consumers have benefited from this innovation.  At the same time we continue to see email exploited as the tactic of choice by criminals and cybercrime syndicates, underscoring the need for marketers to embrace email authentication standards and reject unauthenticated email by default.  There is room for improvement in other areas, most specifically in the discoverability, readability and transparency of the unsubscribe process and user experience.  In OTA’s comments and research we outline recommended guidance.  Read OTA’s Press Release.  Read OTA’s submission.

Looking Ahead vs the Rear View Mirror
As the internet is global and users are highly mobile, increasingly moving from one country to another, this creates challenges for businesses to comply with local jurisdictions and legal regimes.  It is important we look ahead and consider these issues and move toward enhanced opt-in and consent on data collection and specific usage.  The US is still somewhat looking in the rear view mirror versus looking ahead and should consider efforts by  Canada, Australia and the EU.  We know that the opt-in requirements in Canada’s Anti-Spam Law (CASL) and the E.U. Data Protection Directive (GDPR) have both been successfully implemented without creating a burden to business or the economy.  With the deadline to GDPR less than a year away, businesses are encouraged to move past the compliance threshold of CAN-SPAM and move toward the requirements stipulated by GDPR.  Those that fail risk being caught flatfooted and suffer distrust of their brand.

Learning From CAN-SPAM
Looking back on my involvement in the development of CAN-SPAM in 2002, it is important to reflect on where we have come from.  While the Act was originally not supported by leading trade organizations, we have found CAN-SPAM to be a very good model.  It was built on the foundation of efforts by several states including California, while preserving individual states’ rights to enforce it.  Businesses have benefited without having to navigate a patchwork of laws and regulations.  At the same time ISPs and consumers have been able to seek relief with States prosecuting some of the worst spammers.  We need a similar approach for data breach laws, which I suggest will equally benefit society.  Unfortunately once again many of the same trade groups and lobbyists continue to argue for a low bar and limit enforcement to the FTC.  Now is the time to reflect and rethink this approach and move forward and support national breach legislation.

Note: Craig Spiezle is  the managing director of AgeLight  Strategic Insights, a consultancy focused on build trust, stewardship and responsible privacy practices.  Craig is the Founder and Chairman Emeritus of the Online Trust Alliance and currently an industry advisor to the Internet Society and other organizations and government agencies.  The views represented above do not necessarily represent those of all OTA members or the Internet Society.  You may contact Craig at craigsp @

About Internet Society

Remembering Ray Tomlinson

The Internet community has lost one of our true innovators and pioneers.  Ray Tomlinson, best known as the inventor of sending email over a computer network and choosing the @ sign, passed away this weekend.  Our deepest condolences go out to his family and friends.  Ray was an incredible contributor to the Internet and was inducted into the Internet Hall of Fame in 2012 for his many achievements.

Ray’s breadth of work speaks for itself.  You can read more on the Internet Hall of Fame website.

In addition, here are Ray’s own words about his career:

We join with our community in mourning this tremendous loss.

Deploy360 Domain Name System Security Extensions (DNSSEC) Improving Technical Security

Email Hijacking – New Research Shows Why We Need DNSSEC Now!

Want a great example of why we need DNSSEC now?  Consider this new research from the CERT/CC team at Carnegie Mellon University that finds that someone is hijacking email messages to relay them through another email server.  The messages are being delivered, but it’s unknown whether they are being modified before delivery or simply logged and monitored.  As they say:

The disconcerting aspect of this work is not how many domains we see being poisoned, as there are relatively few, but which domains they are. We observe changes in A records so that a domain resolves to a different IP address. But the domains being targeted are often listed as name servers or mail exchanges for other domains. The biggest free webmail providers have been repeatedly victimized on some unknown (but likely smaller) subsection of the Internet sometime during the last year.

Someone… or multiple entities… appear to be poisoning DNS caches so that they can interject their own mail server into the delivery path of the email messages.  The CERT/CC team goes on to explain the attack and provides a very useful diagram:

Figure 2 diagrams how this usual process can be thwarted if the DNS answer for the IP address of the destination MX is changed. The mail message makes an unintended pit stop at the poisonous IP address. That server can then forward the message to its intended destination. Since mail is transmitted asynchronously, the sender and recipient are not likely to notice anything out of the ordinary. The sending IP address in the message header would likely reflect the diversion, but since mail handling often has a few exchanges before the final destination, it is not immediately obvious to anyone along the path that the diversion was out of the ordinary. 

MX cache poisoning

They go on to outline the potential outcome of the attack:

Unless the whole message is cryptographically protected, the intermediate server can read and modify the message, or append malicious content. This attack would defeat opportunistic TLS encryption between MXs that is meant to ensure the confidentiality of messages in transit. And there are some small changes the intermediary could make to the mail that would make the attack worthwhile, such as changing a bank account number for a home purchase deposit.

Essentially, the attacker could do anything they want with the email message as it is now in their possession, including:

  • Modify the message to either add, change or remove content
  • Log the message (and all of its content) in some large database
  • Simply drop the message (i.e. don’t deliver it) so that the recipient never gets the message

The researchers don’t yet know who is behind this redirection.  It could be:

  • Criminals
  • Nation states (ex. intelligence agencies)
  • Other security researchers

All they know is someone is hijacking delivery of email messages for some reason – and they are seeking help from the larger Internet community!  (Please see the bottom of their post.)

How To Protect Your Email Delivery

As the researchers note, DNSSEC is designed to prevent this type of hijacking of DNS information.  This type of hijacking would be prevented if:

1. The recipient’s domain name was signed with DNSSEC which means that the MX records (and all other DNS records) would have a cryptographic signature added.

2. The sender’s local DNS resolver was performing DNSSEC validation in which it checked the DNSSEC signatures.

Had this been in place, then the sending mail server would not have received the false MX record and would not have delivered the email to the attacker’s server.  You can read more in our document about the two sides of DNSSEC.

This hijacking of email messages is going on right now on an ongoing basis according to the researchers, and so you can take two steps to ensure that your email messages are not being hijacked:

1. Sign Your Domain With DNSSEC

The first step is to sign your domain with DNSSEC so that your MX records are protected.  If you do not operate your own DNS servers, this may involve you contacting your DNS hosting provider or DNS registrar to ask them to perform DNSSEC-signing on your domain.  We have some information about how to do this here:

and ICANN has a list of some of the registrars that provide some degree of DNSSEC support.

If you do operate your own authoritative name servers for your domain, then you can determine what you need to do to sign the domain with DNSSEC.  Many of the common authoritative name servers such as BIND, NSD, Knot and Microsoft Windows Server 2012 all include support now for DNSSEC signing.  There are also additional tools such as OpenDNSSEC that can help make this work smoothly.  Some of the resources that may help:

Once you have signed your domain, you will then need to communicate your “DS record” to your parent zone (often the top-level domain) by way of your registrar.  See our page about working with registrars for more information.

2. Turn On DNSSEC Validation On Your Network

With signing, inbound email messages to you will not be hijacked (assuming the sender is performing DNSSEC validation), but the possibility will still exist for outbound messages you send to be hijacked if your mail server doesn’t learn the correct address for the recipient’s mail server.

To enable this layer of protection, all you need to do is turn on DNSSEC validation on your local DNS server – or whatever DNS resolver your email server uses.   That is the important part because in this instance we are trying to protect email delivery.  You want your email server to be getting the correct DNS information.

We wrote about how to do this and recommend an excellent whitepaper from SURFnet that explains how to easily do this with three of the common DNS resolvers: BIND, Unbound and Microsoft Windows Server.

Now… if you don’t control the local DNS server – for instance, if you use the DNS resolver at your local Internet service provider (ISP) – then you need to contact that organization to find out if they can enable DNSSEC validation.

If your ISP is unwilling/unable to turn on DNSSEC validation, you could set your mail server to use external DNS servers that perform DNSSEC validation such as Google’s Public DNS, but we don’t recommend this unless it is your last resort because using such a distant DNS server provides a lot of room for an attacker to still inject fake packets.  As we wrote about in our “plan for DNSSEC validation“, the ideal is to have the DNSSEC validation happening as close as possible to the mail server (in this case).    It would be much safer, and perhaps quite easy, to install a local DNSSEC-validating resolver on or near your mail server itself.


With those two steps, you will protect the delivery of email to your domains – and protect your mailserver from delivering email to whomever is out there right now hijacking all these messages.

Let’s do that today, okay?  If we all do it now we can make the Internet that much safer and more secure!

If you’d like more information about DNSSEC, please see our “Start Here” page to find resources tailored to your type of organization and role – and please let us know if you need even more information!

Deploy360 IPv6

New Apache SpamAssassin Release 3.4.0 Includes Native IPv6 Support!

Apache Spam Assassin logoVery cool news out of the Apache SpamAssassin project that the new release 3.4.0 has full native IPv6 support!  This is important because SpamAssassin is widely used as an anti-spam tool for email servers.  This update nows means that it can be used in mail servers running on IPv6, including on mail servers running in an IPv6-only environment.  From the release notes:

Improved support for IPv6

The rules-updating program sa-update and its infrastructure is now usable over either IPv4 or IPv6, including from an IPv6-only hosts (bug 6654).

SpamAssassin is now usable on an IPv6-only host: affects installation, self-tests, rule updates, client, server, and a command-line spamassassin.

Command line options -4 and -6 were added to prefer/choose/force IPv4 or IPv6 in programs spamassassin, spamd, spamc, and sa-update.

Command line options –listen and –allowed-ips in spamd can now accept IPv6 addresses.

Preferably a perl module IO::Socket::IP is used (if it is available) for network communication regardless of a protocol family – for DNS queries, by spamd server side, and by a client code in Mail::SpamAssassin::Client. As a fallback when the module IO::Socket::IP is unavailable, an older module IO::Socket::INET6 is used, or eventually the IO::Socket::INET is used as last resort.

If spamd fails to start with an ‘Address already in use’ message, please install perl module IO::Socket::IP, or deintall IO::Socket::INET6, or specify a socket bind address explicitly with a spamd –listen option. See bug 6953 for details.

The spamd server can now simultaneously listen on multiple sockets, possibly in different protocol domains (Unix sockets, INET or INET6 protocol families.

DnsResolver was updated allowing it to work on an IPv6-only host (bug 6653)

A plugin RelayCountry now uses module Geo::IP and its database of IPv6 addresses GEOIP_COUNTRY_EDITION_V6 when available.

The following configuration options were extended to accept IPv6 addresses: dns_server, trusted_networks, internal_networks, msa_networks, (but not yet the whitelist_from_rcvd), and their defaults were adjusted accordingly.

The parser code of Received header fields can now deal with IPv6 addresses in a mail header section.

The AutoWhitelist plugin was updated and can now deal with IPv6 addresses.

Installation unit tests were updated to prevent them from failing on an IPv6-only host.

This is excellent news and we congratulate the Apache SpamAssassin team on making this happen.  If you are a SpamAssassin user, you can get release 3.4.0 now to be able to fight spam on email connections over IPv6!

Deploy360 IPv6

Geoff Huston Unravels An IPv6 Bug Involving Apple Mail And Microsoft Exchange

Geoff Huston's blog postGeoff Huston at APNIC Labs published today a fascinating and very well-documented exploration of why he was having occasional seemingly random problems sending email from his Apple Mail program via APNIC’s Microsoft Exchange Server.

It’s such a good read that I’ll not spoil the story, other than to say it is a good example of the kinds of things application developers need to be thinking about with regard to how they work with IPv6 addresses!

Thanks to Geoff and his colleagues for publishing such a thorough write-up from which we all can learn.