Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread Seth Blank
On Wed, Jan 3, 2018 at 3:28 PM, Kurt Andersen (b) wrote: > > Very helpful - thanks. I think that expressing it in the positive > "oldest-pass" form makes the point much clearer. Unless there is an outcry > from the rest of the group, I'd like to change to this terminology. > No

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread Kurt Andersen (b)
On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana wrote: > I assume this was the one that you wanted my clarification on? > Yes, thanks > But let's rewrite it as oldest-pass, because that's clearer. Your case: > > * ARC 1: cv=none, ams.oldest-pass=0 > * ARC 2: cv=pass,

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread Bron Gondwana
On Thu, 4 Jan 2018, at 09:50, Kurt Andersen (b) wrote: > While I wait for Bron's confirmation that my understanding matches his > (see email from yesterday), I'll go check on that... > on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank wrote:>> >> . . .text for . . .

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread Seth Blank
On Wed, Jan 3, 2018 at 14:50 Kurt Andersen (b) wrote: > I'm uncomfortable with the terminology implied by the term > "arc.closest-fail". I think that it is more "ams.closest-fail" or > "arc.ams-broken". AMS is expected to not verify except in the most recent > ARC set. Doing so

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread Kurt Andersen (b)
While I wait for Bron's confirmation that my understanding matches his (see email from yesterday), on Wed, Jan 3, 2018 at 8:57 PM, Seth Blank < s...@sethblank.com> wrote: > > . . .text for . . . arc.closest-fail . . . > I'm uncomfortable with the terminology implied by the term

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread Seth Blank
On Wed, Jan 3, 2018 at 12:48 PM, John Levine wrote: > > Seems to me this makes some assumptions about the way ARC consumers > will use ARC chains to decide whether to ignore a DMARC failure. > Personally, I think the most likely scenario is that they'll look at > all of the

Re: [dmarc-ietf] Clarifying the value of arc.closest-fail

2018-01-03 Thread John Levine
In article <1514939995.3318165.1222346488.5b169...@webmail.messagingengine.com> you write: >Please read my examples again if the problem wasn't clear, because you >don't get security by imagining the best cases where everyone behaves >themselves, you get security by imagining that everybody is

Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

2018-01-03 Thread Dave Crocker
While John Levine cited the benefits of the "experimental" approach taken for EAI (https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw), I'm also biased by the "let's all just play nice" mess that came from designating incompatible "versions" of SPF as competing

Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

2018-01-03 Thread Kurt Andersen (b)
On Wed, Jan 3, 2018 at 8:04 AM, Seth Blank wrote: > > . . .for me "experimental" comes from the fact that there are several open > issues on which there has been lasting discussion within this group with no > resolution that data from an experiment will quickly shine light

Re: [dmarc-ietf] ARC draft questions (speak up!): Experimental Status and Considerations

2018-01-03 Thread Seth Blank
On Tue, Jan 2, 2018 at 11:05 PM, Murray S. Kucherawy wrote: > > 2) The advice that all handlers need to apply a seal to the message, to > which Bron previously and rather strenuously voiced opposition. I believe > the decision was to defer on that issue until we've run some