Brandmail Solutions

			home \| press \| contact us

how to get started


SbS2.0^TM and Domain Keys Identified Mail	Download PDF Version: Part 1 Part 2
Part 1 - Why DKIM? Part 2 - Enhancing and Extending DKIM

Part 1 - Why DKIM? Brandmail Solutions’ SbS2.0™ Email Branding System is based on Domain Keys Identified Email (DKIM). This paper explains DKIM and associated technologies.

What is DKIM? DKIM is a cryptographic email signing protocol used for email integrity checking, email authentication and email authorization. DKIM allows a signature to be written in the message header - allowing messages to be checked to verify that they are from purported senders (authentication) and have arrived unaltered (message integrity). Each sending domain can have individual policies with respect to the requirement for DKIM signing, requiring it for all/some/no emails (authorization). Assuming that an organization protects its encryption keys, a DKIM cryptographic signature proves that an email came from that organization and allows it to be traced back to a known sender. Receiving ISPs that use email reputation services often treat DKIM signed messages as "safe" automatically, granting them “special delivery" status, bypassing the spam filters they use for unsigned email messages. If a sender exceeds a particular threshold for sending questionable messages, an email reputation service will revoke the sender’s “special delivery" status and route the sender’s email through spam filters. How Does DKIM Work? The sending organization adds a DKIM signature to the email header that includes (among other things) 3 important fields: 1) A digital signature 2) A definition of the fields over which the digital signature was calculated 3) The sending domain DKIM publishes the public key and policies of the sending organization to the Domain Name System (DNS). DNS is broadly and widely used (and is indeed required for proper delivery of email), making DNS a very convenient container for email information that needs to be widely available. The receiving organization verifies the DKIM signature by checking it against the sender’s public key made available through DNS. It is important to note that DKIM allows third parties to sign messages as long as they have the necessary private keys. This allows sending organizations to use 3rd party email Service Providers as well as to aggregate a number of different domains. DKIM, Sender Policy Framework and Sender ID DKIM is an example of a larger class of technologies called “DNS based anti-forgery measures”—DNS based because they use the Domain Name System (DNS) to distribute authentication information, and anti-forgery because they are optimized to help ensure that a particular email really is from the sender. These technologies are not inherently anti-spam technologies, and must be used in combination with other technologies for a truly effective anti-spam solution. Sender Policy Framework (SPF) and Sender-ID are two takes on another DNS based anti-forgery measure. They provide essentially the same functionality — allowing email receiving agents to verify that the email is coming from an expected IP address. In other words, if they receive an email from foo.com, they check foo.com’s DNS record to see if the IP address that is actually transmitting the email (and thus purporting to be foo.com or foo.com’s agent) is in the list of their authorized IP addresses. SPF and Sender ID provide a measure of protection — most particularly against the annoying return-path spam, where your email address is used as the return address for spam emails. However, they do not guarantee message integrity, nor do they cryptographically link a sender to an email. Why Does an Email Sender Need Authentication? While email deliverability depends on a combination of factors, the foundation of deliverability is proof that the email is authentic — that it is actually coming from a particular sending domain. Only email that has been authenticated can benefit from deliverability enhancements like white listing that always allows mail from specific e-mail addresses, domains, and/or IP addresses. This is why many ISPs will automatically “bulk-bin” (place in a junk mail folder) email that doesn’t have some sort of authentication attached. Authentication is also fundamental to end-user trust in email. In addition to improving deliverability, authentication (in combination with reputation management/accreditation technology) can improve email opening rates. According to the Email Sender and Provider Coalition, 53% of a survey group of email users said they would be more likely to open an email if it had a symbol identifying it as having been certified by a trusted third party. Why Should an Email Sender Insist on DKIM Authentication? DKIM and Sender ID/SPF provide different methods for authenticating the origin of an email. However, while Sender ID/SPF provide validation of the sending email server, they provide no proof against email tampering. While tampering with email related to a marketing campaign could be embarrassing, tampering with transactional emails (like airline ticket reservation confirmations, or bank statements) could be actively harmful — both to the sender’s reputation and the recipient’s credit score or pocketbook. Summary By allowing an email to be cryptographically associated with a particular sender, Domain Keys Identified email (DKIM) provides a strong base of authentication, authorization and message integrity checking. For these important reasons, Brandmail Solutions built the SbS2.0™ Email Branding System on a solid, trusted DKIM foundation.

Download Part 1 PDF Version

Part 2 - Enhancing and Extending DKIM In 2006, roughly 100 million sending domains sent 300 trillion messages to 330 million mail servers. Any change to this most fundamental Internet application must be carefully considered, weighed and tested. Leading engineers and thought leaders from Cisco and Yahoo! worked over 5 years creating Domain Keys Internet Identified Mail (DKIM) - a method for cryptographically proving the origin of an email.

