Re: [dmarc-ietf] auth-res vs. dmarc

[Douglas Foster]

Does it help if I agree with you that it should have been brought up?

To your implicit question, I did not bring it up because I was not involved
at the time.  On the other hand, that effort did not expect an A-R to be
used outside of one ADMD, so the need for source identification was not
obvious.

ARC introduces the idea that A-R data might be useful outside of a single
ADMD, so ARC is the opportunity to identify the data needed for this to be
workable.   ARC is still experimental, not standards-track.

DMARCbis has forced recognition that indirect messages require different
filtering algorithms than direct messages.  To create those algorithms, it
should be axiomatic that we need to be able to distinguish direct messages
from indirect messages.  Having done so, we need to extract the additional
information needed to apply a differentiated algorithm correctly.

I am simply an individual contributor trying to figure out how to use this
stuff to correctly filter incoming mail.  Show me how to correctly evaluate
a forwarded message without understanding state sequence, and I will be
happy to imitate someone else's success.

Doug Foster




On Tue, Dec 29, 2020, 9:50 PM Kurt Andersen (b)  wrote:

> On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>>
>> DKIM, A-R, and ARC should all have a mandatory attribute indicating the
>> HELO name of the server applying the header, the IP Address of the previous
>> server which supplied the information being evaluated, or both.
>>
>
> With all due respect, it seems to me like this is something which should
> have been pointed out before this WG came to final consensus on 8601 (aka
> 7601bis). A-R and AAR were not designed to be fed into a determinative
> state machine.
>
> --Kurt
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Kurt Andersen (b)]

On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

>
> DKIM, A-R, and ARC should all have a mandatory attribute indicating the
> HELO name of the server applying the header, the IP Address of the previous
> server which supplied the information being evaluated, or both.
>

With all due respect, it seems to me like this is something which should
have been pointed out before this WG came to final consensus on 8601 (aka
7601bis). A-R and AAR were not designed to be fed into a determinative
state machine.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Douglas Foster]

I understand that Authentication-Results are intended for use within a
single organization, since any assertion by an outsider could be
malicious.
Since IETF does not apply ARC Sets, we are using A-R as a proxy for what
might be possible with ARC, but the two are different.

I still see a problem with ARC or A-R.  These headers assert, "These
attributes had these statuses values when I saw them," but they do not
reliably indicate when that look was performed.   The typical message
header set provides a list of address identifiers which have little
connection to servers, and a list of server identifiers which have little
connection to the address identifiers.

Consider these results from a sample message from this list.   They are
presented in the order that they appear in the message headers (top might
be newest.)   The first two are A-R and the bottom one is ARC-A-R:

 ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=
comcast.com

 ietf.org; dkim=none (message not signed) header.d=none;ietf.org;
dmarc=none action=none header.from=comcast.com;

 i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com;
dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=
comcast.com; arc=none

The bottom one tells me that an authenticator identified as "
mx.microsoft.com 1" saw an SPF Pass, but I don't know what IP address it
authenticated, and I don't know when this occurred.  There are no
Microsoft.Com servers in the Received header list, and the Auth-Ident is
not intended to convey a server or domain identifier.

The bottom entry says that the message passed DKIM, but the second entry
tells me that there are no signatures at all, yett the third one assures me
that the signatures have suddenly reappeared and are verifiable.

DKIM, A-R, and ARC should all have a mandatory attribute indicating the
HELO name of the server applying the header, the IP Address of the previous
server which supplied the information being evaluated, or both.   Without a
link between the address identifiers and the server identifiers, I don't
see how a viable algorithm can be constructed to use the data.

Message forwarding provides so much opportunity to confuse the spam filters
that I am surprised that the bad guys do not use it extensively.

DF


On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas  wrote:

>
> On 12/29/20 11:35 AM, Todd Herr wrote:
>
> None of the validation checks bothered with the p= value in the
> mrochek.com DMARC policy record, because the p= value is immaterial to
> the validation check. Whether DMARC passes or fails is based on whether SPF
> or DKIM passes or fails with an aligned domain, full stop.
>
> Once the DMARC validation result is determined, then the mailbox provider or 
> entity performing the DMARC validation check can refer to the p= value in 
> determining how to dispose of the message, but it doesn't have to. It's worth 
> noting perhaps that Google does record message disposition in the auth-res 
> header, though:
>
> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
>
> Unless those values in parens are a MUST requirement, the dmarc=fail is
> highly misleading. I haven't even seen any specification for the dmarc part
> of auth res in rfc  7601, which may be part of the problem. I don't see any
> normative language which would update rfc7601 in dmarc with the syntax and
> semantics of the dmarc field.
>
> At the very least this needs to be straightened out because auth-res, to
> Ned's earlier point, can have consumers in the form of MUA's.
>
> Mike
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/29/20 12:59 PM, John Levine wrote:

In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write:

On 12/29/20 12:10 PM, John Levine wrote:

A lot of tiny non-profits like Girl Scout troops use email addresses
at webmail providers and send their announcements through ESPs like
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.

What gmail does for gsuite is generates (or not, who knows) a key and
gives you the selector to add to your dns. I don't see why that doesn't
scale for all situations.

To point out the obvious, because they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer expertise nor a
lot of need for it.


Um, so? The have to procure a domain too which can be technically 
challenging. If they want to use outsourced email, the outsourced email 
provider should provide the support to get their selector into their 
DNS.  If they can't bother, I don't care if their email isn't delivered.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

On 12/29/20 12:47 PM, Todd Herr wrote:
Unless those values in parens are a MUST requirement, the dmarc=fail 
is highly misleading. I haven't even seen any specification for the 
dmarc part of auth res in rfc  7601, which may be part of the problem. 
I don't see any normative language which would update rfc7601 in dmarc 
with the syntax and semantics of the dmarc field.


We're going to have to agree to disagree here. I had no hand in 
writing RFC 7601 or its predecessors, but I believe DMARC is covered 
under "Extension Methods" in section 2.7.6 
(https://tools.ietf.org/html/rfc7601#section-2.7.6 
) and "Email 
Authentication Results Names" in section 6.6 
(https://tools.ietf.org/html/rfc7601#section-6.6 
), which references 
RFC 7489 section 11.2, which in turn defines pass, fail, temperror, 
and permerror as it pertains to DMARC.


