DKIM Working GroupH. Santos
Internet-DraftSantronics Software, Inc.
Intended status: ExperimentalApril 23, 2006
Expires: October 25, 2006 

Partial DKIM Verifier Support using a DKIM-Received Trace Header

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on October 25, 2006.

Copyright Notice

Copyright © The Internet Society (2006).


A proposal offering partial DKIM verification support to help resolve premature DKIM signature expiration and key revocation related problems associated with time shifted DKIM verifier applications.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Background/Problem
3.  Solution Summary: Partial Verifier Support
4.  How it works?
5.  Example
6.  IANA Considerations
7.  Security Considerations
8.  Acknowledgements
9.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements


1.  Introduction

DKIM (Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.) [DKIM‑BASE] (Domain Keys Identified Message) has a potential premature signature expiration timing issue related to when DKIM verifiers receive a message and when domain signature expire and/or when public keys are revoked.

The problem is highlighted when the DKIM verifiers is outside the SMTP transport such as MUAs and the backend software (MDA) does not support DKIM.

This document offers a proposal and solution to the problem whereby a MDA can offer partial DKIM verification support by adding a new trace header called DKIM-Received recording the DKIM domain DNS public key information before it expired or is revoked.


2.  Background/Problem

Some where along the email transport topology path when sending mail between point A and point B, we have DKIM signer(s) and DKIM verifier(s). This generalized commonly understood email topology can be illustrated in the following diagram:

        --------------        --------------
MUA --> | MSA--->MTA | -----> | MDA--->MFA | ---> MUA
        --------------        --------------
\____________________/        \_____________________/
    DKIM SIGNER                    DKIM VERIFIER
 Figure 1: Typical Mail Flow Topology 

The DKIM signer may be the MUA sending the message to the MSA or within a MSA/MTA network signing messages on behalf of the MUA. The DKIM verifier may be located at the MDA, MFA or recipient MUA.

The MFA (Mail Filtering Agent) is a new acronym describing a relatively recent industry direction and practice to include anti-virus/spam (AVS) mail filtering processes within the MDA network. The MFA could be a SIEVE process, SPAM-ASSASSIN or some non-standard proprietary Rule Based Messaging (RBM) scripting engine. The MFA is any process that is outside the SMTP transport process after the message is accepted by the MDA and before it is stored in the recipient MUA user's mail box.

This provides us with three possible verification delays, t1, t2, and t3, which can promote premature signature expiration or key revocation timing issues depending on where the DKIM verifier is located:

        --------------         -----------------
MUA --> | MSA--->MTA | --t1--> | MDA--t2-->MFA | --t3--> MUA
        --------------         -----------------
 Figure 2: Typical Mail Flow Topology with Delays 

The latter two are time shifted applications because message validation is belated or delayed.

The t1 delay is the SMTP transport time from MTA to MDA. SMTP has a recommended limit of 4-5 days for a SMTP sending/retry strategy [RFC 2821 section] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [RFC2821]. DKIM has a recommended seven (7) day retention limit. So for t1, there would be a low occurrence of premature signature expiration problems at the MDA. The DKIM recommendation of seven days is sufficient and covers the SMTP 4-5 day retry limit recommendation.

However, premature expiration potential increases once the MDA accepts the message and verification may occur at the MFA or MUA.

The length of the MFA delay (t2) is directly proportional to the volume of mail being received (high volume system), and the higher the volume, scalarability operational considerations will typically mandate that the DKIM verification process begin after the message is accepted.

The length of the MUA delay (t3) is directly proportional to the MUA ergonomics and user behavior in regards to frequency of mail pickup or frequency of user logins in order to download, read or received new mail.

In short, the potential of premature DKIM expiration problems increase as the verification process is time shifted beyond MDA applications.

