All - First, thank you for your help over the past year since we published the DMARC specification. The input on this list has proven invaluable in understanding real-world deployment and helping to improve the specification.
This (long) update includes: * The submission of the DMARC specification to the IETF. * Changes to the specification since the last publication. * The new DMARC discussion list at the IETF. * The updated mission of this discussion list. As you undoubtedly know by now, at the request of DMARC.org, the DMARC specification has been submitted to the IETF by Murray Kucherawy on March 31, 2013: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ For those interested in the details of the process, the specification was submitted via the Independent Submission Editor for publication so that, if accepted, it will receive an RFC number for definitive reference. In addition to being able to retrieve the full specification from the IETF Data Tracker link above (in various formats), you'll also be able to monitor the progress of the document as it moves through the process. What was submitted to the IETF is now the most current version of the specification and should be the one that everyone references as the base version. It is an update to the version of the specification that was published on DMARC.org on March 30, 2012, so everyone is encouraged to read it. In the year since the DMARC specification was announced to the public, this discussion list has been invaluable in helping to improve it. The majority of the changes in the version submitted to the IETF, other than being re-formatted for the IETF, relate to improved clarity, specificity, and readability. There were also some minor errors that have been corrected. Among some of the more substantive updates are: * Within Section 6.2, a new, optional "Failure Report Option" (fo) was added to the DMARC record. The new options enable more control for a sender to specify the granularity of Failure Reports (RUF) that are sent based on the configurable options. NOTE: This relies on a receiver who supports RUF and the new options. * A new Section 7.1 on a "Policy Fallback Mechanism" was added to provide guidance on how a receiver must interpret the "pct" tag within a published policy. * An expanded Section 8.3 about "Aggregate Reports" based on wide-scale, real-world experience includes guidance for how receivers may interpret the timing of reports being generated and sent to senders. * The Section 8.4 on "Failure Reports" (including Section 8.4.1) has also been expanded to provide more specific direction in how to format RUF. We are working on an update to the FAQ maintained on DMARC.org that points to the differences since the previous version. We will update this list when it has been added to the site. In the meantime, here is a link to the DIFF between the previous version published on March 30, 2012 and the one submitted to the IETF on March 31, 2013: http://www.dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html Now that the specification has been submitted to the IETF, we are encouraging the ongoing technical discussion about the specification itself move to the new list operated by the IETF: https://www.ietf.org/mailman/listinfo/dmarc Among the topics being discussed on the list is a proposed IETF DMARC Working Group. Included in the planned deliverables are the publication of a "Using DMARC" best current practices document as an adjunct to the specification itself, plus some ancillary work that could improve its utility. The conversation is still new, and we look forward to your contributions to the discussion. In addition, we will continue to operate this DMARC-DISCUSS list to support the growing community of deployers less interested in the specification than in its uses. We encourage everyone to continue sharing their operational advice and ask operational questions here. NB: As part of moving the technical specification work to the IETF, the "NOTE WELL" statement governing participation on this list has been changed: http://www.dmarc.org/note_well.html Thank you again for helping make DMARC such an incredibly effective tool to combat spoofed domain mail. We look forward to your continued involvement. J. Trent Adams DMARC.org Chair -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