As for the parenthetical bits, I believe they too are covered in RFC 
7601 section 2.7.6:


Authentication method implementers are encouraged to provide adequate
information, via message header field comments if necessary, to allow
an MUA developer to understand or relay ancillary details of
authentication results.  For example, if it might be of interest to
relay what data was used to perform an evaluation, such information
could be relayed as a comment in the header field, such as:

 Authentication-Results:example.com  ;
   foo=pass bar.baz=blob (2 of 3 tests OK)


So Google is just adding an informative comment which is free style text 
that just happens to have the juicy bits (the interesting parts dmarc 
record), which cannot be counted on. So that's useless for the MUA 
trying to use auth-res. You would never display a DMARC FAIL or fail of 
any kind for p=none. It doesn't make sense to the user. Likewise, even 
if we're talking about a downstream MTA parsing the auth-res, it will be 
useless to it as well because it has the same problem not knowing the 
context of the "failure".




At the very least this needs to be straightened out because
auth-res, to Ned's earlier point, can have consumers in the form
of MUA's.

The format/contents of an auth-res header and its impact on MUA 
development seem to be a bit off-charter for this working group, but 
I'll say that it might be a heavy lift to try to get major mailbox 
providers who run their own highly customized MTAs to comply with any 
effort to fully standardize. Their interpretations of the headers that 
they insert are done to optimize usage with their message storage 
infrastructure and their web and mobile clients, the latter of which 
the vast majority of their mailbox holders use. I don't think they 
have much incentive to standardize to make things easier for an open 
source MUA developer, but the MUA developer can probably cover most 
variations relatively easily with a simple bit of if-then-else logic 
based on the provider.


To Ned's point though: what is auth-res's purpose and why is it standard 
track if it can't provide a complete encapsulation of the state of 
authentication necessary for downstream consumers? For DMARC in 
particular, it falls far short since there is no way of knowing the 
policy. I do think that's DMARC's problem to solve somehow, regardless 
of process. And if process is a problem, that's processes fault.


Mike, coming at completely from the standpoint of modifying thunderbird 
plugin code


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[John Levine]

In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write:
>
>On 12/29/20 12:10 PM, John Levine wrote:
>> A lot of tiny non-profits like Girl Scout troops use email addresses
>> at webmail providers and send their announcements through ESPs like
>> Constant Contact and Mailchimp.  This is yet another situation where
>> DMARC can't describe an entirely normal mail setup.
>>
>> Constant Contact apparently got Yahoo to give them a signing key,
>> at least temporarily, but that doesn't scale.
>
>What gmail does for gsuite is generates (or not, who knows) a key and 
>gives you the selector to add to your dns. I don't see why that doesn't 
>scale for all situations.

To point out the obvious, because they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer expertise nor a
lot of need for it.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Todd Herr]

On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas  wrote:

>
> On 12/29/20 11:35 AM, Todd Herr wrote:
>
> None of the validation checks bothered with the p= value in the
> mrochek.com DMARC policy record, because the p= value is immaterial to
> the validation check. Whether DMARC passes or fails is based on whether SPF
> or DKIM passes or fails with an aligned domain, full stop.
>
> Once the DMARC validation result is determined, then the mailbox provider or 
> entity performing the DMARC validation check can refer to the p= value in 
> determining how to dispose of the message, but it doesn't have to. It's worth 
> noting perhaps that Google does record message disposition in the auth-res 
> header, though:
>
> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
>
> Unless those values in parens are a MUST requirement, the dmarc=fail is
> highly misleading. I haven't even seen any specification for the dmarc part
> of auth res in rfc  7601, which may be part of the problem. I don't see any
> normative language which would update rfc7601 in dmarc with the syntax and
> semantics of the dmarc field.
>

We're going to have to agree to disagree here. I had no hand in writing RFC
7601 or its predecessors, but I believe DMARC is covered under "Extension
Methods" in section 2.7.6 (https://tools.ietf.org/html/rfc7601#section-2.7.6)
and "Email Authentication Results Names" in section 6.6 (
https://tools.ietf.org/html/rfc7601#section-6.6), which references RFC 7489
section 11.2, which in turn defines pass, fail, temperror, and permerror as
it pertains to DMARC.

As for the parenthetical bits, I believe they too are covered in RFC 7601
section 2.7.6:

   Authentication method implementers are encouraged to provide adequate
   information, via message header field comments if necessary, to allow
   an MUA developer to understand or relay ancillary details of
   authentication results.  For example, if it might be of interest to
   relay what data was used to perform an evaluation, such information
   could be relayed as a comment in the header field, such as:

Authentication-Results: example.com;
  foo=pass bar.baz=blob (2 of 3 tests OK)


And I think in this specific case that those bits are there for the
consumption of the downstream parts of the Gmail infrastructure and
Gmail-developed clients (it's Gmail's MTA that's inserting the header,
after all). Other mailbox providers do things slightly differently, I
suspect.

> At the very least this needs to be straightened out because auth-res, to
> Ned's earlier point, can have consumers in the form of MUA's.
>
The format/contents of an auth-res header and its impact on MUA development
seem to be a bit off-charter for this working group, but I'll say that it
might be a heavy lift to try to get major mailbox providers who run their
own highly customized MTAs to comply with any effort to fully standardize.
Their interpretations of the headers that they insert are done to optimize
usage with their message storage infrastructure and their web and mobile
clients, the latter of which the vast majority of their mailbox holders
use. I don't think they have much incentive to standardize to make things
easier for an open source MUA developer, but the MUA developer can probably
cover most variations relatively easily with a simple bit of if-then-else
logic based on the provider.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Douglas Foster]

My review of messages from Constant Contact and other major E.S.P.s is that
they do obtain and use a DKIM selector when the domain has dmarc
enforcement.

Earlier in this discussion I was assured that conditionally applying the
right signature was not a significant burden for them.

Scaling does not seem to be a problem yet.

On Tue, Dec 29, 2020, 3:11 PM John Levine  wrote:

