Skip to main content

Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting
draft-ietf-marf-dkim-reporting-16

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    marf mailing list <marf@ietf.org>,
    marf chair <marf-chairs@tools.ietf.org>
Subject: Protocol Action: 'Extensions to DKIM for Failure Reporting' to Proposed Standard (draft-ietf-marf-dkim-reporting-16.txt)

The IESG has approved the following document:
- 'Extensions to DKIM for Failure Reporting'
  (draft-ietf-marf-dkim-reporting-16.txt) as a Proposed Standard

This document is the product of the Messaging Abuse Reporting Format
Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/


Ballot Text

Technical Summary 

Deployers of message authentication technologies are increasingly 
seeking visibility into DKIM verification failures and conformance 
failures involving the published signing practices (e.g., ADSP) of 
an Administrative Management Domain. 

This document extends DKIM and ADSP to add an optional reporting 
address and some reporting parameters. Reports are generated using 
the format defined in draft-ietf-marf-authfailure-report. 

Working Group Summary 

There is nothing of real note in the working group discussion. 
The document was not controversial, and in the normal process 
of hammering out the details, everything went smoothly. The 
document has very broad consensus in the MARF working group. 

Document Quality 

There is at least one open-source implementation now, from 
the document editor. There is also an effort called DMARC, 
which builds on DKIM, and some people involved with that work 
plan to implement this protocol. 

Personnel 

Barry Leiba <barry.leiba@computer.org> is the document shepherd
Pete Resnick <presnick@qualcomm.com> is the responsible AD. 

RFC Editor Note