Sender ID: Where Did That Email Come From?

The rapid development of the internet has been a blessing for consumers and businesses. However, while the rise of the internet was good for business, it created many security concerns. Spammers and online criminals frequently exploit emails, threatening user security, stealing their personal information and identities, and even flat out stealing money through various schemes.

Sender ID was designed to mitigate or eliminate some of these risks. It validates email sender addresses and protects users from potentially harmful email messages.

Sender ID Framework (SIDF) is an email verification protocol implemented by Microsoft, based on the Sender ID anti-spoofing proposal from the former MARID internet Engineering Task Force (IETF) workgroup.

Brief History

In April 2006, the MARID IETF workgroup announced its experimental request for comments – RFC 4406, and this document defined the basis of Sender ID. Additional parts of the Sender ID spec were published in RFC 4405, RFC 4407, and RFC 4408. Sender ID is based on the simpler Sender Policy Framework (SPF) email validation system.

Sender ID was implemented by Microsoft, and it became the subject of controversial licensing issues. Key parts of the Sender ID use technologies patented by Microsoft, and licensed under the terms that are not compatible with the GNU General Public License. As a consequence, free implementations of Sender ID were problematic.

In October 2006, Microsoft placed these patents under the Open Specification Promise license, compatible with free and open source licenses. Still, the Open Source Promise is not fully compatible with the latest GPL license version 3.x.

Sender ID Features

The simpler SPF email validation system does not analyze and verify the header addresses identifying the sending party in an email. Instead, SPF only verifies the “MAIL FROM” address.

Sender ID improves on SPF, defining a Purported Responsible Address (PRA) algorithm along with a set of heuristic rules to determine this address from many address headers in an email message. This approach aims to select the header field with the email address actually responsible for sending the message.

The disadvantage of the Sender ID PRA is that forwarders and mailing lists can support it only if they modify the email header, which directly violates the IETF RFC 2822 email message format specification.

The Sender ID specification recommends using the SPF’s v=spf1 policies and applying them to the PRA identity as well. This creates a potentially problematic situation, because the recommendations in the Sender ID specification RFC 4406 violate the SPF specification RFC 4408. This has led to further controversy and friction between the SPF and Sender ID email validation systems.

Despite all controversy, Sender ID has been widely implemented. It is estimated that more than 15 million domains use Sender ID today.

How Does Sender ID Work?

In order to use Sender ID, email domain owners have to ensure that all IP addresses used by their outbound email servers, or IPs authorized to send email, are published or declared in the Domain Name System (DNS). These IP addresses are included in an SPF text file.

Users send emails from an email client or web interface without any changes.

When the recipient’s inbound email server receives the email, it uses the Sender ID Framework (SIDF) to query the purported responsible domain’s DNS (the sender’s DNS) for the SPF record. The receiving email server determines if the outbound email server’s IP address matches the IP addresses that are authorized to send email from that domain.

The receiving email server then delivers the email message based on the SPF record syntax, the pass or fail verdict, and the reputation data, to the inbox, junk or quarantine folders, or blocks it altogether.

Should I Use Sender ID?

There is no simple answer to this question. Sender ID is widely implemented, but mostly in Microsoft’s own software solutions, like the widely used Microsoft Exchange Server. In the early days after the initial release of Sender ID, many open source software vendors decided against implementing Sender ID because of the aforementioned licensing issues. All the controversy surrounding Sender ID licensing and the unresolved issues related to SPF and Sender ID specifications did not help the open source community either.

If your company uses Microsoft software, and your business email server is running Microsoft Exchange, the answer is to this question is definitely yes: Sender ID is most likely a good fit for your stack and your organization.

If you own a website and you are interested in protecting the web site’s email, you should check with your hosting provider whether or not they support Sender ID. As we already pointed out, Sender ID isn’t widespread on open-source platforms, or non-Microsoft platforms to be exact.

Sender ID Resources

Sender ID resources are scarce. We managed to find a few concerning Microsoft Exchange and Linux:

• Microsoft TechNet website has a nice section about using the Sender ID in Microsoft Exchange Server 2016.
• Digitalsanctuary.com blog about spam protection and setting up SPF, Sender ID, Domain Keys and DKIM, also mentions using Sender ID with SPF.

Wizards

There are a number of Sender ID wizards available. They are simple tools that create a Sender ID record for any email host. You just enter the host, and select different parameters (or use the defaults) from a point-and-click interface. They then output the Sender ID record.

• Unlock the Inbox Sender ID Wizard;
• Mail Radar SPF Wizard;
• Email Questions SPF Wizard;
• Dynu SPF Generator.

Sender ID Books

We did not manage to find any books strictly covering Sender ID. Many books about internet and email security mention Sender ID. Microsoft Exchange Server books also cover Sender ID. We singled out a few:

• Microsoft Exchange Server 2013 Pocket Consultant: Configuration & Clients (2013) by William Stanek: this book is a guide offering answers for administration and configuration of Microsoft Exchange Server 2013.
• Scams and Swindles: How to Recognize and Avoid Internet Era Rip-Offs (2015) by The Silver Lake Editors: this book covers various scams circulating on the Web, packed with insights any internet user should be aware of.

Conclusion

While you would expect that a Microsoft technology would have gained a lot more traction over the years, Sender ID never became a de facto industry standard. It was plagued by licensing issues and lack of consistency across different standards and specifications.

As such, Sender ID was relegated to Microsoft-based platforms, although there are exceptions to this rule. Of course, this does not mean Sender ID is a niche solution. It’s not, at least not in the Microsoft ecosystem.

Bear in mind that a lot of enterprises rely on Windows and various Microsoft technologies, from their servers to their tablets, and they are the primary users of Sender ID.

Further Reading and Resources

We have more guides, tutorials, and infographics related to privacy and security:

• The Ugly Face of Online Fraud: this extensive guide explains the most popular scams on the internet.
• Parents Guide to Internet Safety: learn how to product your children when they are on the internet.
• Dealing with Hate Crime: learn all about hate crime and what you can do to stop it.

The World Wide Web & Internet Privacy

Check out our infographic, The World Wide Web & Internet Privacy.

The World Wide Web & Internet Privacy