> In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write:
> >
> >On 12/29/20 10:59 AM, John Levine wrote:
> >>
> >> Don't forget
> >>
> >>   o Normal forwarding of SPF validated mail
> >>   o Authorized third party senders with no access to DKIM keys
> >>
> >If by "authorized" you mean authorized by the originating domain, I don'
> >t have a lot of sympathy since they can delegate them a selector and
> >update their DNS. Not doing so is just lazy.
>
> A lot of tiny non-profits like Girl Scout troops use email addresses
> at webmail providers and send their announcements through ESPs like
> Constant Contact and Mailchimp.  This is yet another situation where
> DMARC can't describe an entirely normal mail setup.
>
> Constant Contact apparently got Yahoo to give them a signing key,
> at least temporarily, but that doesn't scale.
>
> R's,
> John
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/29/20 12:10 PM, John Levine wrote:

In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write:

On 12/29/20 10:59 AM, John Levine wrote:

Don't forget

   o Normal forwarding of SPF validated mail
   o Authorized third party senders with no access to DKIM keys


If by "authorized" you mean authorized by the originating domain, I don'
t have a lot of sympathy since they can delegate them a selector and
update their DNS. Not doing so is just lazy.

A lot of tiny non-profits like Girl Scout troops use email addresses
at webmail providers and send their announcements through ESPs like
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.


What gmail does for gsuite is generates (or not, who knows) a key and 
gives you the selector to add to your dns. I don't see why that doesn't 
scale for all situations.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[John Levine]

In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write:
>
>On 12/29/20 10:59 AM, John Levine wrote:
>>
>> Don't forget
>>
>>   o Normal forwarding of SPF validated mail
>>   o Authorized third party senders with no access to DKIM keys
>>
>If by "authorized" you mean authorized by the originating domain, I don' 
>t have a lot of sympathy since they can delegate them a selector and 
>update their DNS. Not doing so is just lazy.

A lot of tiny non-profits like Girl Scout troops use email addresses
at webmail providers and send their announcements through ESPs like
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] pro tip: get a plugin for your MUA for DKIM/DMARC

[Michael Thomas]

I started using the dkim-verifier for thunderbird the other day and it's 
been pretty eye opening. I've been using where it just uses the auth-res 
rather than verifying the actual signature. I've found a few bugs, but 
overall it's been very enlightening as I've been seeing some pretty 
interesting things. My thread with DMARC=fail is a result of one thing I 
saw which from a UI standpoint was highly misleading. We can probably 
suss out other issues as well.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

On 12/29/20 11:35 AM, Todd Herr wrote:
None of the validation checks bothered with the p= value in the 
mrochek.com  DMARC policy record, because the p= 
value is immaterial to the validation check. Whether DMARC passes or 
fails is based on whether SPF or DKIM passes or fails with an aligned 
domain, full stop.
Once the DMARC validation result is determined, then the mailbox 
provider or entity performing the DMARC validation check can refer to 
the p= value in determining how to dispose of the message, but it 
doesn't have to. It's worth noting perhaps that Google does record 
message disposition in the auth-res header, though:


dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com


Unless those values in parens are a MUST requirement, the dmarc=fail is 
highly misleading. I haven't even seen any specification for the dmarc 
part of auth res in rfc  7601, which may be part of the problem. I don't 
see any normative language which would update rfc7601 in dmarc with the 
syntax and semantics of the dmarc field.


At the very least this needs to be straightened out because auth-res, to 
Ned's earlier point, can have consumers in the form of MUA's.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Alessandro Vesely]

On Tue 29/Dec/2020 18:22:18 +0100 ned+dmarc wrote:

On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote:


DMARC validation failures can be caused either due to legitimate mail
(i.e., mail originated by or on behalf of the publisher of the DMARC
policy, a.k.a., the domain owner) failing authentication checks due to a
shortcoming in the authentication practices of the domain owner or some
other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
not originated by or on behalf of the domain owner, so mail intended to
fraudulently impersonate the domain), specifically the kind of mail that
DMARC is purported to be designed to stop.



That kind of analysis seems to be missing from the draft.  After some years of
experience,  we should be able to provide some, I'd hope.  If not, we'd better
bluntly drop the draft.


I think a list of possible failure causes would be nice to have, because
a lot of people seem to think that DMARC is a completely reliable mechanism.

I'm not entirely convinced this document is the place for it, but OTOH
I'm not convinced it isn't.



A list of failure causes w/o further considerations may well live in an 
appendix of the main document.  If failure causes are specifically categorized 
for failure reports, this document becomes a good candidate.




It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

  o Illegitimate mail
  o Message changed in transit, invalidating DKIM signature

   o Unintended DKIM breakage
   o Intentional DKIM breakage (e.g. MLM)
o DKIM signatures not evaluated or not reported
o Missing DKIM signature

  o Incorrect DKIM signing
  o Incorrect SPF setup

o "Mute" forwarding (SPF failure)
o VERP disalignment

  o Unintentional domain misalignment
  o Improper assertion of DMARC policy


We regularly get problem reports whose root cause turns out to be one of
these things.



The point is working out why one cannot understand the failure reason from 
aggregate reports.  In what cases we do need a failure report in order to 
understand what's wrong?  Maybe we need better aggregate reports?


I found one problematic report today, reported by Yahoo! (Oath) on behalf of 
aol:

  

  4.31.198.44
  1
  
none
fail
fail
  


  tana.it


  
ietf.org
pass
  

  

4.31.198.44 is mail.ietf.org.  DKIM and SPF are not aligned, hence the failure. 
 I'm surprised there are no DKIM signatures.  Now I'm going to add "DKIM 
signatures not evaluated or not reported" to the list above, as it turns out 
that Yahoo! seem to report valid signatures only.  Anyway, would I have got a 
better understanding had I received a ruf as well?


One thing a failure reports brings is the Received: (or ARC) chain.  If I 
wandered how come the IETF sends messages with my header_from, a ruf might 
help.  Is that a real case?  Forwarding for email address portability (either 
"mute" or SRS) is probably not even worth being reported, since there's nothing 
a mail admin can do about that —updating the address could be done by the 
author, had the server returned a 251/551.


