DomainKeys Identified Mail (DKIM) and Mailing Lists
RFC 6377

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    dkim mailing list <>,
    dkim chair <>
Subject: Protocol Action: 'DKIM And Mailing Lists' to BCP (draft-ietf-dkim-mailinglists-12.txt)

The IESG has approved the following document:
- 'DKIM And Mailing Lists'
  (draft-ietf-dkim-mailinglists-12.txt) as a BCP

This document is the product of the Domain Keys Identified Mail Working

The IESG contact persons are Sean Turner and Stephen Farrell.

A URL of this Internet Draft is:

Technical Summary

  DomainKeys Identified Mail (DKIM) allows an administrative mail
  domain (ADMD) to assume some responsibility for a message.  Based on
  deployment experience with DKIM, this Best Current Practices document
  provides guidance for the use of DKIM with scenarios that include
  Mailing List Managers (MLMs).

Working Group Summary

  There is a significant sense that the only "right" thing to advise
  with regard to mailing list managers is that messages forwarded by
  the MLM be DKIM-signed, and that verifiers consider the MLM domain's
  signature in making their assessments.  This is captured in the
  document.  Notwithstanding that, there is consensus that further
  advice, as given in the document, is appropriate and useful.

Document Quality

  This document does not define a protocol, but specifies practices
  recommended for using DKIM in scenarios that include Mailing List
  Managers.  The document reflects the best practices at the current
  time, in the judgment of the DKIM working group. 


   Barry Leiba is the Document Shepherd.
   Sean Turner is the Responsible AD.

RFC Editor Note

  This document depends heavily on draft-ietf-dkim-rfc4871bis, and will
  be waiting in the editor queue for a reference to it.  This document
  has references to specific sections in draft-ietf-dkim-rfc4871bis, so
  the RFC Editor should process the latter document first, and then make
  sure that the section references either haven't changed or are
  corrected.  The document editor should be particularly careful to
  re-check this during AUTH48 (please remind him).