DomainKeys Identified Mail (DKIM) and Mailing Lists
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, dkim mailing list <email@example.com>, dkim chair <firstname.lastname@example.org> 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 Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dkim-mailinglists/
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. Personnel 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).