Today's other reports are even more straightforward.  But then I run such a 
tiny server that I don't get an interesting assortment of cases.


Another question is *if* I were running a large server and *if* that 
problematic record had a 1 zillion, how many of the 
corresponding failure reports would I read, assuming I received any?



Best
Ale
--
















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Todd Herr]

On Tue, Dec 29, 2020 at 1:29 PM Michael Thomas  wrote:

>
> On 12/29/20 10:01 AM, Todd Herr wrote:
>
> On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas  wrote:
>
>>
>> On 12/29/20 9:18 AM, Todd Herr wrote:
>>
>>
>> The intent of the p= value is for the domain owner to communicate a
>> request for message handling by the entity evaluation the DMARC results; a
>> policy of p=none means "please treat this message the same as you would
>> have if you hadn't performed a DMARC check on it, regardless of the result
>> obtained from the check".
>>
>> Right, but that is not what Google at least is doing  in their Auth-res.
>> It's marking it as DMARC=fail.
>>
> I'm sorry, but I just don't do well with abstract concepts. Could you
> please favor me with an example Authentication-Results header that's got
> you vexed, so that I might understand what you're seeing?
>
> I just posted an example.
>
>
> Again, the result of the validation check is independent of the p= value
in the published policy. The p= value is a request by the domain owner for
handling based on the validation check results.

Let's look at your example:

Return-Path:  

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
t=1609263631; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=;
h=From:Date:In-reply-to:References:To:Subject:List-Id:
 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
 Cc;
b=aayvF8PgSyzrXOZYbNxAumLnlLbDQalrt4v/c80QwqvBZwDP3pKlwFBsokgbGdqyj
 NAzqqsrLPPXsYkTNPzmpsQmBkHhz9i+qWILS4DjGJEhDwtrz0X6PKXTLDVHgfUxgRt
 az2SiD/+IPA7iMqhsjjuerYU9UNIlD/Iq4dNtW3M=

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
t=1609263624; bh=EGQWffHXRQ6gspv6YxtmRG6Fn28UIhBFVLnT2fAWP+A=;
h=From:Date:In-reply-to:References:To:Subject:List-Id:
 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
 Cc;
b=PwU4/yuQPAZwBP5tbjxZEG1gunIJDSOkf7BOD5fFeiB9+0Kr9B5jxtcsdj8tncl0E
 PA0Fes+JZac4PX4NFJhQnXyP81gDZckIysH8SV6r3wUy9zxheqUWa0+OpsOaZTcU14
 yPn4VMb1pn4H7YHpQfKDEgn6eKmQUfXq6jwZ9wSE=

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712;
 t=1609263318; bh=ewHxwhE1IkhylbN6K9Ju/+CBAakzJSsXNExHQ9KhZnU=;
 h=From:Cc:Date:Subject:In-reply-to:References:To:From;
 b=PRr8Q7ZvkBTBM2pDFoj11yUAiARLH0Rdv/x6rtkAkorFjOltlWqOIa5XHklqPQ0zC
 IqZveNoYHzmwN9COu1NWEjWUI7TDAW5YoOpJwWtMmfqHvTOIOSfrOkH6Fh5KFR27Ly
 cKgMVOS40Foj24fHUoCMNqGHOaZttR+5IbF+Kqkg=

From: ned+dm...@mrochek.com

Authentication-Results: mx.google.com;
   dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg;
   dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ";
   dkim=neutral (body hash did not verify) header.i=@mrochek.com
header.s=201712 header.b=PRr8Q7Zv;
   spf=pass (google.com: domain of dmarc-boun...@ietf.org
designates 4.31.198.44 as permitted sender)
smtp.mailfrom=dmarc-boun...@ietf.org;
   dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com

So, we have a message where:


   - SPF passed, with the Return-Path domain of ietf.org
   - DKIM passed (twice), with a DKIM signing domain of ietf.org
   - DKIM did not pass, with a DKIM signing domain of mrocheck.com
   - The RFC5322.From domain is mrochek.com, which publishes a DMARC
policy record
   - A DMARC authentication check was done, and it failed, because
neither SPF nor DKIM passed with a domain that aligned with
mrochek.com.

None of the validation checks bothered with the p= value in the
mrochek.com DMARC policy record, because the p= value is immaterial to
the validation check. Whether DMARC passes or fails is based on
whether SPF or DKIM passes or fails with an aligned domain, full stop.

Once the DMARC validation result is determined, then the mailbox
provider or entity performing the DMARC validation check can refer to
the p= value in determining how to dispose of the message, but it
doesn't have to. It's worth noting perhaps that Google does record
message disposition in the auth-res header, though:

dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com


As I understand it, the p= in that part of the header is the published
policy, the sp= is the published policy for any subdomains, and dis=
is the disposition for the message. In this case, the disposition was
the same as the policy, but it's not always so; here's a bit from a
message in my Gmail spam folder:

dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE)

In this case, DMARC validation checks failed for the message, and the
published policy for the domain in question was p=reject, but the
message was routed to my spam folder (dis=QUARANTINE)

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and 

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/29/20 10:59 AM, John Levine wrote:


Don't forget

  o Normal forwarding of SPF validated mail
  o Authorized third party senders with no access to DKIM keys

If by "authorized" you mean authorized by the originating domain, I don' 
t have a lot of sympathy since they can delegate them a selector and 
update their DNS. Not doing so is just lazy.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[John Levine]

In article <01rtqrkld8qk004...@mauve.mrochek.com> you write:
>I think a list of possible failure causes would be nice to have, because
>a lot of people seem to think that DMARC is a completely reliable mechanism.
>
>I'm not entirely convinced this document is the place for it, but OTOH
>I'm not convinced it isn't.

Sounds like a separate WCP document.  I agree it could be nice to have something
to point to when people insist that it's my fault that their DMARC rules don't
match the way my mail system works.

>It also strikes me as more of an exercise in enumeration of possibilities than
>an actual analysis.
>
>Let's see. We have:
>
>  o Illegitimate mail
>  o Message changed in transit, invalidating DKIM signature
>  o Incorrect DKIM signing
>  o Incorrect SPF setup
>  o Unintentional domain misalignment
>  o Improper assertion of DMARC policy

