Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors

From: "Jim Fenton" <[email-masked]>
Date: Wed, 04 Nov 2020 17:38:31 -0800

I gather then that policy is part of the Base specification, and that it 
is assumed that reporting will not be implemented without also 
implementing policy. I don’t think that’s a good assumption.

I would suggest instead that the base specification describe the common 
pieces: lookup of the DMARC record from the From: header field (or 
perhaps some combination of header fields recently discussed), format of 
the DMARC record making provision for extensibility by other DMARC 
specifications, and anything else that is common to both policy and 
reporting.

A second specification would be policy, including much of what is in 
Section 6 of Murray’s draft except for things like policy discovery 
that would be in the base specification.

I’m neutral on whether the aggregate and failure reporting 
specifications are separate or combined.

-Jim

On 27 Oct 2020, at 9:29, Seth Blank wrote:

> One of the primary activities of the WG to review and improve the base
> DMARC specification. As the chairs  sat down and reviewed the issues 
> raised
> by everyone in the issue tracker
> (https://trac.ietf.org/trac/dmarc/report/1), we felt it would be 
> better to
> split RFC7489 into three
> documents. All this work will benefit from multiple document editors
> working on specific pieces and interacting with the WG. After an open 
> call
> for volunteers, we selected individuals from the community with the 
> idea of
> balancing bringing new document authors with those with experience 
> with the
> IETF process.
>
> Assuming draft-kucherawy-dmarc-dmarcbis is adopted (see the adoption 
> thread
> started by Tim), we will then split the draft into three documents 
> scoped
> as follows, with the corresponding editors below.
>
> The drafts will live in GitHub, but all issues are to be managed via 
> the
> IETF Trac tool. All issues will continue to be discussed and resolved 
> on
> the mailing list.
>
> 1. Base Spec
>
> * Define terms and operational implications that are now better 
> understood
> * Clean up confusing or remove unused tags
> * Address nits and errata
> * Clarify Organizational Domain lookups or remove definition from base 
> spec
> * Incorporate ARC or something that deals with indirect mailflows
>
> Editors:
> - Emil Gustafsson, Google
> - Todd Herr, Valimail
> - John Levine
>
> 2. Aggregate reporting
>
> * Address reporting nits and clarifications
> * Provide for more flexible reporting
> * Handle ARC data in a structured manner
>
> Editors
> - Alex Brotman, Comcast
>
> 3. Failure reporting
>
> * Create a simplified failure report
> * Address privacy considerations
>
> Editors
> - Steve Jones, LinkedIn
> - Alessandro Vesely
>
> Thanks everyone, and join us in thanking our editors for volunteering,
>
> Seth, Tim, and Alexey, as Chairs
>
> -- 
>
> *Seth Blank* | VP, Standards and New Technologies
> *e:* [email-masked]
> *p:* 415.273.8818
>
>
> This email and all data transmitted with it contains confidential 
> and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is 
> prohibited
> and may be unlawful. Please immediately notify the sender by replying 
> to
> this email and then delete it from your system.

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Todd Herr <[email-masked]>
Date: Thu, 5 Nov 2020 11:46:19 -0500

On Wed, Nov 4, 2020 at 8:38 PM Jim Fenton <[email-masked]> wrote:

> is assumed that reporting will not be implemented without also implementing
> policy. I don’t think that’s a good assumption.
>
> pieces: lookup of the DMARC record from the From: header field (or perhaps
> some combination of header fields recently discussed), format of the DMARC
> record making provision for extensibility by other DMARC specifications,
> and anything else that is common to both policy and reporting.
>
> Section 6 of Murray’s draft except for things like policy discovery that
> would be in the base specification.
>
> I’m neutral on whether the aggregate and failure reporting specifications
> are separate or combined.
>
>
> Hatless...

Respectfully, I disagree with the suggestion made here to move policy to a
separate document. DMARC at its core is the requested mail receiver policy
that's expressed in the p= tag; in the draft specification, p= and v= are
the only two required tags, and I can't envision a world where policy isn't
implemented as a requirement to implement DMARC.

Moving discussion of policy to a second specification would render any base
specification to be no more than effectively a table of contents pointing
to other documents, which seems to me to be a pointless document to produce.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 5 Nov 2020 18:31:21 +0100

> implemented as a requirement to implement DMARC.

That's the old spec.  The consensus of the working group is to remove the 
normative constraint about p= (ticket #49).  So now only v= is required.

> to other documents, which seems to me to be a pointless document to produce.

Operators who don't need policy, for example external report receivers who just 
want to publish verification records, would find the relevant info in the base 
spec.

A good point of Jim's proposal is that having policy in a separate spec, in the 
same manner as reports, avoids the unintended effect of classifying reports as 
a 2nd class, generally-not-used feature.

jm2p
Ale
--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 5 Nov 2020 09:43:44 -0800

On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely <[email-masked]> wrote:

> The consensus of the working group is to remove the

I must have completely misunderstood the discussion and will have to go
back and look up the thread. I thought that the discussion was strictly
about whether the "p=" phrase had to be the second phrase in the record.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Thu, 5 Nov 2020 09:45:25 -0800

> normative constraint about p= (ticket #49).  So now only v= is required.

As Chair, this is not the consensus of the group, nor what ticket #49 (
https://trac.ietf.org/trac/dmarc/ticket/49) says. What we removed was the
normative requirement that p= MUST be the second tag in the record. p= is
still REQUIRED.

To Todd's point, DMARC is a means of communicating policy between domain
owner and mail receiver regarding how to handle unauthenticated mail. DMARC
does not function without policy.

If someone believes policy can be spun out into a separate draft, please
upload your suggestion as an I-D and we will discuss it.

Seth

--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Nov 2020 11:55:20 -0800

On 11/5/2020 8:46 AM, Todd Herr wrote:
> Moving discussion of policy to a second specification would render any 
> base specification to be no more than effectively a table of contents 
> pointing to other documents, which seems to me to be a 
> pointless document to produce.

Separation has to have a compelling reason, mostly involving differences 
in anticipated revision patterns, or fundamental differences in the 
nature of their specifications.  That is, they should be separate 
because, in practical terms, they have to be, either now or later.  NOT 
making them separate will either now or later pose significant problems.

The rationale for the the current, proposed separations should be posted 
in a message with a specifically-titled Subject: line and solid 
explanations for the choices.

d/

ps. I think separating can be essential for some specifications.  The 
challenge is how and why; the answers need to be compelling.  A 
beginning point of consideration can be:

      Tussle in cyberspace: defining tomorrow's internet
      https://dl.acm.org/doi/10.1145/633025.633059

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 6 Nov 2020 12:44:56 +0100

> normative requirement that p= MUST be the second tag in the record. p= is

Oops, I must have been mistaken with ticket #72.  My apologies.

> does not function without policy.

It still has reporting, though...

> upload your suggestion as an I-D and we will discuss it.

An I-D?!  What kind of I-D?  Couldn't we discuss it informally, just to see 
what most people think?

Best
Ale
--

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 06 Nov 2020 11:57:47 +0000

> On Thu 05/Nov/2020 18:45:25 +0100 Seth Blank wrote:

 [snip]

> An I-D?!  What kind of I-D?  Couldn't we discuss it informally, just to see 

In order to be able to decide on this proposal, proposer(s) have to give enough details to enable other participants (including WG chairs) to decide whether such separation has benefits. At minimum this would require Table of Content and justification of benefits.

Best Regards,
Alexey

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 6 Nov 2020 07:27:30 -0500

I am just catching on to the implications of this discussion, and I must disagree

It makes no sense to allow "p=" missing.   Why would we suggest that all existing implementations alter their code to tolerate additional unnecessary complexity, rather than requiring domain administrators to key a few more characters so that code changes will not be necessary?

There is no functional difference between "p=" missing and "p=none".  Both configurations state: "I don't know what to tell you, you are on your own." 

I also don't understand this comment from Allesandro :

"Operators who don't need policy, for example external report receivers who just
want to publish verification records, would find the relevant info in the base
spec."

There is only one policy record, published by the domain owner.  The DNS record either suggests enforcement (p=quarantine, p=reject) or it does not (p=none, p=missing, no DMARC record).

Let's not add code complexity when it provides no benefit.

Doug Foster

---

From: Todd Herr <[email-masked]>
Date: Fri, 6 Nov 2020 08:57:46 -0500

On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> It makes no sense to allow "p=" missing.   Why would we suggest that all
> existing implementations alter their code to tolerate additional
> unnecessary complexity, rather than requiring domain administrators to key
> a few more characters so that code changes will not be necessary?
>
> There is no functional difference between "p=" missing and "p=none".  Both
> configurations state: "I don't know what to tell you, you are on your own."
>

I disagree with the assertion that p=none means "I don't know what to tell
you".

"p=none" is the starting point for all DMARC implementations in any
non-trivial environment. "p=none" allows the domain owner, through the
consumption of DMARC reports, to effectively audit their own understanding
of their mailstreams and authentication practices, and address any
shortcomings before eventually moving along, theoretically, to
"p=quarantine" or "p=reject".

> There is only one policy record, published by the domain owner.  The DNS
> record either suggests enforcement (p=quarantine, p=reject) or it does not
> (p=none, p=missing, no DMARC record).
>
>
I can't speak for him, but I believe he's referring to the records that a
report consumer outside the authority of the domain at issue might publish,
as documented currently in https://tools.ietf.org/html/rfc7489#section-7.1.
In those cases where, for example, foo.com publishes a DMARC policy record
with a rua= value of say "[email-masked]", there must exist a TXT record
of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that
bar.org is consenting to receive these reports.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 7 Nov 2020 10:11:16 +0100

On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote:
> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote:
> 

Are there really implementations that choke on missing p=?

How about "v=DMARC1; p=none; p=quarantine;"?

>> I also don't understand this comment from Alessandro :
>>
>>> "Operators who don't need policy, for example external report receivers 
>>> who just want to publish verification records, would find the relevant
>>> info in the base spec." >>

Exactly!  Dropping the requirement allows the definition of DMARC record to be 
unique.  Not a terrific gain, just a little simplification.

Best
Ale
--

---

From: Steven M Jones <[email-masked]>
Date: Sat, 7 Nov 2020 01:52:44 -0800

> How about "v=DMARC1; p=none; p=quarantine;"?

I'm pretty sure both cases would be invalid as DMARC policy records, in 
which case they should be ignored. If an implementation is trying to do 
something with invalid records like these, particularly one with 
multiple "p=" tags, then that would be a problem.

>>>> "Operators who don't need policy, for example external report 
>>>> receivers who just want to publish verification records, would find 
>>>> the relevant
>> as documented currently in 
>> https://tools.ietf.org/html/rfc7489#section-7.1.
> Exactly!  Dropping the requirement allows the definition of DMARC 
> record to be unique.  Not a terrific gain, just a little simplification.

I'm not aware of any requirement for third party report receivers to 
publish a DMARC policy record for their domain, in order to operate as 
report receivers. If that's what you meant, Ale, can you tell us where 
it appears in RFC7489 or the -bis spec?

--S.

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 7 Nov 2020 08:09:27 -0500

The report receiver verification step was referenced in the response.   This was the pointer:

It requires a DNS entry at: <sourcedoman>. _report._dmarc.<domainname>, type TXT, value "v=DMARC1"  (No other content is specified.)

Since the DNS location, the purpose of the entry, and the content are all different, I do not see that it has any bearing on the question of whether "p=" is required or not.

p=none probably means "I am trying to get my administrative controls in place, but I am not there yet", which still supports my earlier comment that "I don't know how to advise you on whether to accept or reject this message".

If p=missing means, "I am trying to get my administrative controls in place, but I am so chaotic that I cannot construct a compliant DMARC record", then I don't know why I should take the policy seriously.

If p=missing means "I am not trying to get any administrative controls in place, but I like to know whether my bot network is successful", then it is still not a DMARC record that I want to take seriously.

Overall, it is a small requirement to insist that the domain owner publish a compliant DMARC policy.

In addition, I propose making rua reporting mandatory.   A domain owner that does not want to learn about, and correct, his configuration errors cannot be a reliable source of policy information.   False positives will persist indefinitely, and therefore the policy record itself cannot be trusted.  Domain owners with persistent errors made SPF pretty much useless until DMARC came along.   I don't want to see it repeated.

Doug Foster

----------------------------------------

From: Steven M Jones <[email-masked]>
Sent: 11/7/20 4:54 AM
To: [email-masked]
Subject: Re: [dmarc-ietf] Optional p= makes no sense

--S.

---

From: Dotzero <[email-masked]>
Date: Sat, 7 Nov 2020 13:33:36 -0500

<SNIP>..

>
> p=none probably means "I am trying to get my administrative controls in
> place, but I am not there yet", which still supports my earlier comment
> that "I don't know how to advise you on whether to accept or reject this
> message".
>

p=none simply means "This domain is not asserting policy". Reading anything
more than that into it is pure speculation.

Michael Hammer

---

From: Steven M Jones <[email-masked]>
Date: Sat, 7 Nov 2020 12:16:46 -0800

On 11/7/20 5:09 AM, Douglas E. Foster wrote:
> It requires a DNS entry at: <sourcedoman>. 
> _report._dmarc.<domainname>, type TXT, value "v=DMARC1"  (No other 
> content is specified.)

Thank you Doug, I'm familiar with section 7.1.

I think the question of whether the "p=" tag is optional has been 
adequately addressed.

I'll respond to the other topic in this thread separately, with a 
subject line that reflects the topic.

--S.

---

From: Steven M Jones <[email-masked]>
Date: Sat, 7 Nov 2020 12:19:45 -0800

I wanted to bring this topic into a visibly different thread, as it's 
really about further splitting up of the base DMARC document.

In digging through recent messages, I think I see what Ale meant. The 
topic was Jim Fenton's suggestion of splitting the policy section out 
into a separate document. This would be the relevant reference from 
Ale's message on Nov 5th, subject "Announcing DMARCbis Editors" - Ale is 
responding to Todd Herr in this snippet:

> Operators who don't need policy, for example external report receivers 
> info in the base spec.
> A good point of Jim's proposal is that having policy in a separate 
> spec, in the same manner as reports, avoids the unintended effect of 
> classifying reports as a 2nd class, generally-not-used feature.

Alessandro: Correct me if I'm wrong, but it seems from this quotation 
that you were just constructing a case were a valid DMARC role (third 
party report receiver) would need to use the "base" spec (without policy 
content), and the reporting specs, without direct need for a 
separate/split-out "policy" spec.

While you have a point, I would think that any report receiver would 
need to reference that policy spec as soon as they receive a report and 
need to interpret it. In which case, I would need a more compelling 
reason or benefit to split the policy section out into a separate document.

With regard to the "Optional p= makes no sense" thread, I think the 
quotation with too-little context gave the impression of a different or 
larger issue.

--Steve.

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 07 Nov 2020 16:50:32 -0800

> does not function without policy.

If that last sentence is the consensus of the working group (and I see 
that the charter could be interpreted that policy is required), then 
fine. But I consider the reporting aspect to be useful even in the 
absence of policy assertion or enforcement, allow a domain owner to 
obtain information about recipients’ receipt of unauthenticated email 
from that domain. I realize that RFC 7489 treats policy as the primary 
function and reporting as secondary, but this WG is about improving that 
specification, and I consider this to be an improvement.

> upload your suggestion as an I-D and we will discuss it.

That’s quite a bit of work for something that might very well be dead 
on arrival. I have outlined the portions of the specification that would 
go in the base specification and the portions that go into the policy 
document, and that should be sufficient to make this decision.

To Todd’s earlier comment, the base specification would be much more 
than a “table of contents” because that is where the format of DMARC 
records, the discovery mechanisms, and the like would be specified. 
However, the base specification would not stand alone; it would require 
the policy specification or one or both of the reporting specifications 
to do anything useful.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sat, 7 Nov 2020 17:00:45 -0800

> specification, and I consider this to be an improvement.

DMARC can do 3 things:

    1. Define alignment and how to effect it

    2. Request receive-side disposition of non-aligned mail

    3. Request reporting.

DMARC does not have to do 2 or 3.  It can refrain from making a handling 
request and it can refrain from requesting reporting.

A claim that DMARC isn't DMARC unless there is policy seems an odd view, 
given p=none.

d/

---

From: Steven M Jones <[email-masked]>
Date: Sat, 7 Nov 2020 20:12:35 -0800

On 11/7/20 4:50 PM, Jim Fenton wrote:
>> [...]
> [...] But I consider the reporting aspect to be useful even in the 
> function and reporting as secondary, but this WG is about improving 
> that specification, and I consider this to be an improvement.

I agree there is a great deal of value in reporting without 
"enforcement" -- that's why the policy option of "p=none" exists. 
Perhaps the use of the string "none," meaning "no change in handling," 
is too readily confused with "none" meaning "no policy?" Which is indeed 
an odd duck, a policy saying there is no policy...

Is there a problem with using the "p=" tag to signal the desire for 
reports without requesting a change in the processing of messages that 
don't get a DMARC "pass?"

> [ Quoting Seth again: ]
> on arrival. I have outlined the portions of the specification that 
> would go in the base specification and the portions that go into the 
> policy document, and that should be sufficient to make this decision.

Okay, but what is the expected payoff from splitting it out? Does it 
make it easier to process and approve updates of the policy content 
separately from, say, the description of record discovery or Alignment 
concepts? Easier to pass muster for Standards Track? Are implementers 
currently confused and dissuaded by having policy details mixed with the 
other content?

If the benefits seem worthwhile, I could get behind the split - but 
there ought to be a clear benefit.

--S.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 7 Nov 2020 20:20:10 -0800

On 11/7/2020 8:12 PM, Steven M Jones wrote:
> that's why the policy option of "p=none" exists. Perhaps the use of the 
> string "none," meaning "no change in handling," is too readily confused 
> with "none" meaning "no policy?" Which is indeed an odd duck, a policy 
> saying there is no policy...

Although the DMARC spec defines p=none as:

>       none:  The Domain Owner requests no specific action be taken
>          regarding delivery of messages.

This is rather tortured language that invites confusion.  Forgive me, 
but "requests no specific action" is a request that isn't a request.  It 
has no real meaning.

What is actually intended is:

       "The Domain Owner is expressing no policy for action to be taken
        regarding delivery of the message."

d/

---

From: Steven M Jones <[email-masked]>
Date: Sat, 7 Nov 2020 20:27:05 -0800

On 11/7/20 5:00 PM, Dave Crocker wrote:
>> If that last sentence is the consensus of the working group (and I 
>> see that the charter could be interpreted that policy is required), 
>> then fine. But I consider the reporting aspect to be useful even in 
>> the absence of policy assertion or enforcement, allow a domain owner 
>> to obtain information about recipients’ receipt of unauthenticated 
>> email from that domain.
>
>
> DMARC can do 3 things:
>
> DMARC does not have to do 2 or 3.  It can refrain from making a 
> handling request and it can refrain from requesting reporting.
>
> A claim that DMARC isn't DMARC unless there is policy seems an odd 
> view, given p=none.

"p=none" is the defined _policy_ to get 1 and 3 without 2. That's how 
you set a _policy_ that allows you to request reporting without enforcement.

"p=none" allows Jim's desired use case to have reporting without a 
change in handling. Since it _is_ a policy, what Seth wrote ("DMARC does 
not function without policy.") is not in conflict with that use case.

Maybe changing that option to "none" from "monitoring" wasn't actually 
the best choice? But I'm not sure it would be wise to change it now, in 
light of the installed base...

--S.

---

From: Steven M Jones <[email-masked]>
Date: Sat, 7 Nov 2020 20:32:44 -0800

On 11/7/20 8:20 PM, Dave Crocker wrote:
>> that's why the policy option of "p=none" exists. Perhaps the use of 
>> the string "none," meaning "no change in handling," is too readily 
>> confused with "none" meaning "no policy?" Which is indeed an odd 
>> duck, a policy saying there is no policy...
>
>
> but "requests no specific action" is a request that isn't a request.  
> It has no real meaning.
>

Fair point, the language could be improved - and by a lovely 
coincidence, I understand there's a group tasked with revising the spec. ;^)

Though I'm not convinced that it seems confusing when you read it in the 
context of the "quarantine" and "reject" options right below it...

--S.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 9 Nov 2020 13:15:02 +0100

On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote:
> I'm pretty sure both cases would be invalid as DMARC policy records, in which 
> case they should be ignored.

I don't think so.  The current draft says:

    6.  If a retrieved policy record does not contain a valid "p" tag, or
        contains an "sp" tag that is not valid, then:

        1.  if a "rua" tag is present and contains at least one
            syntactically valid reporting URI, the Mail Receiver SHOULD
            act as if a record containing a valid "v" tag and "p=none"
            was retrieved, and continue processing;

> If an implementation is trying to do something with invalid records like
> these, particularly one with multiple "p=" tags, then that would be a
> problem.

Invalid or repeated p= tags are a problem, but possibly they don't completely 
disqualify a record.  So the question becomes "How does a missing p= tag differ 
from an invalid one?"

This is a marginal question, to define the syntax of a DMARC record as simply 
as possible (but not simpler).  I added a comment to ticket #7[*] with a 
proposed syntax.  IMHO the spec should just mention undefined behavior or some 
such, without trying to impose overly strict commitments —given that parsers 
have to deal with the possibility of non-conforming records anyway.

This question is not related with splitting policy into its own document.

Best
Ale
-- 

[*] https://trac.ietf.org/trac/dmarc/ticket/7#comment:4

---

From: "Doug Foster" <[email-masked]>
Date: Mon, 9 Nov 2020 08:51:41 -0500

I would be content with language that says:

If an evaluator detects a DMARC record without a policy tag, it MAY reject the record as invalid or it MAY treat the record as equivalent to p=none. 
Consequently, domain owners SHOULD include a p= tag, as the recipient action is otherwise unpredictable..

DF

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Alessandro Vesely
Sent: Monday, November 09, 2020 7:15 AM
To: [email-masked]
Subject: Re: [dmarc-ietf] Optional p= makes no sense

On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote:
>>>> It makes no sense to allow "p=" missing.   Why would we suggest 
>>>> that all existing implementations alter their code to tolerate 
>>>> additional unnecessary complexity, rather than requiring domain 
>>>> administrators to key a few more characters so that code changes will not be necessary?
>>
>>
> I'm pretty sure both cases would be invalid as DMARC policy records, 
> in which case they should be ignored.

> If an implementation is trying to do something with invalid records 
> like these, particularly one with multiple "p=" tags, then that would 
> be a problem.

Invalid or repeated p= tags are a problem, but possibly they don't completely disqualify a record.  So the question becomes "How does a missing p= tag differ from an invalid one?"

This is a marginal question, to define the syntax of a DMARC record as simply as possible (but not simpler).  I added a comment to ticket #7[*] with a proposed syntax.  IMHO the spec should just mention undefined behavior or some such, without trying to impose overly strict commitments —given that parsers have to deal with the possibility of non-conforming records anyway.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 9 Nov 2020 06:05:15 -0800

On 11/9/2020 4:15 AM, Alessandro Vesely wrote:
> Invalid or repeated p= tags are a problem, but possibly they don't 
> completely disqualify a record.

The concept of 'partial' disqualification points to the problem of 
trying to be subtle in specifications.

A specification should provide and demand simple details and simple 
handling of problems.

If a domain owner cannot produce a DMARC record that is correct, then it 
is far too likely they don't know enough to participate in DMARC.

Here, the simple rule should be:

      An invalid DMARC record MUST be treated as if no DMARC record is 
present.

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 9 Nov 2020 11:06:02 -0500

> A specification should provide and demand simple details and simple

This!

> is far too likely they don't know enough to participate in DMARC.

+1

>       An invalid DMARC record MUST be treated as if no DMARC record is

+100

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 9 Nov 2020 18:07:41 +0100

>> is far too likely they don't know enough to participate in DMARC.

Agreed.  Possibly, bad DMARC records can be reported to the human point of 
contact disclosed in aggregate reports, for domains which generate them.

>>       An invalid DMARC record MUST be treated as if no DMARC record is

+1e2 for me too, even if it disparages bullet 6 of Section 6.6.3.
(Aren't we inflating consensus a little bit this way?)

Yet, it is going to require more wording to make p= mandatory (while sp= is 
optional) except for external destination verification records where p= is not 
required, than to make all tags optional except v=, at least syntactically.

Best
Ale
--

---

From: Steven M Jones <[email-masked]>
Date: Mon, 9 Nov 2020 12:02:00 -0800

> I don't think so.  The current draft says:

Oops - thank you for the gentle correction about absent "p=" tags in 
policy records, Ale.

> A specification should provide and demand simple details and simple 

At least "clear and unambiguous" if we can't quite reach "simple."

+1

--S.

---

From: "Jim Fenton" <[email-masked]>
Date: Mon, 09 Nov 2020 15:04:39 -0800

On 7 Nov 2020, at 20:12, Steven M Jones wrote:

> currently confused and dissuaded by having policy details mixed with 
> the other content?
>

The benefit I have in mind is that reporting does not cause issues with 
indirect mail flows (the addressing of which is item 1 on the WG 
charter), so it can proceed even while there isn’t WG consensus on how 
to solve that problem for the policy piece. Or in the extreme case, it 
can proceed even if IESG considers the policy piece to not have an 
acceptable solution.

Of course, if the solution to the policy piece is likely to affect the 
discovery/binding of the policy and reporting, which would be in the 
base document, this argument doesn’t hold.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Nov 2020 16:57:01 -0500

On 11/9/2020 6:04 PM, Jim Fenton wrote:

>> separately from, say, the description of record discovery or
>> Alignment concepts? Easier to pass muster for Standards Track? Are
>> implementers currently confused and dissuaded by having policy
>> details mixed with the other content?
>>
> The benefit I have in mind is that reporting does not cause issues
> with indirect mail flows (the addressing of which is item 1 on the WG

My view.

I was the 2nd on Jim's proposal to split DMARC.  I presumed the obvious:

- DMARC-BASE
- DMARC-REPORTS  (optional reporting features. Not required)

DMARC-BASE is the base policy protocol based on the DKIM-POLICY model 
as was DKIM-SSP and DKIM-ADSP.  All these proposals used the required 
DKIM 5322.From domain identity binding as input for a DKIM Policy 
model.The DKIM Signer Domain identity is input for an Reputation 
lookup that never materialized. DKIM-VBR is the closes thing we have 
to a IETF proposed reputation lookup for DKIM.  DKIM-VBR does the 
Author and Signer as input.

I favored the split for the same reasons DKIM was split into two WG PS 
work items:

- DKIM-BASE   was the base signing/verification protocol,
- DKIM-POLICY where DKIM-SSP was the draft proposal on the table.

The split allowed DKIM-BASE to be completed and now we have a DKIM STD 
document.

Fenton was the editor of DKIM-SSP. It evolved to DKIM-ADSP which was 
abandoned and the DKIM WG ended.  It was replaced with DKIM-DMARC as 
an Informational Status document.

Keep in mind that DKIM-SSP covered 3rd party policies with an "o=" tag:

SSP Draft:

    o=~  NEUTRAL (signature optional [No 3rd party?])
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

WG Suggestions:

    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)

Due to the ambiguity of the 3rd party policies and the lack of a 3rd 
party authorization protocol, Levine rewrote DKIM-SSP draft 3 titled 
DKIM-ASP and by draft 10, it became DKIM-ADSP.

ADSP stripped the 3rd party semantics and pretty much left an 
EXCLUSIVE policy with ADSP DISCARDABLE policy.

DMARC also offered a similar exclusive signing policy and also 
reported as well.

Fast forward to today.  I believe the charter is touching based with 
the 3rd party resigners design issues. So we are back to a situation 
where we may have three documents:

- DMARC-BASE      base protocol for current strong 1st party policy,
- DMARC-REPORTS   optional reporting
- DMARC-TPA       Third party Authorization proposals.

The DMARC-TPA should cover ATPS, ARC and hopefully conditional 
signatures. However, based on the charter, it outlined specifically:

This work item was lumped into DMARC-BASE.

My position is this:

I believe ARC or "something that deals with indirect mailflows" that 
is not well defined or has not gained traction as a TPA solution, 
should not be included in DMARC-BASE.

DMARC-BASE should be independent of any other add-on but it should 
allowed for Tag Extensions to support TPA concepts included ARC, ATPS 
and conditional signatures.

In my opinion, this is a best way to get DMARC-BASE fast tracked to 
standardization. DMARC-TPA or DKIM-TPA can be a separate doc that 
specifies add-on DMARC augmentations which are designed to help 
address the long time 3rd party resigned and authorization issue.

While I personally, and I believe ideally, prefer ATPS be included in 
the DMARC-BASE protocol, due to the lack of WG support, I rather get 
the DKIM-BASE 1st party semantics completed first.

Thanks

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Nov 2020 16:53:57 -0800

Merely as a participant: +1 to Dave's reply to this.

On one particular point:

On Mon, Nov 9, 2020 at 5:51 AM Doug Foster <fosterd=
[email-masked]> wrote:

> If an evaluator detects a DMARC record without a policy tag, it MAY reject
> the record as invalid or it MAY treat the record as equivalent to p=none.

<ad>
When it comes to requirements language in standards track documents, and
particularly with respect to SHOULD, be prepared to answer this question:
Under what circumstances might an implementer deviate from the
recommendation presented by the SHOULD?  If the text doesn't make that
clear already, you can expect I'll ask that question when it comes up for
AD Evaluation.

If there's no solid answer to that, then you might consider MAY or MUST, or
omit the requirements language entirely.

In this case, why might an operator consciously omit "p=", and to what
end?  If there's no good answer to that, I'd consider making "p=" mandatory.
</ad>

-MSK

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2020 21:12:44 -0500

>end?  If there's no good answer to that, I'd consider making "p=" mandatory.

Make it mandatory. If you can publish a DMARC record at all, you can
put a p= tag in it.

I agree we should remove the rule about what order the tags appear.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly