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

From: Michael Thomas <[email-masked]>
Date: Sat, 26 Dec 2020 15:47:54 -0800

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?

Aside to John Levine: you had two messages to nanog back to back, one 
verified and one failed DKIM. I doesn't seem like nanog is doing any 
rewriting or anything so that is very strange. Maybe they are 
inadvertently rewriting in some situations that aren't obvious?

Mike

---

From: Todd Herr <[email-masked]>
Date: Mon, 28 Dec 2020 08:17:08 -0500

> instead of "fail"? Is this left over from when Auth-res was mainly for
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: <[email-masked]>
   - DKIM domain: b.org
   - From: [email-masked]

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)?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*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.

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Dec 2020 10:58:43 -0500

On 12/28/2020 8:17 AM, Todd Herr wrote:
> On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> 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: <[email-masked] <mailto:[email-masked]>>
>   * DKIM domain: b.org <http://b.org>
>   * From: [email-masked] <mailto:[email-masked]>
>
> Can get an SPF pass for a.net <http://a.net> and have its DKIM
> signature validate, but still fail DMARC for c.com <http://c.com>
> because neither a.net <http://a.net> nor b.org <http://b.org> align
> with c.com <http://c.com>.
>
> Can you share the example auth-res header(s) in question along with
> the DMARC policy record(s) for the message(s)?
> --

FWIW....

For your message, the wcSMTP MDA verified and produced the follow AR 
for you:

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  dmarc=fail policy=none author.d=dmarc.ietf.org signer.d=ietf.org 
(unauthorized signer);
  dkim=fail (DKIM_SIGNATURE_BAD) header.d=ietf.org header.s=ietf1 
header.i=ietf.org;
  dmarc=dkim-fail policy=none author.d=dmarc.ietf.org 
signer.d=ietf.org (unauthorized signer);
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=valimail.com 
header.s=google2048 header.i=valimail.com;
  dmarc=dkim-fail policy=none author.d=dmarc.ietf.org 
signer.d=valimail.com (unauthorized signer);

bottom up read,

By the time your message (my list copy) was echoed to me, as expected 
with the ietf.org MLM, your original body integrity was lost, hence a 
body-mismatch will be detected with all downlink DKIM verifiers.

The original DKIM idea for MLM correction (or middle-ware in general) 
was to perform a resigning by the MLM as a 3rd party signer. But we 
never corrected the authorization protocol for the 3rd party signers 
like is done with SPF allowing for 3rd party mailers to exist within 
it output mail sender framework.

Here is the problem with rewriting which the AR recorded illustrates 
-- who is the POLICY holder here?  You or the IETF (ietf.org or 
dmarc.ietf.org)?

Valmail.com does not have a policy, like ATPS, that will authorized 
ietf.org or dmarc.ietf.org as a resigner.   If you had this zone record:

;
; DMARC/ATPS Zone Records for author-domain: valimail.com
; Generated by wcMakeDMARC v4.00 (c) copyright 2020 Santronics 
Software, Inc.
; See https://secure.winserver.com/public/wcdmarc
;

_dmarc TXT ("v=dmarc1; p=reject; atps=y; asl=ietf.org,dmarc.ietf.org;")

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
xxv4fo4ieaguvlupvusha3j2x7ici4za._atps  TXT ("v=atps01; 
d=dmarc.ietf.org;")

Then our wcDMARC verifier would validate your message and stamp the AR 
with an authorized resigner data bit.  However, this is true when 
rewriting is not applied.

In practice, we have a "contract" as a list member to accept what the 
IETF MLM does, to a degree, to receive its output. But I don't expect 
any original protection to be lost.  Valimail.com was protected on 
input.  On output, it was no longer protected once it passes through 
the IETF MLM.

Consider a rewrite is not correct when it used two different domains. 
My understanding for the intent of this unfortunate introduction into 
the mail world, the whole point was make it a 1st party signature so 
that the author and signer identities matched:

ADID  Author Identity: dmarc.ietf.org
SDID  Signer Identity: ietf.org   <--- SHOULD BE signed by dmarc.ietf.org

Even if it was signed by dmarc.ietf.org, its DMARC policy is p=none, 
so who cares what is done with valimail.com messages?  Product 
engineering common sense is to not destroy the original policy 
protection Valimail.com had. If the rewrite logic is going to be 
applied only when an incoming domain has a DMARC p=reject|quarantine 
policy, then the rewrite MUST have a matching level of protection when 
it changes the author identity To me, this is the only possible way 
for a rewrite mlm logic to minimize the damage created by destroying 
the original intent and protection of a DMARC-based restricted domain.

This failure is feeding any anticipated growth for "Deep AI Mail 
engines"  that indicate valimail.com has a significant failure rate, 
100% of the time coming out of the IETF.

If I was valimail.com, as a product developer, you should support the 
easy ATPS protocol. Just add the domains you want to authorized as a 
resigner and hopefully with ATPS endorsement by ValiMail, adding it to 
your product line will give you and customers protection, immediately, 
in the eyes of my wcDMARC receivers and verifiers.

BTW, these are my authorized 3rd party resigners for my personal 
sandbox domain: isdg.net

kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01; 
d=winserver.com;" )

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 08:38:38 -0800

> 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

---

From: Todd Herr <[email-masked]>
Date: Tue, 29 Dec 2020 12:18:00 -0500

On Tue, Dec 29, 2020 at 11:38 AM Michael Thomas <[email-masked]> wrote:

> 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.

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 09:48:01 -0800

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.
>
> 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

---

From: Todd Herr <[email-masked]>
Date: Tue, 29 Dec 2020 13:01:59 -0500

On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas <[email-masked]> wrote:

> 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".
>
> 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.
>

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
<https://tools.ietf.org/html/rfc7489#section-3>.

> 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.

--

---

From: Laura Atkins <[email-masked]>
Date: Tue, 29 Dec 2020 18:07:47 +0000

> On 29 Dec 2020, at 17:48, Michael Thomas <[email-masked]> 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 <https://tools.ietf.org/html/rfc7489#section-3>.  If one or more of the Authenticated Identifiers align
       with the RFC5322 <https://tools.ietf.org/html/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. 

>> 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
[email-masked]
(650) 437-0741		

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 10:26:41 -0800

On 12/29/20 10:07 AM, Laura Atkins wrote:
>
>
>> On 29 Dec 2020, at 17:48, Michael Thomas <[email-masked] 
>>> 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, 
>> 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.
>>
>         with theRFC5322  <https://tools.ietf.org/html/rfc5322>.From domain, the message is considered to pass

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

From: [email-masked]
Date: Tue, 29 Dec 2020 09:22:18 -0800 (PST)
To: Alessandro Vesely <[email-masked]>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/IhKyBFyr-uHo92Uem1rBLZ1p730>
Subject: Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy
  implications of failure reports
Cc: Todd Herr <[email-masked]>, IETF DMARC WG <[email-masked]>
Sender: "dmarc" <[email-masked]>

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 10:28:55 -0800

On 12/29/20 10:01 AM, Todd Herr wrote:
> On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas <[email-masked] 
>>     The intent of the p= value is for the domain owner to communicate
>>     a request for message handling by the entity evaluation the DMARC
>>     same as you would have if you hadn't performed a DMARC check on
>>     it, regardless of the result obtained from the check".
>
>     Auth-res. It's marking it as DMARC=fail.
>
> 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

---

From: Todd Herr <[email-masked]>
Date: Tue, 29 Dec 2020 14:35:08 -0500

On Tue, Dec 29, 2020 at 1:29 PM Michael Thomas <[email-masked]> wrote:

> 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: <[email-masked]> <[email-masked]>

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=

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 [email-masked]
designates 4.31.198.44 as permitted sender)
smtp.mailfrom=[email-masked];
       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)

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 12:00:43 -0800

On 12/29/20 11:35 AM, Todd Herr wrote:
> mrochek.com <http://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.
>     <http://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

---

From: Todd Herr <[email-masked]>
Date: Tue, 29 Dec 2020 15:47:36 -0500

On Tue, Dec 29, 2020 at 3:01 PM Michael Thomas <[email-masked]> wrote:

> 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:
>
> 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.

> 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.

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Dec 2020 13:02:20 -0800

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 
> <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 
> <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-Results:example.com  <http://example.com>;

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

---

From: Douglas Foster <[email-masked]>
Date: Tue, 29 Dec 2020 20:30:40 -0500

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 29 Dec 2020 18:50:16 -0800

On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster <
[email-masked]> wrote:

> 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

---

From: Douglas Foster <[email-masked]>
Date: Tue, 29 Dec 2020 22:42:55 -0500

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

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Dec 2020 09:57:57 +0100

On Wed 30/Dec/2020 02:30:40 +0100 Douglas Foster 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.

For DKIM, the HELO name is irrelevant.  d= determines who did the deed.

A-R and ARC have an authserv-id which is often consistent with HELO.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Dec 2020 10:42:36 +0100

On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
>>> highly misleading.

I agree with Michael here.  When a (trusted) dmarc=fail is seen downstream, its consumers neither know what policy was specified nor whether it was honored.

>> and "Email Authentication Results Names" in section 6.6 

By convention, each method specifies the same meanings for the same result names.  Yet, methods can have unique codes, for example softfail.  If you look at IANA table[*], the meaning of dmarc method is referred to [RFC7489] section 11.2.  That section does indeed give the definition of "fail" that Todd has extensively described.  However, we are going to obsolete that document, so redefining result names is not out of our reach.

[*] https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names

>> As for the parenthetical bits, I believe they too are covered in RFC 7601 

For parenthetical info to be machine readable, A-R consumer software has to be dedicated to A-R producer.  An blatant standardization shortcoming.

> [...] 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".

That is especially true for quarantine.  As DMARC is often verified by a filter during the SMTP exchange, the filter has to commission the MDA to possibly honor a quarantine request.  In order to do that, the filter needs to communicate the results of authentication to the delivery agent.  Not using A-R for this task, or resorting to parenthetical info, is preposterous.

