I appreciate Dave's comments. We are new to DMARC. It is difficult for some folks in my organization to understand that we are at best, providing recipient org guidance, not dictating policy. I would have preferred g= to p=
Dianne Blitstein Solomon -----Original Message----- From: dmarc-discuss [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, May 02, 2014 10:47 AM To: [email protected] Subject: dmarc-discuss Digest, Vol 29, Issue 4 Send dmarc-discuss mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://dmarc.org/mailman/listinfo/dmarc-discuss or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of dmarc-discuss digest..." Today's Topics: 1. Re: DMARC woes - forwarding signed / encrypted e-mail (Dave Crocker) 2. Re: DMARC woes - forwarding signed / encrypted e-mail (Matt Simerson) 3. Re: DMARC woes - forwarding signed / encrypted e-mail (Rolf E. Sonneveld) 4. Re: DMARC woes - forwarding signed / encrypted e-mail (John Levine) 5. Re: DMARC woes - forwarding signed / encrypted e-mail (Douglas Otis) 6. Re: DMARC woes - forwarding signed / encrypted e-mail ([email protected]) 7. Re: DMARC woes - forwarding signed / encrypted e-mail ([email protected]) ---------------------------------------------------------------------- Message: 1 Date: Thu, 01 May 2014 15:11:21 -0500 From: Dave Crocker <[email protected]> To: Terry Zink <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252 On 5/1/2014 2:54 PM, Terry Zink wrote: > I remember reading somewhere about a year ago (can?t remember where, > but it was on a mailing list) that Gmail overrides the DMARC reject > policy and instead treats it as quarantine. This provides a nice example of why "overrides" is probably not the proper term. Receivers have complex decision engines and take in all sorts of information they use to formulate handling decisions. A remote agency, such as a domain owner, cannot "dictate" a receiver's actions. That is, it cannot assert anything that should reasonably be called "policy", in terms of receiver actions. It of course can state its desires -- which is what DMARC enables -- but that's quite different from policy. What's been described for gmail is that it takes guidance from the published DMARC record and then formulates is /own/ policy. In reality, that's what every receiver does. Always. So gmail is not 'overriding' DMARC policy, it is merely choosing a policy that factors in domain owner desire a bit differently than the domain owner has requested. This is more than semantic quibbling. It goes to an essential reality about the tentative nature of publishing "policy" information. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ------------------------------ Message: 2 Date: Thu, 1 May 2014 13:12:14 -0700 From: Matt Simerson <[email protected]> To: Terry Zink <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252 On May 1, 2014, at 12:54 PM, Terry Zink <[email protected]> wrote: > > It seems gmail makes an exception that allows these messages to reach > > spam folders. It seems they know DMARC can't be fully trusted. > > I remember reading somewhere about a year ago (can?t remember where, but it > was on a mailing list) that Gmail overrides the DMARC reject policy and > instead treats it as quarantine. > > -- Terry That is exactly my recollection, as discovered and discussed on this very list when a certain person published p=reject on tnpi.net and then posted to this list. But I doubt I was the first. This behavior of gmail has been discussed here several times as others experimented with the same results. Matt ------------------------------ Message: 3 Date: Thu, 01 May 2014 23:27:50 +0200 From: "Rolf E. Sonneveld" <[email protected]> To: [email protected], Terry Zink <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252; format=flowed On 05/01/2014 10:11 PM, Dave Crocker wrote: > On 5/1/2014 2:54 PM, Terry Zink wrote: >> I remember reading somewhere about a year ago (can?t remember where, but >> it was on a mailing list) that Gmail overrides the DMARC reject policy >> and instead treats it as quarantine. > > This provides a nice example of why "overrides" is probably not the > proper term. > > Receivers have complex decision engines and take in all sorts of > information they use to formulate handling decisions. > > A remote agency, such as a domain owner, cannot "dictate" a receiver's > actions. That is, it cannot assert anything that should reasonably be > called "policy", in terms of receiver actions. It of course can state > its desires -- which is what DMARC enables -- but that's quite different > from policy. > > What's been described for gmail is that it takes guidance from the > published DMARC record and then formulates is /own/ policy. > > In reality, that's what every receiver does. Always. > > So gmail is not 'overriding' DMARC policy, it is merely choosing a > policy that factors in domain owner desire a bit differently than the > domain owner has requested. > > This is more than semantic quibbling. It goes to an essential reality > about the tentative nature of publishing "policy" information. +1 It seems that much of the confusion about 'DMARC policy' is due to the fact that DMARC conflates the concepts of 'author domain signing policy' [1] and the concept of 'requested receiver action policy' [2]; the two are presented as one policy (DMARC p=). The result is: sky high expectations on one side and a (growing?) set of combinations of requested DMARC p= policies + applied receiver disposition policies. Examples that were mentioned on this list (apart from the combinations described in par. 5.2 of [3]) are: p=reject, disposition quarantine (Gmail) p=quarantine, disposition reject It will be interesting to see if/when receivers will start implementing the combination of 'p=none, disposition quarantine', or 'p=none, disposition reject', as this will definitely have its impact on the use of the reporting options in DMARC. /rolf [1] This is the general concept of author domain signing policy, which is not equivalent to what we know as 'ADSP'. [2] This is the concept of the message disposition policy, that is requested by the author domain owner, to be applied by the receiver module. [3] https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base ------------------------------ Message: 4 Date: 2 May 2014 00:36:26 -0000 From: "John Levine" <[email protected]> To: [email protected] Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=utf-8 In article <ad11d9982a1645eeba2b2c238bea8...@bl2sr01mb605.namsdf01.sdf.exchangelabs.com> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >> It seems gmail makes an exception that allows these messages to reach >> spam folders. It seems they know DMARC can't be fully trusted. > >I remember reading somewhere about a year ago (can't remember where, but it >was on a >mailing list) that Gmail overrides the DMARC reject policy and instead treats >it as >quarantine. In early April they were rejecting yahoo.com mail. More recently people tell me it's going into the spam folder, and if you click Not Spam enough, it'll go into your inbox. R's, John ------------------------------ Message: 5 Date: Thu, 1 May 2014 21:34:55 -0700 From: Douglas Otis <[email protected]> To: [email protected] Cc: "[email protected]" <[email protected]> Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=windows-1252 On May 1, 2014, at 1:11 PM, Dave Crocker <[email protected]> wrote: > On 5/1/2014 2:54 PM, Terry Zink wrote: >> I remember reading somewhere about a year ago (can?t remember where, but >> it was on a mailing list) that Gmail overrides the DMARC reject policy >> and instead treats it as quarantine. > > This provides a nice example of why "overrides" is probably not the > proper term. > > Receivers have complex decision engines and take in all sorts of > information they use to formulate handling decisions. > > A remote agency, such as a domain owner, cannot "dictate" a receiver's > actions. That is, it cannot assert anything that should reasonably be > called "policy", in terms of receiver actions. It of course can state > its desires -- which is what DMARC enables -- but that's quite different > from policy. Dear Dave and Rolf, DMARC is a mechanism that allows Author Domains a means to request clear and concise action. Some might describe that as a request to apply those actions "as policy" against their domain. When a requested action is not taken, it lessens protection. It is neither mailing-lists nor recipients disrupting community forums and other third-party services. It is clearly Yahoo! and now others. If the DMARC specification is unclear, it should be made crystal clear. It is NEVER okay to request a REJECT policy against normal user accounts. It is not reasonable to assume receivers are able to apply uniform mailing-list heuristics without input necessary to prevent the disruption of legitimate and beneficial communication. Rewriting "From" header fields is wrong and negates meaningful anti-spoofing by creating confusion about actual authors. Clear and concise action avoids exceptions based on heuristics that are always easily gamed. Adding cryptographic tokens of any sort is also easily replayed. A mitigation strategy should be made available by Author domains to reduce possible damage their policy request might reasonably cause. There is a straight forward, low latency, and highly scalable strategy that has far less overhead than either DKIM or SPF. This strategy can even permit uniform treatment of both user and transactional accounts. This strategy expects Author Domains to offer necessary input which does not always track with any specific message. Nor will this strategy increase average message size. Nor will it require mailing-lists to change processing. TPA is that good. We offer similar schemes supporting several very large ISPs. Nevertheless, TPA depends on Author Domains providing necessary information they should already have. As email extends into China, typical users have compromised systems. In this environment, DMARC feedback may prove extremely useful at establishing user notification where TPA should be able to significantly lower the noise. There will be a very steep learning curve ahead in this region. Regards, Douglas Otis ------------------------------ Message: 6 Date: Fri, 02 May 2014 16:43:01 +0200 From: [email protected] To: John Levine <[email protected]> Cc: [email protected] Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed John Levine skrev den 2014-05-01 18:17: >> Lets hope this maillist will not break dkim, please post back with my >> errors if you >> dont see dmarc pass in private mail > > Since it adds subject tags and message footers, both of which are > useful features, I'm having trouble imagining how you could expect any > incoming DKIM signatures to be valid on outgoing messages. > > Authentication-Results: iecc.com; spf=pass > [email protected] > spf.helo=dragon.trusteddomain.org; > dkim=fail (bad signature) header.d=forged.junc.eu > header.b="OI+bj08L"; > dmarc=fail.none header.from=forged.junc.eu policy=none its still my hope a maillist that is created for showing how dmarc works should stop create false alarms on domains that use p=reject where users say its a problem with it, when its not if this maillist here would change i bet it would be more understandelble on what not to do ------------------------------ Message: 7 Date: Fri, 02 May 2014 16:47:56 +0200 From: [email protected] To: [email protected] Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed John Levine skrev den 2014-05-01 18:22: > Evidently someone or something at Google has figured out that it is > not in their interest to treat Yahoo's DMARC policy advice too > seriously. Perhaps if you click "not spam" enough, that'll train it > to ignore the advice completely. p=reject on direct mails is ok, there could be maybe another p= option to accept forged from maillists ? if at all possible to solve it in dmarc ? :(/ ------------------------------ Subject: Digest Footer _______________________________________________ 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) ------------------------------ End of dmarc-discuss Digest, Vol 29, Issue 4 ******************************************** _______________________________________________ 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)