Don't forget

 o Normal forwarding of SPF validated mail
 o Authorized third party senders with no access to DKIM keys

Could be an interesting document.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

On 12/29/20 10:01 AM, Todd Herr wrote:
On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas > wrote:



On 12/29/20 9:18 AM, Todd Herr wrote:


The intent of the p= value is for the domain owner to communicate
a request for message handling by the entity evaluation the DMARC
results; a policy of p=none means "please treat this message the
same as you would have if you hadn't performed a DMARC check on
it, regardless of the result obtained from the check".


Right, but that is not what Google at least is doing in their
Auth-res. It's marking it as DMARC=fail.

I'm sorry, but I just don't do well with abstract concepts. Could you 
please favor me with an example Authentication-Results header that's 
got you vexed, so that I might understand what you're seeing?


I just posted an example.

Mike


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

On 12/29/20 10:07 AM, Laura Atkins wrote:



On 29 Dec 2020, at 17:48, Michael Thomas > wrote:



On 12/29/20 9:18 AM, Todd Herr wrote:


The intent of the p= value is for the domain owner to communicate a 
request for message handling by the entity evaluation the DMARC 
results; a policy of p=none means "please treat this message the 
same as you would have if you hadn't performed a DMARC check on it, 
regardless of the result obtained from the check".


Right, but that is not what Google at least is doing  in their 
Auth-res. It's marking it as DMARC=fail. I think the issue is with 
rfc 7601 because all I see in it are some DMARC codepoints for IANA 
unless I missed something. But it could also be considered a fault of 
DMARC if there isn't normative language on what constitutes 
pass/neutral or missing/fail. Of course this can just be a Google 
bug, but it looks more likely underspecification to me.


RFC 7489 specifically says that if the domains don’t align then the 
mail fails DMARC.


5.  Conduct Identifier Alignment checks.  With authentication checks
and policy discovery performed, the Mail Receiver checks to see
if Authenticated Identifiers fall into alignment as described in
Section 3  .  If one or 
more of the Authenticated Identifiers align
with theRFC5322  .From domain, the 
message is considered to pass
the DMARC mechanism check.  All other conditions (authentication
failures, identifier mismatches) are considered to be DMARC
mechanism check failures.



The From address was the original address, and it has an original 
signature which broke because of the list.



Here's one from Ned, auth-res shows DMARC=fail, but his _DMARC is: 
"v=DMARC1" which should be equivalent to p=none.


here's the actual message:

Mike


Delivered-To: m...@mtcc.com
Received: by 2002:a54:25ca:0:0:0:0:0 with SMTP id x10csp10181329eco;
Tue, 29 Dec 2020 09:40:32 -0800 (PST)
X-Google-Smtp-Source: 
ABdhPJyg+U7QcElEhZoI4aKc4WUQJDIWF5y8fdwdJmyjtympNYX9FAdff8Hm/Li9AYTGbddL/trG
X-Received: by 2002:a9d:336:: with SMTP id 51mr35190952otv.29.1609263632302;
Tue, 29 Dec 2020 09:40:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1609263632; cv=none;
d=google.com; s=arc-20160816;
b=dTJ54tXt0rCUsyrv1GwOeH4tt4b0svswn6u/HQWkAaV71Lq8FvoSMoDgE1O89PMWh/
 SeSKMR4NfyZsLOTh6KIWQ4nnQXBiPeyQqdVBHFbR+rnRQTPbxSlR6nPHiAa7rdv1ALmL
 dblBh3d+RQQGhaca/RMd4zT570hheniVq9CFxjCyhoa5aVFiHKgAK98ouRV5G+cmliAP
 cKuo4J2logklJ2tRkL/WaJbw5eFXXE1fSYrlO5PCINiAIRgjofhv6OfYdZ4DjA+q+B3I
 JORJjRfm+QS3HtuLNWl1Qood3uZzHNUUfWFXYAO8V7xMix7ueZa+MfzvYDz4pSUq5LYt
 XtZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=sender:errors-to:content-transfer-encoding:cc:list-subscribe
 :list-help:list-post:list-archive:list-unsubscribe:list-id
 :precedence:subject:archived-at:to:references:in-reply-to:date
 :message-id:from:mime-version:dkim-signature:delivered-to
 :dkim-signature:dkim-signature;
bh=K1GgIcpwgrhht0uXSnTdvMnH4VecXw2MUZjQBJOuUr0=;
b=nLsXAjfcPF4vqV+DPpFvzAkhJVfT8TiRkgDhEck7mOmobi376n+SINg/aife5vS0jB
 1ceDHt4zmM9mJaRv/0r4ScjrYStxd1udPBR04PxwO7upqpBKgq3EP+CS0HS7kT3tF5AW
 VnsuiEOOvgR1SJCFKOg6vFEoDZ0A3WC0XwuYw7a4uiuK34sCMQyTA8rG/Z59BsNUPoKg
 68PWKxGvV7WVCNI5cBeT0Zq4K8zNCYUiwvdd/Drohw7q9mqh2EpWneY+HVD6toGwSVqQ
 SwAyoWMlJY6VPaPt8BsarBo+KpyL2yGa2bd9REDdf5byYvf7QrPrL0KfwlYmSTPDXGnx
 Ynrg==
ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg;
   dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ";
   dkim=neutral (body hash did not verify) header.i=@mrochek.com 
header.s=201712 header.b=PRr8Q7Zv;
   spf=pass (google.com: domain of dmarc-boun...@ietf.org designates 
4.31.198.44 as permitted sender) smtp.mailfrom=dmarc-boun...@ietf.org;
   dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