I propose to add two new result name codes, named after the policy requests:

    dmarc=quarantine, and

    dmarc=reject (of course, you only see this if the filter didn't honor the request).

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Wed, 30 Dec 2020 08:48:05 -0500

On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <[email-masked]> wrote:

> is
> I agree with Michael here.  When a (trusted) dmarc=fail is seen
> downstream, its consumers neither know what policy was specified nor
> whether it was honored.
>

That depends on your definition of "downstream", I guess.

MDAs and local clients (web and mobile) at the mailbox provider will have
the information they need.

Third-party MUAs perhaps won't, but MUAs aren't really responsible for
message disposition in a way that is relevant to DMARC's primitive
disposition choices, except in those cases where they're POP clients that
download everything to a local message store, I guess; maybe in that case
DMARC policy request and DMARC validation results could be used to make the
Inbox v. Spam decision.

If the host recording the Auth-Res header is a true intermediary like a
mailing list server, there's no disposition information to record that will
matter to the downstream; in that case, if the intermediary rejects it, the
downstream will never see it, and if it doesn't reject it, then it's not
making any disposition decisions.

> 7601
> For parenthetical info to be machine readable, A-R consumer software has
> to be dedicated to A-R producer.  An blatant standardization shortcoming.
>

The text of 2.7.6 (RFC 8601) I believe indicates that the parenthetical is
just a comment:

   relay what data were used to perform an evaluation, such information

My position is that both the message handling request conveyed by the
domain owner in the p= value of their policy record and the message
disposition are "ancillary details of authentication results", because
while the disposition may be driven by those results, neither impacts the
results nor how those results are determined.

> That is especially true for quarantine.  As DMARC is often verified by a
> filter during the SMTP exchange, the filter has to commission the MDA to
> possibly honor a quarantine request.  In order to do that, the filter needs
> to communicate the results of authentication to the delivery agent.  Not
> using A-R for this task, or resorting to parenthetical info, is
> preposterous.
>

MDAs have been routing messages to spam folders on the instruction of MTAs
long before the Authentication-Results header existed. Many years ago when
I worked in email operations, our third-party software supported the
concept of the spam-filtering layer inserting an X- header to be read by
the MDA to use in inbox/spam folder placement. We're making assumptions in
this thread that the A-R header is driving things, but we really have no
idea how each mailbox provider does things unless we work there.

>     dmarc=reject (of course, you only see this if the filter didn't honor
I do not support this, because quarantine, reject, and none are not
Authentication Results, but are instead both policy requests and
disposition decisions.

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 05:55:41 -0800

On 12/30/20 5:48 AM, Todd Herr wrote:
> On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     downstream, its consumers neither know what policy was specified
>     nor whether it was honored.
>
>
> MDAs and local clients (web and mobile) at the mailbox provider will 
> have the information they need.

No they don't. I keep saying this, but you guys keep dismissing me. 
Painting up "fail" for p=none is absolutely the wrong thing to do. It is 
not what the user expects to see for a piece of mail that is perfectly 
acceptable to the originating domain. This is an error or omission, full 
stop.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 06:01:34 -0800

> Authentication Results, but are instead both policy requests and 
Then we should remove DMARC from auth-res altogether because it is not 
an authentication mechanism. Either we fully support DMARC in auth-res 
or remove it. This half-assed state of unlessness serves nobody.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 06:48:14 -0800

On 12/30/20 5:48 AM, Todd Herr wrote:
> disposition choices, except in those cases where they're POP clients 
> that download everything to a local message store, I guess; maybe in 
> that case DMARC policy request and DMARC validation results could be 
> used to make the Inbox v. Spam decision.
>
This is a failure of imagination. If spam filters are too worried about 
false positives to take action on p=reject and p=quarantine, that 
doesn't mean a human can't. Imagine three colors, green, orange and red. 
If I see red, I am immediately suspicious of it and treat it as suspect 
when evaluating the context and semantics in the message -- something 
that spam filters do not do. Same to a lesser degree orange. If auth-res 
provided me the proper information, I could do that today. I cannot 
because it does not. As it stands today, auth-res is useless for DMARC.

Mike

---

From: Dotzero <[email-masked]>
Date: Wed, 30 Dec 2020 10:05:50 -0500

Absolutely agree with Todd's analysis and comments. +1

Michael Hammer

---

From: Laura Atkins <[email-masked]>
Date: Wed, 30 Dec 2020 15:06:53 +0000

> On 30 Dec 2020, at 09:42, Alessandro Vesely <[email-masked]> wrote:
> 
>>>> Unless those values in parens are a MUST requirement, the dmarc=fail is highly misleading.
> 
> 

The auth-res result posted as an example of DMARC failing earlier in this thread: 
Authentication-Results: mx.google.com <http://mx.google.com/>;
       dkim=pass header.i=@ietf.org <mailto:header.i=@ietf.org> header.s=ietf1 header.b=aayvF8Pg;
       dkim=pass header.i=@ietf.org <mailto:header.i=@ietf.org> header.s=ietf1 header.b="PwU4/yuQ";
       dkim=neutral (body hash did not verify) header.i=@mrochek.com <mailto:header.i=@mrochek.com> header.s=201712 header.b=PRr8Q7Zv;
       spf=pass (google.com <http://google.com/>: domain of [email-masked] <mailto:[email-masked]> designates 4.31.198.44 as permitted sender) smtp.mailfrom=[email-masked] <mailto:smtp.mailfrom=[email-masked]>;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com <http://mrochek.com/>
The policy statement is right there: p=NONE. 

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 07:17:21 -0800

On 12/30/20 7:06 AM, Laura Atkins wrote:
> Authentication-Results:mx.google.com  <http://mx.google.com>;
>         dkim=passheader.i=@ietf.org  header.s=ietf1 header.b=aayvF8Pg;
>         dkim=passheader.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  <http://google.com>: domain [email-masked]  designates 4.31.198.44 as permitted sender)smtp.mailfrom=[email-masked];
>         dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com  <http://mrochek.com>
No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and 
be valid.

Mike

---

From: Todd Herr <[email-masked]>
Date: Wed, 30 Dec 2020 10:31:46 -0500

> acceptable to the originating domain. This is an error or omission, full
I'm sorry, but I don't know that I've seen an example of painting up "fail"
for p=none in my Gmail or Google Apps clients; it is possible you can share
a screencap of an example of what you're referring to here, please?

--

---

From: Todd Herr <[email-masked]>
Date: Wed, 30 Dec 2020 10:35:09 -0500

On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <[email-masked]> wrote:

> Then we should remove DMARC from auth-res altogether because it is not an
> authentication mechanism. Either we fully support DMARC in auth-res or
> remove it. This half-assed state of unlessness serves nobody.
>
>
> I disagree. DMARC has rules that determine whether or not a message is
deemed to be authenticated - did it pass SPF or DKIM and did it do so with
a domain that aligns with the RFC5322.From domain. The currently valid
states for those rules are pass, fail, temperror, and permerror.

Policy and disposition (none, quarantine, reject) apply to decisions made
based on the authentication results; they are not states for the
authentication checks themselves.

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 07:35:59 -0800

On 12/30/20 7:31 AM, Todd Herr wrote:
> On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas <[email-masked] 
>>         I agree with Michael here.  When a (trusted) dmarc=fail is
>>         seen downstream, its consumers neither know what policy was
>>         specified nor whether it was honored.
>>
>>
>>     MDAs and local clients (web and mobile) at the mailbox provider
>>     will have the information they need.
>
>     No they don't. I keep saying this, but you guys keep dismissing
>     me. Painting up "fail" for p=none is absolutely the wrong thing to
>     do. It is not what the user expects to see for a piece of mail
>     that is perfectly acceptable to the originating domain. This is an
>     error or omission, full stop.
>
>
>
> I'm sorry, but I don't know that I've seen an example of painting up 
> "fail" for p=none in my Gmail or Google Apps clients; it is possible 
> you can share a screencap of an example of what you're referring to 
> here, please?
>
I already said there is a thunderbird extension called dkim-verify that 
does exactly that. It says "DMARC: fail". That is highly misleading to 
the user.

Mike

---

From: Todd Herr <[email-masked]>
Date: Wed, 30 Dec 2020 10:40:15 -0500

On Wed, Dec 30, 2020 at 10:36 AM Michael Thomas <[email-masked]> wrote:

> "fail" for p=none in my Gmail or Google Apps clients; it is possible you
> can share a screencap of an example of what you're referring to here,
> please?
>
>
> does exactly that. It says "DMARC: fail". That is highly misleading to the
> user.
>
>
>
I see.

I wrote "MDAs and local clients (web and mobile) at the mailbox provider",
and I was referring to things such as Gmail's web client, Gmail's mobile
client, etc.

You are talking about an extension for Thunderbird, which is different from
what I'm talking about.

Thank you for the clarification.

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 07:41:37 -0800

On 12/30/20 7:35 AM, Todd Herr wrote:
> On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <[email-masked] 
>>     I do not support this, because quarantine, reject, and none are
>>     not Authentication Results, but are instead both policy requests
>>     and disposition decisions.
>>
>     Then we should remove DMARC from auth-res altogether because it is
>     not an authentication mechanism. Either we fully support DMARC in
>     auth-res or remove it. This half-assed state of unlessness serves
>     nobody.
>
>
> deemed to be authenticated - did it pass SPF or DKIM and did it do so 
> with a domain that aligns with the RFC5322.From domain. The currently 
> valid states for those rules are pass, fail, temperror, and permerror.
>
> Policy and disposition (none, quarantine, reject) apply to decisions 
> made based on the authentication results; they are not states for the 
DMARC != Auth-res. Auth-res provides all kinds of useful information 
than just pass/fail. For DMARC Auth-res should provide what the policy 
was at a bare minimum. But none of this seems to have any normative 
language anywhere which is a problem unto itself. DMARC in auth-res 
seems to be an orphan.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 07:47:57 -0800

On 12/30/20 7:40 AM, Todd Herr wrote:
> I already said there is a thunderbird extension called dkim-verify 
> that does exactly that. It says "DMARC: fail". That is highly 
> misleading to the user.
>
>
> I see.
>
> I wrote "MDAs and local clients (web and mobile) at the mailbox 
> provider",  and I was referring to things such as Gmail's web client, 
> Gmail's mobile client, etc.
>
> You are talking about an extension for Thunderbird, which is different 
> from what I'm talking about.
>
This would be a problem for any MUA. That's the point. It's not 
different, it's the exact same problem for every MUA. There is no 
normative mechanism that gives anything downstream from the DMARC check 
producing the auth-res to be able to use that information correctly. And 
we sure don't want billions of MUA's doing DMARC checks on their own 
because of the inadequacy of auth-res. There is code in that extension 
to do exactly that. If that were widespread, it would be disastrous.

Mike

---

From: Dotzero <[email-masked]>
Date: Wed, 30 Dec 2020 11:22:07 -0500

On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas <[email-masked]> wrote:

> DMARC != Auth-res. Auth-res provides all kinds of useful information than
> just pass/fail. For DMARC Auth-res should provide what the policy was at a
> bare minimum. But none of this seems to have any normative language
> anywhere which is a problem unto itself. DMARC in auth-res seems to be an
> orphan.
>
> Mike
>

You just stated the case as to why this discussion should be ruled out of
scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan"

This is the IETF DMARC working group, not the AUTH-RES working group. You
gave the example of someone writing a crappy Thunderbird extension as a
reason for the working group to change its focus. Perhaps getting the
extension author to fix their extension might be a more fruitful effort.

Michael Hammer

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 08:30:46 -0800

On 12/30/20 8:22 AM, Dotzero wrote:
>
>     DMARC != Auth-res. Auth-res provides all kinds of useful
>     information than just pass/fail. For DMARC Auth-res should provide
>     what the policy was at a bare minimum. But none of this seems to
>     have any normative language anywhere which is a problem unto
>     itself. DMARC in auth-res seems to be an orphan.
>
>     Mike
>
>
> You just stated the case as to why this discussion should be ruled out 
> of scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be 
> an orphan"
>
> This is the IETF DMARC working group, not the AUTH-RES working group. 
> You gave the example of someone writing a crappy Thunderbird extension 
> as a reason for the working group to change its focus. Perhaps getting 
> the extension author to fix their extension might be a more fruitful 
> effort.
>

Because the author *can't* fix their extension for the 100th time. There 
is no normative mechanism for transporting the DMARC state in the 
auth-res header. And if the working group is not willing to do its part 
for auth res, then auth-res should just be moved to historic since there 
is nobody to maintain it, and no place to discuss its shortcomings. 
Requiring every downstream MTA and MUA to do DMARC policy checks would 
be a mess and *that* is most certainly in scope as scaling is an 
internet issue.

Mike

---

From: Dotzero <[email-masked]>
Date: Wed, 30 Dec 2020 11:38:29 -0500

On Wed, Dec 30, 2020 at 11:30 AM Michael Thomas <[email-masked]> wrote:

> is no normative mechanism for transporting the DMARC state in the auth-res
> header. And if the working group is not willing to do its part for auth
> res, then auth-res should just be moved to historic since there is nobody
> to maintain it, and no place to discuss its shortcomings. Requiring every
> downstream MTA and MUA to do DMARC policy checks would be a mess and *that*
> is most certainly in scope as scaling is an internet issue.
>
> Mike
>

And for the second time, that is not a DMARC problem, it is an auth-res
problem. It is also a problem for someone who writes an extension without
understanding what they are presenting to the end user.

Michael Hammer

---

From: Todd Herr <[email-masked]>
Date: Wed, 30 Dec 2020 11:38:28 -0500

On Wed, Dec 30, 2020 at 10:48 AM Michael Thomas <[email-masked]> wrote:

> This would be a problem for any MUA. That's the point. It's not different,
> it's the exact same problem for every MUA. There is no normative mechanism
> that gives anything downstream from the DMARC check producing the auth-res
> to be able to use that information correctly. And we sure don't want
> billions of MUA's doing DMARC checks on their own because of the inadequacy
> of auth-res. There is code in that extension to do exactly that. If that
> were widespread, it would be disastrous.
>
>
>
As I attempted to communicate in a different message, we're making
assumptions about the use of the A-R header that may not be entirely valid.
RFC 8601 says in its Abstract:

   Any receiver-side software, such as mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users or to make sorting and
filtering decisions.

It does not say, however, "can use this header field, AND ONLY THIS HEADER
FIELD, to relay that information"; it doesn't even require that the header
be included.

There are quite a number of headers inserted into messages at the major
mailbox providers, and I'd wager that some of them are used by the MDAs and
local clients instead of the A-R header when executing their message
delivery and display actions; I might be wrong, but I imagine the folks
who've put together these enormous email systems do things in such a way
that maximizes efficiency for them.

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 08:38:52 -0800

> the extension author to fix their extension might be a more fruitful 

Let me put this another way:

"The verifying DMARC SHOULD encode its results into an 
Authentication-Results header [RFC 8601] for downstream MTA's, MDA's, 
and MUA in the same administrative domain, and those downstream entities 
SHOULD use the Authentication-Results so as to not put undue burden on 
the DNS infrastructure".

Anything that would cause them to have to violate that SHOULD is a 
problem that needs to be resolved.

Mike, getting tired of the circularity going on here

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Dec 2020 08:42:06 -0800

At this point, this thread is deeply unproductive and preventing work on
open tickets.

Mike, I hear that you believe better normative accounting for DMARC results
in auth-res is needed. If this is correct, please open a ticket, and the
working group will address it later as we've committed to discussing all
open tickets.

Seth, as Chair

On Wed, Dec 30, 2020 at 8:39 AM Michael Thomas <[email-masked]> wrote:

> Authentication-Results header [RFC 8601] for downstream MTA's, MDA's, and
> MUA in the same administrative domain, and those downstream entities SHOULD
> use the Authentication-Results so as to not put undue burden on the DNS
> infrastructure".
>
> Anything that would cause them to have to violate that SHOULD is a problem
> that needs to be resolved.
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Dec 2020 12:12:22 -0500

> language anywhere which is a problem unto itself. DMARC in auth-res

A-R was a moving target for a long period and I am not sure it is 
completed for the task at hand.

It was why my own wcSMTP used name space field values and made use of 
for potential visual reports, wcAVS filters at the backend and 
potentially the MUA frontend.  That has always been a consideration 
since day one.

But it was also a consideration the MUA filter could only safely apply 
it to messages verified by the host, i.e. the A-R record MUST was 
created by the host by domain name which the MUA client trust.

This brings up the important fact, the most mail host have a 
responsibility to filter "bad" mail before the user gets it and not 
pass it on to potential phishable users. However, in this real market, 
like even in this WG, we have both camps; those who believe strongly 
in rejection at SMTP (system wide) and those who believe of accepting 
all and passing the buck to the user (user-level filters). IMO, you 
can't fight it. You accept both and program for both because both exist.

For example for Mike's message, its a simple A-R:

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=mtcc.com 
header.s=fluffulence header.i=mtcc.com;

There are no DKIM-POLICY protocol records like ADSP or DMARC.  No A-R 
line for DMARC means the domain have NO record. It is not 
participating in DMARC, purposely or not. Having no A-R line avoids 
making erroneous interpretations by consumer like Mike has pointed out.

Any A-R evaluation looking for the specific DMARC verification bits as 
part of its algorithm, but sees none, MUST use the default input and 
output values for a domain that lacks a DMARC record.  For DMARC, when 
no record exist, the default values are (please confirm, I am going 
off my https://secure.winserver.com/public/wcDMARC wizard form values).

p=none
sp=none
adkim=relaxed
aspf=relaxed
pct=100%
rua=0
ruf=0
rf=afrf
ri=86400

The dmarc= value SHOULD not be dmarc=fail nor dmarc=pass because no 
DMARC record exist.  So if an A-R is written for a non-DMARC domain, 
it should be perhaps write:

   dmarc=unknown author.d=gmail.com signer.d=gmail.com (originating 
signer);

or

   dmarc=none author.d=gmail.com signer.d=gmail.com (originating signer);

Although the dmarc=none could erroneously suggest a DMARC record exist 
with a p=none policy, when a real policy exist, then a policy= tag 
used in our A-R, like:

   dmarc=dkim-fail policy=none author.d=gmail.com signer.d=gmail.com 
(originating signer);

which reads:

The author.d=gmail.com has a DMARC none policy. It has an aligned 
author and signer domain, but DMARC failed due to a dkim-fail 
signature which the A-R dkim line shows:

   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com 
header.s=20161025 header.i=gmail.com;

I am not suggesting this or no DMARC A-R line should be written when 
the domain lacks a DMARC record.

If a A-R dmarc line is recorded, it should be readable by humans. It 
should not erroneously misdirect an A-R evaluator routine when a DMARC 
does not exist. Using the comment field SHOULD be reserved for 
non-standard HUMAN readable data.  But some of used it to fill in the 
gaps we wanted A-R for verification results, i.e. for SPF, the ip name 
field.

Overall, I agree, resolving the A-R name space technical issue SHOULD 
be resolve in the WG for DMARC-bis. I think it is well worth the 
effort to define what we need and then use this for the update up the 
A-R specs to create a more common and useful name space to all.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 09:16:08 -0800

On 12/30/20 8:42 AM, Seth Blank wrote:
> At this point, this thread is deeply unproductive and preventing work 
> on open tickets.
>
> Mike, I hear that you believe better normative accounting for DMARC 
> results in auth-res is needed. If this is correct, please open a 
> ticket, and the working group will address it later as we've committed 
> to discussing all open tickets.
>
Later? How much later? Looking at the open tickets it looks you have 
about 5 more years of "later". And I would say the chairs teeing up 
tickets would be a far more efficient means of driving the process than 
shutting down discussions that will become tickets. That other thread on 
privacy should have been closed out weeks ago.

I believe there are several separate issues:

1) There is a scaling issue for DMARC if it is required to be used 
beyond the boundary of an administrative domain, and especially if MUA's 
start running them; there is nothing that says that they can't or shouldn't.

2) Auth-res process-wise is an orphan with no means of discussing it in 
any working group even though it's standards track and has issues 
requiring coordination with this working group

3) The fundamental question that Ned brought up which is whether 
Auth-res is a protocol at all. If it's really just a debugging tool to 
be use by humans, it should definitely just be informational, and 
probably historic. Either Auth-res is useful and supported or not and 
should be killed

4) Should DMARC require a normative Authentication-Results Requirements 
section? This process-wise would solve the problem of auth-res in (2) 
and shift the specification of that normative text back to the document 
that is affected by it, letting Auth-res just be a transport vehicle so 
that it doesn't require yet another working group-less update. That is 
what we should have done from the start, but auth-res is an accident of 
history.

