Hi Paul, Yes. In general (since we provide solution anti-spam/malware/phishing/spoofing/etc,mail routing and infrastructure) we don't believe in quarantine products. We use to have it in core product today it's separate solution and open-source, github: https://github.com/halonsecurity/sp-enduser More on our wiki as well: http://wiki.halon.se/Overview
Thanks, appreciate your feedback! 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 Mar 11, 2014, at 6:11 PM, Paul Midgen <[email protected]> wrote: > 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)
