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

[Murray S. Kucherawy]

On Wed, Dec 30, 2020 at 9:16 AM Michael Thomas  wrote:

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

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

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.

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
>

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

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

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article <2717cf5f-bec9-d561-d7f7-ac167dc7c...@tana.it> you write:
>>> dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mrochek.com
>>> The policy statement is right there: p=NONE.
>>>
>> 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

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

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

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

[Alessandro Vesely]

On Wed 30/Dec/2020 16:17:21 +0100 Michael Thomas wrote:


On 12/30/20 7:06 AM, Laura Atkins wrote:
The auth-res result posted as an example of DMARC failing earlier in this 
thread:

Authentication-Results: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: domain ofdmarc-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
The policy statement is right there: p=NONE.


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
















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

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

[Alessandro Vesely]

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

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



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:

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



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
















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

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

[Seth Blank]

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

On Wed, Dec 30, 2020 at 10:31 Michael Thomas  wrote:

> 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:
>
> 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.
>
> On Wed, Dec 30, 2020 at 10:21 Michael Thomas  wrote:
>
>>
>> On 12/30/20 10:13 AM, Alessandro Vesely wrote:
>> > 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
>> >
>> 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
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> --
> *Seth Blank* | VP, Standards and New Technologies
> *e:* s...@valimail.com
> *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.
>
> --

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

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:

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.


On Wed, Dec 30, 2020 at 10:21 Michael Thomas > wrote:



On 12/30/20 10:13 AM, Alessandro Vesely wrote:
> 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

>
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

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


--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com 
*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.


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

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

[Seth Blank]

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.

On Wed, Dec 30, 2020 at 10:21 Michael Thomas  wrote:

>
> On 12/30/20 10:13 AM, Alessandro Vesely wrote:
> > 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
> >
> 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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 12/30/20 10:13 AM, Alessandro Vesely wrote:

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

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

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

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

[Alessandro Vesely]

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
























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

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

[Michael Thomas]

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

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

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

[Todd Herr]

On Wed, Dec 30, 2020 at 12:34 PM Alessandro Vesely  wrote:

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

-- 

*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

[Alessandro Vesely]

On Wed 30/Dec/2020 17:22:07 +0100 Dotzero wrote:

On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas  wrote:

On 12/30/20 7:35 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas  wrote:

On 12/30/20 5:48 AM, Todd Herr wrote:


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


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.

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.


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




Policy and disposition (none, quarantine, reject) apply to decisions made
based on the authentication results; they are not states for the
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.




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.


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.



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


























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

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

[Seth Blank]

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

On Wed, Dec 30, 2020 at 09:16 Michael Thomas  wrote:

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

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

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

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

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

[Hector Santos]

On 12/30/2020 10:41 AM, Michael Thomas 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.


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.



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


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

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

[Seth Blank]

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

>
> On 12/30/20 8:22 AM, Dotzero wrote:
>
>
> 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.
>
>
> 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
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

On 12/30/20 8:22 AM, Dotzero wrote:


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.




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

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

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

[Todd Herr]

On Wed, Dec 30, 2020 at 10:48 AM Michael Thomas  wrote:

>
> 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.
>
> Thank you for the clarification.
>
> 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.

-- 

*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

[Dotzero]

On Wed, Dec 30, 2020 at 11:30 AM Michael Thomas  wrote:

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

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

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

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

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

[Dotzero]

On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas  wrote:

>
> On 12/30/20 7:35 AM, Todd Herr wrote:
>
> On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas  wrote:
>
>>
>> On 12/30/20 5:48 AM, Todd Herr wrote:
>>
>>
>> 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).
>>>
>>>
>> 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.
>>
>>
>> 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.
>
> 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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Michael Thomas]

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.


Thank you for the clarification.

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

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

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

[Michael Thomas]

On 12/30/20 7:35 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas > wrote:



On 12/30/20 5:48 AM, Todd Herr wrote:


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


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.


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.


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

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

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

[Todd Herr]

On Wed, Dec 30, 2020 at 10:36 AM Michael Thomas  wrote:

>
> On 12/30/20 7:31 AM, Todd Herr wrote:
>
> On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas  wrote:
>
>>
>> On 12/30/20 5:48 AM, Todd Herr wrote:
>>
>>
>> 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.
>
>
>
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.

-- 

*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/30/20 7:31 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas > wrote:



On 12/30/20 5:48 AM, Todd Herr wrote:

On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely mailto:ves...@tana.it>> wrote:

On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> 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 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.


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

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

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

[Todd Herr]

On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas  wrote:

>
> On 12/30/20 5:48 AM, Todd Herr wrote:
>
>
> 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).
>>
>>
> 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.
>
>
> 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.

-- 

*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

[Todd Herr]

On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas  wrote:

>
> On 12/30/20 5:48 AM, Todd Herr wrote:
>
> On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely  wrote:
>
>> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
>> > 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 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.
>
> 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?

-- 

*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/30/20 7:06 AM, Laura Atkins wrote:
The auth-res result posted as an example of DMARC failing earlier in 
this thread:

Authentication-Results: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  : domain 
ofdmarc-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  

The policy statement is right there: p=NONE.

No. That is not guaranteed whatsoever. It could say "(eat at Joe's)" and 
be valid.


Mike

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

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

[Laura Atkins]

> On 30 Dec 2020, at 09:42, Alessandro Vesely  wrote:
> 
> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
>> 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 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.

The auth-res result posted as an example of DMARC failing earlier in this 
thread: 
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 

The policy statement is right there: p=NONE. 

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

[Dotzero]

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

Michael Hammer

On Wed, Dec 30, 2020 at 8:48 AM Todd Herr  wrote:

> On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely  wrote:
>
>> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
>> > 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 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.
>
>
>>
>> >> As for the parenthetical bits, I believe they too are covered in RFC
>> 7601
>> >> section 2.7.6:
>>
>>
>> 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:
>
>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 were 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)
>
>
>
> 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.
>
>
>>
>>
>> > [...] 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.
>>
>
> 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.
>
>
>>
>> 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).
>>
>>
> I do not support this, because quarantine, reject, and none are not
> Authentication Results, but are instead both policy requests and
> disposition decisions.
>
> --
>
> *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 

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

[Michael Thomas]

On 12/30/20 5:48 AM, Todd Herr wrote:


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.


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

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

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

[Michael Thomas]

On 12/30/20 5:48 AM, Todd Herr wrote:


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


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.


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/30/20 5:48 AM, Todd Herr wrote:
On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely > wrote:


On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> 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 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.


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

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

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

[Todd Herr]

On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely  wrote:

> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> > 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 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.


>
> >> As for the parenthetical bits, I believe they too are covered in RFC
> 7601
> >> section 2.7.6:
>
>
> 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:

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



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.


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

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.


>
> 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).
>
>
I do not support this, because quarantine, reject, and none are not
Authentication Results, but are instead both policy requests and
disposition decisions.

-- 

*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

[Alessandro Vesely]

On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:

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



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 



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 
section 2.7.6:



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





























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

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

[Alessandro Vesely]

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











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

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] 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] 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] 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] 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] 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] 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] auth-res vs. dmarc

[Hector Santos]

On 12/28/2020 8:17 AM, Todd Herr wrote:

On Sat, Dec 26, 2020 at 6:48 PM Michael Thomas mailto:m...@mtcc.com>> 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)?
--


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 

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

[Todd Herr]

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

-- 

*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

[dmarc-ietf] auth-res vs. dmarc

[Michael Thomas]

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

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