Mike

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Dec 2020 09:20:45 -0800

Please follow the process stated by the chairs, open the tickets, and we’ll
tear through the items. It’s disruptive threads that take us off task and
make it feel like “five years” worth of tickets. Most in the tracker are
simple and close to NOOPs if we stay focused.

Seth, as Chair

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Dec 2020 18:34:36 +0100

>> valid states for those rules are pass, fail, temperror, and permerror.

They are not enough to convey the information needed.  That's why I propose an 
addition.

>> authentication checks themselves.

They become states for the authentication check in the moment that we publish 
that dmarc=quarantine means the message failed DMARC check and the DMARC record 
asked that the message be quarantined in that case.

Todd clearly said that a mailbox provider currently has to resort to temporary 
header fields in order to communicate results of authentication checks to a 
downstream, non-standard agent.  Perhaps like so:

X-Authentication-Results: dmarc=quarantine?

Mail systems are not the prerogative of large mailbox providers who roll out 
their own code.  Standards exist to allow compliant code to interoperate.

> This is the IETF DMARC working group, not the AUTH-RES working group.

Indeed.  Auth-Res values and meaning are defined precisely in the document we 
are writing.  RFC 8601 is extensible, and it only covers methods that were 
already in use in 2009, when RFC 5451 came out.

> You gave the example of someone writing a crappy Thunderbird extension as a 
> reason for the working group to change its focus.