Return-Path: 
Received: from mail.ietf.org (mail.ietf.org. [4.31.198.44])
by mx.google.com with ESMTPS id k26si2675892oig.140.2020.12.29.09.40.32
for 
(version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
Tue, 29 Dec 2020 09:40:32 -0800 (PST)
Received-SPF: pass (google.com: domain of dmarc-boun...@ietf.org designates 
4.31.198.44 as permitted sender) client-ip=4.31.198.44;
Authentication-Results: mx.google.com;
   dkim=pass header.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg;
   dkim=pass header.i=@ietf.org header.s=ietf1 header.b="PwU4/yuQ";
   dkim=neutral (body hash did not verify) header.i=@mrochek.com 
header.s=201712 header.b=PRr8Q7Zv;
   spf=pass (google.com: domain of dmarc-boun...@ietf.org designates 
4.31.198.44 as permitted sender) 

Re: [dmarc-ietf] auth-res vs. dmarc

[Laura Atkins]

> On 29 Dec 2020, at 17:48, Michael Thomas  wrote:
> 
> 
> 
> On 12/29/20 9:18 AM, Todd Herr wrote:
>> 
>> The intent of the p= value is for the domain owner to communicate a request 
>> for message handling by the entity evaluation the DMARC results; a policy of 
>> p=none means "please treat this message the same as you would have if you 
>> hadn't performed a DMARC check on it, regardless of the result obtained from 
>> the check".
> Right, but that is not what Google at least is doing  in their Auth-res. It's 
> marking it as DMARC=fail. I think the issue is with rfc 7601 because all I 
> see in it are some DMARC codepoints for IANA unless I missed something. But 
> it could also be considered a fault of DMARC if there isn't normative 
> language on what constitutes pass/neutral or missing/fail. Of course this can 
> just be a Google bug, but it looks more likely underspecification to me.
> 
RFC 7489 specifically says that if the domains don’t align then the mail fails 
DMARC. 

   5.  Conduct Identifier Alignment checks.  With authentication checks
   and policy discovery performed, the Mail Receiver checks to see
   if Authenticated Identifiers fall into alignment as described in
   Section 3 .  If one or 
more of the Authenticated Identifiers align
   with the RFC5322 .From domain, the 
message is considered to pass
   the DMARC mechanism check.  All other conditions (authentication
   failures, identifier mismatches) are considered to be DMARC
   mechanism check failures. 

> Maybe Murray can chime in here.
> 
>> My feeling is that failure should be reserved only in the case where both 
>> SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI 
>> standpoint is the p= value passed along as well so I can decide to decorate 
>> reject differently from quarantine and none.
>> 
>>  A typical domain owner with a non-trivial email infrastructure and an 
>> eventual goal of getting to p=reject will start with p=none, and will 
>> consume aggregate and failure reports, and will use the data in those 
>> reports to address any shortcomings in their authentication practices. 
>> Aggregate reports containing DMARC failure verdicts will be quite useful to 
>> the domain owner, to ferret out those cases where Mike in Marketing has 
>> contracted with a third party to send mail on behalf of the domain, or where 
>> Ellen the Engineer has a server running off the side of her desk, sending 
>> reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams are 
>> properly authenticated before updating the DMARC policy to p=quarantine or 
>> p=reject. It's not uncommon for some domains to be at p=none for months, 
>> perhaps twelve or more, depending on their mailing practices and cadences 
>> before making the switch. Domain owners won't move to p=reject until they're 
>> sure that enforcement of such a policy won't have a negative impact on their 
>> mail flow.
>> 
> In the mean time, it would be nice for MUA's to be able to do their part with 
> annotating mail. DMARC=fail is really unhelpful with p=none.
> 
But, the mail fails DMARC because the domains don’t align. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Todd Herr]

On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas  wrote:

>
> On 12/29/20 9:18 AM, Todd Herr wrote:
>
>
> The intent of the p= value is for the domain owner to communicate a
> request for message handling by the entity evaluation the DMARC results; a
> policy of p=none means "please treat this message the same as you would
> have if you hadn't performed a DMARC check on it, regardless of the result
> obtained from the check".
>
> Right, but that is not what Google at least is doing  in their Auth-res.
> It's marking it as DMARC=fail.
>
I'm sorry, but I just don't do well with abstract concepts. Could you
please favor me with an example Authentication-Results header that's got
you vexed, so that I might understand what you're seeing?


> I think the issue is with rfc 7601 because all I see in it are some DMARC
> codepoints for IANA unless I missed something. But it could also be
> considered a fault of DMARC if there isn't normative language on what
> constitutes pass/neutral or missing/fail. Of course this can just be a
> Google bug, but it looks more likely underspecification to me.
>
> Maybe Murray can chime in here.
>

RFC 7489 contains this text in section 4.2:

   A message satisfies the DMARC checks if at least one of the supported
   authentication mechanisms:

   1.  produces a "pass" result, and

   2.  produces that result based on an identifier that is in
alignment, as defined in Section 3
.


> My feeling is that failure should be reserved only in the case where both
>> SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI
>> standpoint is the p= value passed along as well so I can decide to decorate
>> reject differently from quarantine and none.
>>
>  A typical domain owner with a non-trivial email infrastructure and an
> eventual goal of getting to p=reject will start with p=none, and will
> consume aggregate and failure reports, and will use the data in those
> reports to address any shortcomings in their authentication practices.
> Aggregate reports containing DMARC failure verdicts will be quite useful to
> the domain owner, to ferret out those cases where Mike in Marketing has
> contracted with a third party to send mail on behalf of the domain, or
> where Ellen the Engineer has a server running off the side of her desk,
> sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams
> are properly authenticated before updating the DMARC policy to p=quarantine
> or p=reject. It's not uncommon for some domains to be at p=none for months,
> perhaps twelve or more, depending on their mailing practices and cadences
> before making the switch. Domain owners won't move to p=reject until
> they're sure that enforcement of such a policy won't have a negative impact
> on their mail flow.
>
> In the mean time, it would be nice for MUA's to be able to do their part
> with annotating mail. DMARC=fail is really unhelpful with p=none.
>
>
> I'm not sure there's any value in annotating the DMARC fail/p=none
combination. The domain owner in that case has not committed to a state
where it believes that all of its mail is properly authenticated, and so
it's possible that some percentage of legitimate mail sent by or on behalf
of the domain owner will fail.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

On 12/29/20 9:18 AM, Todd Herr wrote:


