Thank you Steven, good information. Yet with 'quarantine', you are at the mercy of the receivers policy handling rules. As the RFC states in section 6.6.4: the Mail Receiver SHOULD quarantine the message
I would assume this is one of the primary reasons these financial institutions were adamant about moving from 'none'. On Fri, Dec 23, 2016 at 10:15 AM, Steven M Jones via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > On 12/23/2016 08:10, John Comfort via dmarc-discuss wrote: > > Maybe it is time to rethink this, or open a more official dialogue. I > > understand folks don't want to send reports. I understand the privacy > > issue. However, without these reports, or at least *some* information > > sent regarding the unaligned emails, we are at an impasse to migrating > > to a 'reject'. For certain environments (e.g. financial), we cannot > > reject *any* legitimate emails and therefore require verification of > > all emails that are rejected. > > It may be difficult, but it is not impossible. I say this as somebody > who, at a financial, tried to get a DMARC "blocking" policy in place on > a sub-domain seeing x00,000's of fraudulent messages each day. But > because a few hundred legitimate messages would also have been blocked, > we couldn't proceed. Our business side partner couldn't accept the risk > of blocking those 00's of messages, but also didn't have the > authority/resources to investigate and address the root cause. Each case > is different, but often you need to check and make sure you've got > sufficient "clout" on the business side to complete the job. > > In 2016 Bank of America managed to get to "quarantine" after four years > of effort. Believe me, they didn't want to block legitimate messages, > but they understood the risk of allowing the fraudulent messages to > continue, and eventually they struck a balance. > > Wells Fargo and Discover Card also took this step in 2016. > > It may take time and effort but even stodgy, traditional financials can > get there. > > > > I would be perfectly fine with limiting the information if people are > > really that paranoid about header information. For example: date, > > receiving server information, originating smtp server sender, and > > subject line. This would be a good start at least. > > I believe Receivers already understand that they can subset the > information they share via failure reports, and do so. > > If you look at the failure reports from NetEase, you only get certain > 5322 headers - Message-ID, Received, To/From, dates and times, > authentication results, etc. Certainly there are times you want more, > but this is helpful and useful information. > > > --S. > > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > 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 dmarc-discuss@dmarc.org 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)