The code that Philippe Lieser wrote is strictly conforming to standards.  It is 
crappy only because the DMARC standard is, at least as far as specifying 
authentication methods is concerned.

> Perhaps getting the extension author to fix their extension might be a more
> fruitful effort.

By my bitty knowledge of Philippe's reasoning, I'd bet he'd ask what RFC says 
where to get a different status than what his add-on displays.  Of course he's 
not going to tentatively parse every known A-R comment.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Wed, 30 Dec 2020 12:40:54 -0500

> downstream, non-standard agent.  Perhaps like so:
I know we're supposed to let this thread die, but I wanted to clarify
something here.

It was not my intent to say "a mailbox provider has to resort to temporary
header fields in order to communicate results..."

What I was trying to say is "Absent our working for a given mailbox
provider, we don't know which header(s) are used by the mailbox provider to
convey message disposition and display information to their MDAs and UIs."

I apologize for the confusion.

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 10:02:49 -0800

On 12/30/20 9:20 AM, Seth Blank wrote:
> Please follow the process stated by the chairs, open the tickets, and 
> we’ll tear through the items. It’s disruptive threads that take us off 
> task and make it feel like “five years” worth of tickets. Most in the 
> tracker are simple and close to NOOPs if we stay focused.
>
Filed. And I still have no  idea what tickets we're actually supposed to 
be talking about. And since when did IETF process require tickets to be 
opened to discuss issues?

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Dec 2020 19:13:21 +0100

