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)