Public and Private Keys DKIM uses the Domain Name System (DNS) to publish the public key half of a public/private key pair. The sending domain uses the private key to sign the message. And the recipient mail server uses the public key it retrieves from the sender’s DNS servers to verify the origin of the email. The clever use of DNS servers to publish public keys means that no previous relationship has to be established between a sender and receiver to verify the authenticity of the email origin. DKIM’s Rapid Adoption And, unlike other DNS based email verification methods, DKIM actually signs each individual message and thus can prove that the email was unmodified in transit. The open, public nature of DNS has enabled the rapid adoption of the DKIM standard. Despite its recent introduction, nearly 10% of all sending domains now use DKIM to sign outbound email. Building on the DKIM Foundation Email itself requires the existence of a sound DNS infrastructure, so using DNS to distribute keys makes a lot of sense. However, DNS has certain known vulnerabilities and limitations that make it possible for a malicious sender to manipulate DKIM. Three key concerns with DKIM and DNS include “DNS cache poisoning”, message replay attacks, and DNS key persistence. DNS Cache Poisoning DNS cache poisoning takes advantage of two DNS weaknesses: (1) DNS uses an insecure protocol to communicate information between DNS servers and (2) local DNS servers cache the retrieved DNS records locally to reduce load on the root servers. These weaknesses allow malicious senders to insert false keys into intermediate DNS servers, causing false message verification. Message Replay Attacks Because DKIM does not keep track of the delivery of any individual message, it is vulnerable to a denial of service attack known as a message replay attack. In such a scenario, the same message is sent again and again, filling up the inboxes of the system under attack. DNS Key Persistence If a private key is compromised in some way, it must be revoked immediately. Because of the nature of DNS, it is hard to determine how long it will take before all cached copies of the compromised public key are eliminated from all DNS servers. This DNS key persistence means that all DKIM activity must cease for at least 24-48 hours to be certain that all recipients will request the new public key. Unfortunately, this key persistence also opens a window of time during which a malicious entity in possession of a revoked private key can use it to sign bogus Emails. SbS2.0™ is DKIM but DKIM is not SbS2.0™ DKIM, like all great Internet protocols, was built with an eye towards extension and improvement. Brandmail Solutions recognized an opportunity to address some of the aforementioned concerns by extending the work done by Cisco and Yahoo!. The Brandmail Control Center Brandmail Solutions adds a 3rd entity to the DKIM writer/reader pair. Known as the Brandmail SbS2.0™ Control Center, it acts as a central, trusted, authority for key distribution, email record keeping and other essential functions. While more detail is available in the addendum to this paper, the Brandmail Control Center prevents malicious senders from taking advantage of DKIM and DNS weaknesses. Because the Control Center uses a secure protocol to transfer public keys, there is no opportunity to poison the DNS cache. Because the Control Center tracks each individual message, there is no possibility of launching a message replay attack. Because the Control Center has central control, there is a very small time DNS key persistence time window that would allow malicious senders to sign bogus Emails. SbS2.0™ Interoperability The Brandmail SbS2.0 System allows SbS2.0™ DKIM signed mail to reach non-SbS2.0™ enabled sites. It also allows SbS2.0™ Readers to receive non-SbS2.0™ DKIM signed email. It integrates perfectly with most existing email environments, adding value without adversely affecting functionality. Brandmail Solutions' SbS2.0™ Advantage Brandmail Solutions’ SbS2.0™ provides a secure stage for email, the number 1 activity on the Internet, and enables truly unique online branding. Addendum The Brandmail Solutions SbS2.0™ Email Branding System uses and augments the Domain Keys Identified Mail (DKIM) protocol. DKIM has 2 parts: a DKIM enabled MTA (a “writer”) at the sender and a DKIM signature verifier (a “reader”) at the recipient. The Brandmail SbS2.0™ architecture has both a Writer and a Reader, and has added a 3rd piece to the system: a Control Center. The Brandmail Control Center The Brandmail Control Center is designed to work in conjunction with the Brandmail Writer and Reader. By providing a secure, centralized authority for email tracking and key distribution, the Control Center layers additional protection on top of the basic DKIM protocol. The Control Center also maintains complete records that end users can access to see the complete picture of email deliverability, opening rates and response rates. Because all communications between the Brandmail Control Center and Readers and Writers are authenticated and encrypted, any possibility of inserting a bogus entry cache poisoning is eliminated. Also, since key changes are instantly transferred to Brandmail Readers and Writers, there is effectively no window during which a known bad key can persist. This eliminates the dependency on DNS caches to clear out after a key is revoked. Brandmail Readers and Writers are informed immediately by the Control Center when keys are revoked. The Brandmail Writer vs. Standard DKIM Writers The Brandmail SbS2.0™ Writer is fully DKIM compliant, and will work either as a synergistic part of an SbS2.0™ system, with the Brandmail Reader and Control Center, or will work to sign emails destined for any DKIM compliant system. Unlike standard DKIM writers that operate without knowing if emails are actually delivered, the Brandmail Writer receives this information from the Control Center. This feature eliminates the possibility of message replay attacks that can fill up the inboxes of systems under attack. Additionally, the Brandmail Writer operates as part of a coherent system - greatly simplifying the management and increasing overall security of public and private keys. The Brandmail Reader The fully DKIM compliant SbS2.0™ Reader leverages the power of central control and management. Each email that arrives with a DKIM signature is verified. However, in addition to checking the email, the Reader also inserts a logo into the email. In communicating with the Control Center to insert the logo, the Reader provides unique details of the email to the Control Center. These details, while they do not contain any private information, allow the system to prevent duplicate emails from getting through to recipients. This check defends against a message replay attack. Again, key management is greatly simplified by having a central authority managing the keys, reducing risk. Interoperability The Brandmail SbS2.0™ Email Branding System has addressed the limitations of DKIM while remaining fully interoperable with DKIM signed email. A Brandmail DKIM signed email will authenticate with a non-Brandmail DKIM reader. A Brandmail Reader will authenticate a non-Brandmail DKIM signed email and assign it the appropriate logo. When a Brandmail Writer sends an email to a Brandmail Reader, the Control Center monitors the entire transaction — increasing the amount of information available to the system as a whole. This allows email senders to know when email is delivered, opened and acted upon. The gain in information is valuable in gauging the effectiveness of marketing campaigns and improving the effectiveness of transactional emails.

Download Part 2 PDF Version

Untitled Document A brand is much more than a trademark. It's a trustmark! TM