Hey Jonas, Well-written article, thanks for putting it out there and advocating folks use DMARC.
One request, if you ever amend/update the article, and specifically since you're speaking to high-volume receivers, is to qualify the remarks regarding use of forensic reporting with the point the core DMARC contributors have been making: make an informed decision based on your knowledge of the sort of traffic you receive; use local policy to inform the decision to apply strong policies or send forensic reports, as well as drive the level of redaction applied to such reports. Advocating that high-volume receivers turn off forensic reporting due to concerns of list membership leakage is also an argument for not honoring quarantine and reject policies, which some of the high-volume receivers participating in the development phase of DMARC showed rather exhaustively to be safe when selectively applied based on local policy. The same research also showed that the benefit realized by reduction in exposure to email-borne threats outweighed the risk of loss in what amounted to a fraction of a percent of the total post-filter traffic received by such domains. -Paul On Tue, Mar 11, 2014 at 4:17 PM, Jonas Falck <[email protected]>wrote: > Hi Trent, > Thanks. > > The RFC should highlight and warn about forensic report concerns, we > published a blog of our notice that some hosting providers are leaking > information about users' mailing list subscriptions: > > http://www.halonsecurity.com/blog/considerations-regarding-dmarc-forensic-reports-and-other-implementation-notes/ > > > Best Regards, > > Jonas Falck > CEO & Co-Founder > > HALON SECURITY INC > 100 Montgomery Street, Suite 1080 > San Francisco, CA 94104, USA > Phone: +1.415.835.3030 > Cell: +1.650.445.9076 > > www.inumbo.com - Enterprise anti-spam/malware/phishing service - no > contract, no commitments. > www.halonsecurity.com - Award winning security software for > datacenter,hosting and service providers. > > On Feb 28, 2014, at 5:04 PM, J. Trent Adams <[email protected]> wrote: > > > > > DMARC Folks - > > > > As you know, the authors of the DMARC specification have been looking to > > find a home for the base document somewhere within the IETF. We've > > explored various options in the past year, and now it looks like we've > > found the right path. > > > > We have chosen to submit the DMARC specification via the Independent > > Submission Editor (ISE). This will have three primary effects: (1) it > > will be published with a permanent reference location; (2) it will be > > classified as Informational rather than as a Proposed Standard; (3) the > > ISE process is a much more direct path to publication. > > > > A primary reason for this shift is that DMARC is already a mature > > specification with broad adoption. We also want to help support its > > continued deployment and provide a foundation for potential future > > evolution. There are some related issues that still need to mature > > further, such as reporting practices, domain boundary identification, > > etc. To facilitate those work streams, it is important to publish a > > referenceable version of the specification. > > > > To support this effort, we are asking the community for input as we > > prepare the current version for submission to the ISE. We are seeking > > concise statements that can be incorporated into the specification > > primarily with a focus toward clarity, readability, and utility. While > > we're happy to continue cataloging suggestions for future work, our goal > > is primarily to tighten up this version of the document. Please send > > your comments to the IETF discussion list within the next week as we > > intend to submit the final version of the specification to the ISE by > > the close of the meeting in London. > > > > Current Specification: > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ > > > > IETF DMARC Discussion List: > > https://www.ietf.org/mailman/listinfo/dmarc > > > > Also, if you happen to be at IETF 89 in London, you can corner Murray > > Kucherawy and share your thoughts with him (as he has the pen on the > > current draft)... though he'll probably suggest you send your specific > > suggestions to the list, anyway. > > > > Once the specification is published, our intent is to wind down the > > loose collaboration effort known as DMARC.org. The goal is to clearly > > turn DMARC over to the community to maintain like any other open > > specification. > > > > On behalf of the original authors, we would like to extend our thanks to > > everyone for being part of the effort thus far. DMARC is not perfect but > > it's clear that it is having a substantial positive influence across the > > ecosystem. We look forward to your final comments and hope to engage > > with everyone on some other new and exciting work that will help improve > > trust in email. > > > > Thank you all, > > Trent > > > > > > -- > > 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) > > > _______________________________________________ > 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) >
_______________________________________________ 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)