The intent of the p= value is for the domain owner to communicate a 
request for message handling by the entity evaluation the DMARC 
results; a policy of p=none means "please treat this message the same 
as you would have if you hadn't performed a DMARC check on it, 
regardless of the result obtained from the check".


Right, but that is not what Google at least is doing  in their Auth-res. 
It's marking it as DMARC=fail. I think the issue is with rfc 7601 
because all I see in it are some DMARC codepoints for IANA unless I 
missed something. But it could also be considered a fault of DMARC if 
there isn't normative language on what constitutes pass/neutral or 
missing/fail. Of course this can just be a Google bug, but it looks more 
likely underspecification to me.


Maybe Murray can chime in here.



My feeling is that failure should be reserved only in the case
where both SPF and DKIM fail and that the p= > none. What I'd
*really* like from a UI standpoint is the p= value passed along as
well so I can decide to decorate reject differently from
quarantine and none.

 A typical domain owner with a non-trivial email infrastructure and an 
eventual goal of getting to p=reject will start with p=none, and will 
consume aggregate and failure reports, and will use the data in those 
reports to address any shortcomings in their authentication practices. 
Aggregate reports containing DMARC failure verdicts will be quite 
useful to the domain owner, to ferret out those cases where Mike in 
Marketing has contracted with a third party to send mail on behalf of 
the domain, or where Ellen the Engineer has a server running off the 
side of her desk, sending reports to $ARBITRARY_MAILBOXES and ensure 
that such mailstreams are properly authenticated before updating the 
DMARC policy to p=quarantine or p=reject. It's not uncommon for some 
domains to be at p=none for months, perhaps twelve or more, depending 
on their mailing practices and cadences before making the switch. 
Domain owners won't move to p=reject until they're sure that 
enforcement of such a policy won't have a negative impact on their 
mail flow.


In the mean time, it would be nice for MUA's to be able to do their part 
with annotating mail. DMARC=fail is really unhelpful with p=none.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote:
>
> DMARC validation failures can be caused either due to legitimate mail
> (i.e., mail originated by or on behalf of the publisher of the DMARC
> policy, a.k.a., the domain owner) failing authentication checks due to a
> shortcoming in the authentication practices of the domain owner or some
> other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
> not originated by or on behalf of the domain owner, so mail intended to
> fraudulently impersonate the domain), specifically the kind of mail that
> DMARC is purported to be designed to stop.




That kind of analysis seems to be missing from the draft.  After some years of
experience,  we should be able to provide some, I'd hope.  If not, we'd better
bluntly drop the draft.


I think a list of possible failure causes would be nice to have, because
a lot of people seem to think that DMARC is a completely reliable mechanism.

I'm not entirely convinced this document is the place for it, but OTOH
I'm not convinced it isn't.

It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

 o Illegitimate mail
 o Message changed in transit, invalidating DKIM signature
 o Incorrect DKIM signing
 o Incorrect SPF setup
 o Unintentional domain misalignment
 o Improper assertion of DMARC policy


We get regularly get problem reports whose root cause turns out to be one of
these things.

I've probably missed a bunch, and this may not be the best way to compose the
list.

Ned

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Todd Herr]

On Tue, Dec 29, 2020 at 11:38 AM Michael Thomas  wrote:

> Mail from this list is being set to DMARC=fail in the authentication
> results even with _DMARC is set to "p=none". My mail provider -- google --
> is the one that is creating that auth-res. I just looked through DMARC and
> AUTH-RES (rfc 7601) and couldn't find any guidance as to what qualifies as
> "fail". Did I overlook something?
>
Your use of the phrase "set to DMARC=fail" indicates to me that you are
interpreting the Authentication-Results header in ways that are different
from my understanding of it.

My understanding of the Authentication-Results header is that it captures
the results of any authentication checks (SPF, DKIM, DMARC) that were
performed on the message. DMARC validation results are independent of the
DMARC policy record, in that any validation result (pass, fail, other) is
possible for any policy value, even p=none.

The intent of the p= value is for the domain owner to communicate a request
for message handling by the entity evaluation the DMARC results; a policy
of p=none means "please treat this message the same as you would have if
you hadn't performed a DMARC check on it, regardless of the result obtained
from the check".

My feeling is that failure should be reserved only in the case where both
> SPF and DKIM fail and that the p= > none. What I'd *really* like from a UI
> standpoint is the p= value passed along as well so I can decide to decorate
> reject differently from quarantine and none.
>
 A typical domain owner with a non-trivial email infrastructure and an
eventual goal of getting to p=reject will start with p=none, and will
consume aggregate and failure reports, and will use the data in those
reports to address any shortcomings in their authentication practices.
Aggregate reports containing DMARC failure verdicts will be quite useful to
the domain owner, to ferret out those cases where Mike in Marketing has
contracted with a third party to send mail on behalf of the domain, or
where Ellen the Engineer has a server running off the side of her desk,
sending reports to $ARBITRARY_MAILBOXES and ensure that such mailstreams
are properly authenticated before updating the DMARC policy to p=quarantine
or p=reject. It's not uncommon for some domains to be at p=none for months,
perhaps twelve or more, depending on their mailing practices and cadences
before making the switch. Domain owners won't move to p=reject until
they're sure that enforcement of such a policy won't have a negative impact
on their mail flow.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

On 12/28/20 5:17 AM, Todd Herr wrote:
On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas > wrote:



I installed this handy dandy t-bird dkim verifier extension which
also
allows you to just use the upstream auth-res.  After fixing a bug
in it,
I could see that it lists DMARC as a fail when DKIM failed, but SPF
passed. The _dmarc record has p=none, so it seems really odd to call
that a DMARC failure. Shouldn't it just be using the appropriate
p= tag
instead of "fail"? Is this left over from when Auth-res was mainly
for dkim?


A DMARC pass verdict requires not only that SPF or DKIM pass, but also 
that the SPF or DKIM domain in question align with the DMARC 
(RFC5322.From) domain. A message such as the following:


  * Return-Path: mailto:f...@a.net>>
  * DKIM domain: b.org 
  * From: b...@c.com 

Can get an SPF pass for a.net  and have its DKIM 
signature validate, but still fail DMARC for c.com  
because neither a.net  nor b.org  align 
with c.com .