To help resolve this, one possible idea is allow the MFA and MUA to use the time stamp recorded at the MDA as required by the all SMTP receivers when adding the Received: trace header [RFC 2821 section 4.4] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [RFC2821]. This time stamp may be called the Transaction Reception Time (TRT) because it represents the time the MDA first received the transaction from the MTA. If the MFA and MUA use the TRT as part of the DKIM expiration checks, the problems related to signature expirations are eliminated.

However, while using the TRT may help resolve MFA and MUA timing issues, there is still the possibility of a DKIM public key being revoked or removed from DNS.

To help resolve this problem, a new idea called "Partial Verifier DKIM support" may be used by MDA verifiers to help resolve both expiration or keys revocation problems potentially occurring at the MFA and much greater potential at the MUA.


3.  Solution Summary: Partial Verifier Support

In practice, it is conceivable for DKIM implementations to operate in a partial or full verifier support mode..

Partial Verifier support may include early adopters migrating towards full support and wanting to assist independent Full Verifier support processes, such as MFAs and MUAs, while the backend is being upgraded for full DKIM support.

Partial (including full) verifier support would begin with the simple addition of adding public key information in the new message RFC2822 (Resnick, P., “Internet Message Format,” April 2001.) [RFC2822] header called DKIM-Received:

   rt=<DKIM-timestamp>;    # Current time msg was received.
   sd=<selector-data>;     # Selector DNS record Data.
   [vt=<DKIM-timestamp>;]  # Current time msg was validated.
 Figure 3: DKIM-Received: Header 

If available, this header allows for time shifted full verifiers to obtain message state information that might be missing at a future moment of time to correctly validate a DKIM signature.



4.  How it works?

As an organization is migrating to full DKIM support, it may decide to add partial verification support by performing the following steps:

  1. If a incoming message has a DKIM-Signature, obtain the selector and domain from the s= and d= tag respectively.
  2. Obtain the public key by performing DKIM DNS query on selector._domainkey.<domain>.
  3. Create and prepend the DKIM-Received: header setting the rt= received time and the sd= tag with the public key data. The DKIM-Received MUST be written before the SMTP required Received: Header is written.

The full verifier MAY support DKIM-Received: If the full verifiers attempts to validate the signature, it MAY add the vt= verification time stamp tag. Adding the vt= tag to the DKIM-Received MUST NOT be viewed by MFA or MUAs as an indication of success or failure. It merely indicates that a verification was performed.

MFA and MUAs MAY support the DKIM-Received: header and if supported, it MAY use the public key information to validate the signature. The recommended steps are:

  1. If the DKIM-Signature: has a x= expiration tag, check for a DKIM-Received: header and use the rt= received time stamp for time comparison.
  2. If no x= expiration is available, begin the DKIM verification by obtaining the public key from DNS.
  3. If no public key is available, it MAY verify the signature by using the public key (sd=) recorded in the DKIM-Received: header, if any.


5.  Example

The following example shows what a MDA would add to the incoming message:

Example 5.1

Received: from ([])
          by (Wildcat! SMTP v6.1.451.7) with ESMTP
          id 2671734859; Sat, 22 Apr 2006 12:28:31 -0400
DKIM-Received: rt=1145722498;


6.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.


7.  Security Considerations

Other than not enforcing the key revocation concept. i.e. verification is still possible after the domain's public key is revoked, there are no security concerns currently envision with this proposal at this time.


8.  Acknowledgements

Discussions related to signature expiration and key revocation timing problems in the IETF-DKIM Working Group among many participants lead to the development of this proposed solution.


9. Normative References

[DKIM-BASE] Allman, E., “DomainKeys Identified Mail Signatures,” April 2006.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2821] Klensin, J., “Simple Mail Transfer Protocol,” RFC 2821, April 2001.
[RFC2822] Resnick, P., “Internet Message Format,” RFC 2822, April 2001.


Author's Address

  Hector Santos
  Santronics Software, Inc.
  15600 SW 158 ST Suite #306
  Homestead, Florida, FL 33033
  United States of America


Full Copyright Statement

Intellectual Property