On Apr 5, 2013, at 11:22 AM, John Sweet <[email protected]> wrote:
> On Fri, Apr 5, 2013 at 9:47 AM, Steve Atkins <[email protected]> wrote: > But it leads to the secondary problem of mail administrators who implement > DMARC in a half-hearted manner and attempt to work around the primary problem > by picking and choosing which DMARC records to pay attention to... > > I'm not sure I'm following you here, Steve. Could you elaborate? If an ISP that implements DMARC receives an email from a domain that publishes a DMARC reject record, and that email cannot be authenticated in an aligned manner, then the intent of the domain owner is that that email not be delivered. If the perceived quality of DMARC records is poor (with many domains with DMARC reject records sending "legitimate" email that nevertheless fails to authenticate) then an ISP might choose to deliver some email that the associated DMARC record says should be rejected. If the reasons they do that are at all predictable (and given a little time to reverse engineer it, they'll be predictable to some degree) then that behaviour by the ISP can be taken advantage of by a malicious attacker to cause "illegitimate" mail claiming to be from a DMARC reject protected domain to be delivered. If you believe that DMARC reject policy addresses a problem[1] then the ability for an attacker to subvert the intent of the DMARC reject policy seems like an issue. It's possible I'm misunderstanding something (I've not had the time yet to go through the spec and turn it into flowcharts) but I don't think so. Cheers, Steve [1] one that isn't already addressed by manually maintained DKIM/SPF-based whitelists _______________________________________________ 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)