Can you share the example auth-res header(s) in question along with 
the DMARC policy record(s) for the message(s)?




Mail from this list is being set to DMARC=fail in the authentication 
results even with _DMARC is set to "p=none". My mail provider -- google 
-- is the one that is creating that auth-res. I just looked through 
DMARC and AUTH-RES (rfc 7601) and couldn't find any guidance as to what 
qualifies as "fail". Did I overlook something?


My feeling is that failure should be reserved only in the case where 
both SPF and DKIM fail and that the p= > none. What I'd *really* like 
from a UI standpoint is the p= value passed along as well so I can 
decide to decorate reject differently from quarantine and none.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/28/20 11:03 PM, Murray S. Kucherawy wrote:
On Mon, Dec 28, 2020 at 7:23 AM > wrote:


P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on
earth do you
assess interoperability?



Ned -- rfc6589 is a ipv6 informational doc. which rfc are you actually 
referring to?


Mike
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[ned+dmarc]

On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote:
>
>> I still think it'd be a good idea to mention RFC 6590...
>
> Why? RFC 6590 documents a generic approach to partial information hiding. It
> does not specify how to apply this technique to DMARC failure reports, and
> doing so effectively requires a careful assessment of what needs to be hidden
> and what does not, and that in turn drags in all of the specifics we need to
> avoid in a base document of this sort.




The failure-reporting draft references RFC6591.  The only appearance of the
term "redaction" occurs in the 2nd paragraph of Section 4.1:


Referencing an approved standards document on failure reporting formats is
perfectly reasonable and even necessary.


These reports may expose sender and recipient identifiers (e.g.,
RFC5322.From addresses), and although the [RFC6591] format used for
failed-message reporting supports redaction, failed-message reporting
is capable of exposing the entire message to the report recipient.



RFC6591 doesn't go into a very detailed description.  It references RFC6590:



For privacy reasons, report generators might need to redact portions
of a reported message, such as an identifier or address associated
with the end user whose complaint action resulted in the report.  A
discussion of relevant issues and a suggested method for doing so can
be found in [RFC6590].



RFC6590, in turn, avoids the specifics of what exactly needs to be redacted.
However, it mentions the local parts of email addresses.


If anything this is an even stronger case for not referencing RFC 6590 here -
it's unnnecessary because the reference is already in the failure reporting
format specification.

I also note that RFC 6591 was published in 2012, long before PII became such a
contentious issue. Timing can be everything.


> P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
> standards-track status to be nothing short of astonishing. How on earth do
> you assess interoperability?



Maybe it's the ability to relate reports from the same source with one another
which makes them manageable.  Producers of actionable reports and consumers who
react properly can be said to interoperate, can't they?


Absent agreement on what gets redacted and how? Not even close.

RFC 6590 doesn't even pass muster as a BCP, since it describes an overall
approach to solving a range of problems and explictly does not recommend
a particular practice.

This is an informational document, nothing more and nothing less.

Ned

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Michael Thomas]

On 12/28/20 11:03 PM, Murray S. Kucherawy wrote:
On Mon, Dec 28, 2020 at 7:23 AM > wrote:


P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
standards-track status to be nothing short of astonishing. How on
earth do you
assess interoperability?


With the benefit of hindsight, that's a great question. I'd have been 
happy with Informational.  Indeed, the IESG evaluation record shows 
several ADs brought that up, but none of them insisted, and thus it 
didn't get changed.


What I had always expected to happen was, among other things, that MUA's 
would use it for like a web-like padlock too. At that point you have a 
protocol consumer. It's sort of disappointing they by and large don't 
from what I've seen. Hence my question on another thread DMARC fail, 
with p=none. That seems wrong and would definitely send the wrong signal 
to the MUA on how to mark it up.


Mike, who has now hacked on a thunderbird extension

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Alessandro Vesely]

On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote:


DMARC validation failures can be caused either due to legitimate mail
(i.e., mail originated by or on behalf of the publisher of the DMARC
policy, a.k.a., the domain owner) failing authentication checks due to a
shortcoming in the authentication practices of the domain owner or some
other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
not originated by or on behalf of the domain owner, so mail intended to
fraudulently impersonate the domain), specifically the kind of mail that
DMARC is purported to be designed to stop.



That kind of analysis seems to be missing from the draft.  After some years of 
experience,  we should be able to provide some, I'd hope.  If not, we'd better 
bluntly drop the draft.


Personally, I used to receive a few of them.  None at all now.  The only 
mention I recall about failure reports was an old article, by Terry Zinc IIRC, 
where he said they're key for telling abusers from legit operators needing 
realignment.  I don't recall why that info couldn't be derived from the source 
IPs though.



Best
Ale
--
















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[Alessandro Vesely]

On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote:



I still think it'd be a good idea to mention RFC 6590...


Why? RFC 6590 documents a generic approach to partial information hiding. It
does not specify how to apply this technique to DMARC failure reports, and
doing so effectively requires a careful assessment of what needs to be hidden
and what does not, and that in turn drags in all of the specifics we need to
avoid in a base document of this sort.



The failure-reporting draft references RFC6591.  The only appearance of the 
term "redaction" occurs in the 2nd paragraph of Section 4.1:


   These reports may expose sender and recipient identifiers (e.g.,
   RFC5322.From addresses), and although the [RFC6591] format used for
   failed-message reporting supports redaction, failed-message reporting
   is capable of exposing the entire message to the report recipient.

RFC6591 doesn't go into a very detailed description.  It references RFC6590:

   For privacy reasons, report generators might need to redact portions
   of a reported message, such as an identifier or address associated
   with the end user whose complaint action resulted in the report.  A
   discussion of relevant issues and a suggested method for doing so can
   be found in [RFC6590].

RFC6590, in turn, avoids the specifics of what exactly needs to be redacted. 
However, it mentions the local parts of email addresses.



P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its 
standards-track status to be nothing short of astonishing. How on earth do

you assess interoperability?


Maybe it's the ability to relate reports from the same source with one another 
which makes them manageable.  Producers of actionable reports and consumers who 
react properly can be said to interoperate, can't they?



Best
Ale
--






















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc