Re: [dmarc-ietf] Announcing DMARCbis Editors

2020-11-07 Thread Steven M Jones
On 11/7/20 8:20 PM, Dave Crocker wrote: 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 po

Re: [dmarc-ietf] Announcing DMARCbis Editors

2020-11-07 Thread Steven M Jones
On 11/7/20 5:00 PM, Dave Crocker wrote: On 11/7/2020 4:50 PM, Jim Fenton 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 absenc

Re: [dmarc-ietf] Announcing DMARCbis Editors

2020-11-07 Thread Dave Crocker
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... Alth

Re: [dmarc-ietf] Announcing DMARCbis Editors

2020-11-07 Thread Steven M Jones
On 11/7/20 4:50 PM, Jim Fenton wrote: On 5 Nov 2020, at 9:45, Seth Blank wrote: [...] 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. [...] But I consider t

Re: [dmarc-ietf] Announcing DMARCbis Editors

2020-11-07 Thread Dave Crocker
On 11/7/2020 4:50 PM, Jim Fenton 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, allo

Re: [dmarc-ietf] Announcing DMARCbis Editors

2020-11-07 Thread Jim Fenton
On 5 Nov 2020, at 9:45, Seth Blank wrote: On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote: 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. As Chair, this is not the consensus of the

[dmarc-ietf] Separate policy spec, was Re: Optional p= makes no sense

2020-11-07 Thread Steven M Jones
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 docum

Re: [dmarc-ietf] Optional p= makes no sense

2020-11-07 Thread Steven M Jones
On 11/7/20 5:09 AM, Douglas E. Foster wrote: The report receiver verification step was referenced in the response.   This was the pointer: https://tools.ietf.org/html/rfc7489#section-7.1. It requires a DNS entry at: . _report._dmarc., type TXT, value "v=DMARC1"  (No other content is specifie

Re: [dmarc-ietf] Optional p= makes no sense

2020-11-07 Thread Douglas E. Foster
Exactly. I was speculating.  What reasons could possibly exist for a domain to be given another method for not saying anythng?  You make my point - there are no valid reasons to do so.Sent from my Verizon, Samsung Galaxy smartphone Original message From: Dotzero Date: 11/7/20

Re: [dmarc-ietf] Optional p= makes no sense

2020-11-07 Thread Dotzero
.. > > 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 polic

Re: [dmarc-ietf] Optional p= makes no sense

2020-11-07 Thread Douglas E. Foster
The report receiver verification step was referenced in the response. This was the pointer: https://tools.ietf.org/html/rfc7489#section-7.1. It requires a DNS entry at: . _report._dmarc., type TXT, value "v=DMARC1" (No other content is specified.) Since the DNS location, the purpose of the

Re: [dmarc-ietf] Optional p= makes no sense

2020-11-07 Thread Steven M Jones
On 11/7/20 1:11 AM, Alessandro Vesely wrote: 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: It makes no sense to allow "p=" missing.   Why would we suggest that all existing implementations alter their code to tolerate additional unn

Re: [dmarc-ietf] Optional p= makes no sense

2020-11-07 Thread Alessandro Vesely
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: 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 doma