Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 10/14/2015 5:04 PM, ned+dm...@mrochek.com wrote: If the installed base can legally ignore a new feature, then it is not mandatory. The nature of DKIM is such that many signatures end up getting ignored as part of normal operation. That doesn't make any aspect of the various mandatory aspect

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

Responding to this late, but I think there are some important points not previously covered. > On 10/3/2015 10:08 AM, John R Levine wrote: > > I suppose the version bump to v=2 is an open issue, but I don't really > > see what the problem is. Since the current spec says that unknown tags > > are

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

tf.org] On Behalf Of John R Levine Sent: Sunday, October 4, 2015 8:35 AM To: Murray S. Kucherawy Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-02 > As John pointed out, RFC6376 requires that the signature not pass for any > "v=" value other than 1. I

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

As John pointed out, RFC6376 requires that the signature not pass for any "v=" value other than 1. It won't even get as far as considering the "!" tags. He said "most" implementations he checked will conform to that. I thought it was "all"; perhaps he'd care to elaborate. All the ones that an

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On Sat, Oct 3, 2015 at 6:59 PM, Dave Crocker wrote: > Yeah, and what's interesting about that is that the spec does not > explicitly specify that signatures without a v=1 need to be failed. > I believe Section 6.1.1, first paragraph, has that covered. -MSK __

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 10/3/2015 6:35 PM, John Levine wrote: > People have looked at the code in most existing DKIM verifiers to see > whether the code matches the spec, and the current code does indeed > reject signatures that don't start with v=1. Yeah, and what's interesting about that is that the spec does not e

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

>I had not noticed -- and still don't quite understand -- what it is >about the new stuff that will cause a legacy engine to fail the >signature validation. It's in section 3.5 of RFC 6376, the part about the DKIM-Signature header, where it says: v= Version (plain-text; REQUIRED). This tag de

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 10/3/2015 5:23 PM, Murray S. Kucherawy wrote: > On Sat, Oct 3, 2015 at 4:49 PM, Dave Crocker > wrote: > > Claiming that something is mandatory, as part of a version bump, is > meaningless, when the installed base will be using the older version and > ignor

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 10/3/2015 5:07 PM, John R Levine wrote: >> Things get easier if you make the new feature optional, in which case >> you don't need a version number... > > If you can figure out how to make signature conditional on another with > without a version bump, that would be swell. 1. I wasn't recomm

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

Things get easier if you make the new feature optional, in which case you don't need a version number... If you can figure out how to make signature conditional on another with without a version bump, that would be swell. I've been thinking about it for over a year and so far this trick elude

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 10/3/2015 10:08 AM, John R Levine wrote: > I suppose the version bump to v=2 is an open issue, but I don't really > see what the problem is. Since the current spec says that unknown tags > are ignored, there's no way to add mandatory tags without a version > bump. I believe when this came up b

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On Sat, Oct 3, 2015 at 3:21 PM, John R Levine wrote: I think at least the latter is a minor point since the XML source for >> RFC6376 is readily available. I'm happy to pick up the editor pen again >> if >> needed. >> > > My concern is that once the can is opened, it's hard to keep some of the >

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

I think at least the latter is a minor point since the XML source for RFC6376 is readily available. I'm happy to pick up the editor pen again if needed. My concern is that once the can is opened, it's hard to keep some of the worms from escaping. There was a further rather theological argum

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

I think "!cd" is the only thing I changed. Here's my old comment about it with some open issues mentioned, like "v=2" to which Dave objected: https://mailarchive.ietf.org/arch/msg/dmarc/WQNRhqdUjM5Kut0BWzENx8aJSO8 I suppose the version bump to v=2 is an open issue, but I don't really see what

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

I made a post some time back about changes I made in my implementation versus the spec. I'll dig that up too. For one thing, I apparently decided I didn't like the term "forward signature" and preferred "conditional domain", so the new tag is "!cd". We can argue about that and the other stuff w

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

This has been implemented in an experimental branch of OpenDKIM, since about May. I haven't released it yet, but it's probably time to do that. I made a post some time back about changes I made in my implementation versus the spec. I'll dig that up too. For one thing, I apparently decided I did

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

>> Quite correct. I would expect conditional signatures to be applied by >> large mail systems, using their private list of domains that look like >> mailing lists to decide who gets them. > >How much of a barrier to entry to new or small mailing list providers >(or new domains being used there) d

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

Steve Atkins writes: > How much of a barrier to entry to new or small mailing list providers > (or new domains being used there) does this cause? That depends on how badly a missing conditional signature "deprecates" a list. There are three ways deprecation can happen: 1. By reducing the ris

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

> On Sep 30, 2015, at 5:39 PM, John Levine wrote: > >>> The local signer here must know this message goes to dmarc@ietf.org >>> an add a signature including "!fs=ietg.org" >> >> An average email author cannot be relied on to cause this setting to be >> made. > > Quite correct. I would expect

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

I would expect conditional signatures to be applied by large mail systems, using their private list of domains that look like mailing lists to decide who gets them. From the past couple of years of discussion, it is clear that all of the large mail systems already have such a list of domains, s

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 9/30/2015 5:39 PM, John Levine wrote: > I would expect conditional signatures to be applied by > large mail systems, using their private list of domains that look like > mailing lists to decide who gets them. > >>From the past couple of years of discussion, it is clear that all of > the large m

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

>> The local signer here must know this message goes to dmarc@ietf.org >> an add a signature including "!fs=ietg.org" > >An average email author cannot be relied on to cause this setting to be >made. Quite correct. I would expect conditional signatures to be applied by large mail systems, using t

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 9/29/2015 1:08 PM, John Levine wrote: > I refreshed this draft so it wouldn't expire. Not very different, > mostly changed the @fs= to !fs= per Murray's suggestion. > > I still think this is the least broken way I've seen to let > mailing lists coexist with DMARC. I am going to look at ad

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

> The local signer here must know this message goes to dmarc@ietf.org > an add a signature including "!fs=ietg.org" An average email author cannot be relied on to cause this setting to be made. There are multiple levels of knowledge and action this this setting requires and average end-users ca

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

John Levine: I still think this is the least broken way I've seen to let mailing lists coexist with DMARC. reads like a good idea. The local signer here must know this message goes to dmarc@ietf.org an add a signature including "!fs=ietg.org" So opendkim in my case has to be extended to look

Re: [dmarc-ietf] draft-levine-dkim-conditional-02

On 9/29/2015 1:08 PM, John Levine wrote: I refreshed this draft so it wouldn't expire. Not very different, mostly changed the @fs= to !fs= per Murray's suggestion. I still think this is the least broken way I've seen to let mailing lists coexist with DMARC. I am going to look at adding suppo

[dmarc-ietf] draft-levine-dkim-conditional-02

I refreshed this draft so it wouldn't expire. Not very different, mostly changed the @fs= to !fs= per Murray's suggestion. I still think this is the least broken way I've seen to let mailing lists coexist with DMARC. R's, John ___ dmarc mailing list d