On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote:
> And for the second time, that is not a DMARC problem, it is an auth-res problem.

Standardizing the result names for dmarc authentication method is an integral 
part of DMARC specification.

Added ticket 91
https://trac.ietf.org/trac/dmarc/ticket/91

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 10:21:33 -0800

On 12/30/20 10:13 AM, Alessandro Vesely wrote:
> Standardizing the result names for dmarc authentication method is an 
> integral part of DMARC specification.
>
> Added ticket 91
I opened a ticket too which basically says that there should be a 
normative Authentication-Results Requirements section in the base 
specifications. That was a process error from the very beginning with 
auth-res and its weird semi-official status. I don't think it has ever 
been discussed whether it is even a protocol or not as Ned brought up 
(opened a ticket on that too).

Mike

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Dec 2020 10:29:23 -0800

Thank you filing these tickets.

With regards to which tickets are actively open, I’ve asked the document
editors to push on open tickets, stand by.

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Dec 2020 10:31:50 -0800

I'll try to propose some text for the ones that would require 
modifications in the ticket. I assume that is appropriate?

Mike

On 12/30/20 10:29 AM, Seth Blank wrote:
> With regards to which tickets are actively open, I’ve asked the 
> document editors to push on open tickets, stand by.
>
> On Wed, Dec 30, 2020 at 10:21 Michael Thomas <[email-masked] 
>     <https://trac.ietf.org/trac/dmarc/ticket/91>
>     >
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>
> -- 
> *Seth Blank*| VP, Standards and New Technologies
> *e:[email-masked] <mailto:[email-masked]>
> *p:*415.273.8818
>
>
> 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.
>

