If spammers knew that signing emails would deliver them into the inbox, then they would be signing their emails (or whatever technology you invent)
As long as you remember that, you are fine. What I'm trying to figure out is that filters are capable to do based content filter depending on the certification of the message. If a template is abused, then a content filter gets in place for unauthenticated emails, not for all emails being received. The important is shifting from solely IP based reputation to domain based reputation (with a mix of the two). On Oct 27, 2012, at 10:40 AM, Zachary Harris wrote: > > I think it would be easy for someone coming in to DMARC to assume that > a "reject" policy is absolutely the top of the chain where everybody > ultimately needs to be. I would just point out that reject has its own > special set of pitfalls. > There is of course the problem of false negatives. Say your underlying > SPF or DKIM accidentally, or maliciously, gets "broken" somehow and a > whole stream of outgoing messages get rejected until you realize it and > take action. > The point I really want to draw out right now, however, is perhaps a > bit more subtle, regarding false positives. If people are used to seeing > both spam and legitimate messages from yourdomain.com, then it is more > natural for them to apply their own skeptical "human spam filters" to > messages they receive. If however, over time they have gotten used to a > pattern wherein absolutely nothing bad from yourdomain.com shows up, not > in their inbox, not even in their junk folder, then an instinctive (or > perhaps even explicitly stated) level of trust is built up that any > incoming email from yourdomain.com is good. Whenever the next new > security hole shows up, which it inevitably will someday, if someone > spoofs yourdomain.com then all of a sudden the spoof now carries that > much more weight than it otherwise would have. > The problem of false positives is significantly exacerbated if > receiving vendors choose to display special icons, along the lines > mentioned in the DMARC FAQ. That is the type of thing that is great when > it works, but which also makes matters worse when it breaks (or "gets > broken"). As a receiving vendor, all the more stuff now hits the fan > because you have not merely accepted a scam, but actually put your own > special in-house stamp of approval on a scam. > > The ideal would seem to be if everybody was doing SPF, DKIM, and DMARC > totally "by the books", always getting it right, reject policies were in > place, and the billions of non-technical email users out there in the > world were still taking personal responsibility to be skeptical of any > and every email they received, whatsoever. (Actually, from an idealist > perspective, SMTP needs to be rebooted, the patchwork quilt discarded, > and the whole thing redrawn from scratch within a secure paradigm.) But > of course this isn't an ideal world. In the real world, I'm not > suggesting anyone shy away from "reject", I'm just cautioning and > reminding folks to be fully cognizant of the range of consequences. > > -Zach > > _______________________________________________ > 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)