---

From: Seth Blank <[email-masked]>
Date: Wed, 30 Dec 2020 10:34:32 -0800

Yes, put whatever you think is appropriate in the ticket, including a link
from the dmarc archive to this thread, so that when it is reopened the
group has appropriate context

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Dec 2020 20:10:08 +0100

On Wed 30/Dec/2020 18:12:22 +0100 Hector Santos wrote:
> 
> Any A-R evaluation looking for the specific DMARC verification bits as part of 
> its algorithm, but sees none, MUST use the default input and output values for 
> a domain that lacks a DMARC record.  For DMARC, when no record exist, the 
> default values are (please confirm, I am going off my 
> https://secure.winserver.com/public/wcDMARC wizard form values).
> 
> p=none
> sp=none
> adkim=relaxed
> aspf=relaxed
> pct=100%
> rua=0
> ruf=0
> rf=afrf
> ri=86400
> 
> The dmarc= value SHOULD not be dmarc=fail nor dmarc=pass because no DMARC 
> record exist.  So if an A-R is written for a non-DMARC domain, it should be 
> perhaps write:
> 
>    dmarc=unknown author.d=gmail.com signer.d=gmail.com (originating signer);
> 
> or
> 

I like better the latter (except that author.d should be header.from and 
signer.d is useless as there must be one or more dkim=pass with a matching 
header.d=gmail.com or spf=pass with matching helo/ mailfrom property.)

> Although the dmarc=none could erroneously suggest a DMARC record exist with a 
> p=none policy

Having no record or just "v=DMARC1; p=none;" should be equivalent.  ADSP 
explicitly said so, preferring an existing record with default values for DNS 
caching performance.

IMHO, we're being somewhat fussy by /requiring/ p=none.

> when a real policy exist, then a policy= tag used in our A-R, like:
> 

should be:

     dmarc=fail policy.dmarc=none

The moment that you deploy existing software, using unregistered properties 
becomes problematic.  Reporting the domain where a DMARC record was found might 
be useful.  However, if you want to use it you should register it.  I'd suggest 
dns.zone=gmail.com, as that ptype.property is already registered, albeit for a 
different method.

> which reads:
> 
> The author.d=gmail.com has a DMARC none policy. It has an aligned author and 
> signer domain, but DMARC failed due to a dkim-fail signature which the A-R dkim 
> line shows:
> 
>    dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com header.s=20161025 
> header.i=gmail.com;

Obviously, SPF failed too.  It makes little sense to specify all possible 
failure reason on the A-R line.

> I am not suggesting this or no DMARC A-R line should be written when the domain 
> lacks a DMARC record.
> 
> If a A-R dmarc line is recorded, it should be readable by humans. It should not 
> erroneously misdirect an A-R evaluator routine when a DMARC does not exist. 
> Using the comment field SHOULD be reserved for non-standard HUMAN readable 
> data.  But some of used it to fill in the gaps we wanted A-R for verification 
> results, i.e. for SPF, the ip name field.
> 
> Overall, I agree, resolving the A-R name space technical issue SHOULD be 
> resolved in the WG for DMARC-bis. I think it is well worth the effort to define 
> what we need and then use this for the update up the A-R specs to create a more 
> common and useful name space to all.

Right.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Dec 2020 20:38:43 +0100

On Wed 30/Dec/2020 16:17:21 +0100 Michael Thomas wrote:
>> Authentication-Results:mx.google.com;
>>         spf=pass (google.com: domain [email-masked]  designates 4.31.198.44 as permitted sender)smtp.mailfrom=[email-masked];
> No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and be valid.

Correct.  However, it could have been:

     dmarc=fail policy.dmarc=none header.from=mrochek.com

where the property meaning is defined as "Evaluated DMARC policy applied/to be 
applied after policy options including pct: and sp: have been processed. Must 
be none, quarantine, or reject."

That value appears on the IANA page[*] referring to RFC7489 for its definition. 
  However, Section 11.1 of RFC 7489 only mentions the "from" property.

IMHO, dmarc=quarantine is more direct than dmarc=fail policy.dmarc=quarantine.

In addition, policy.dmarc as a ptype.property pair sounds redundant.  Perhaps 
it should be policy.result, to emphasize that it has been computed after 
checking pct= and sp= (to be added: np=) and the alignment of header.from with 
respect to the dns zone where the record was found.

Best
Ale
-- 

[*] https://www.iana.org/assignments/email-auth/email-auth.xhtml

---

From: "John Levine" <[email-masked]>
Date: 30 Dec 2020 15:54:31 -0500

>     dmarc=fail policy.dmarc=none header.from=mrochek.com

Ticket #86 already suggests we define a few more items to put in a DMARC A-R
clause so we don't have to try and guess them from comments.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 31 Dec 2020 20:11:34 -0800

> privacy should have been closed out weeks ago.

The alternative is to have all of those discussions open at the same time.
It's not hard to imagine a way to ensure even less progress than we're
making now.

I believe there are several separate issues:
> [...]

I don't understand the basis for this assertion.

There are many standards track documents that are not historic but don't
currently have a working group developing them.  I don't think of them as
orphans.  If the IETF has work to do on one of them, we either spin up a
working group to do the work, or an AD can sponsor the work, or an existing
WG can negotiate to extend its charter to cover the work.

This WG already extended RFC 7601 to become RFC 8601.  It could, in theory,
do so again.

> probably historic. Either Auth-res is useful and supported or not and

This is the first time I've heard that it's not useful.  If that were the
case, I wonder why it's gone through four iterations (RFC 5451, then RFC
7001, then RFC 7601, and now RFC 8601).

> what we should have done from the start, but auth-res is an accident of

Section 6.7 of RFC 7489 recommends use of A-R.  If the WG chooses to change
that to a MUST, that seems reasonable to me.

-MSK