Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

They seek to distinguish important differences in processing for what is claimed to be the /same/ protocol. Except really they don't. Except when they do. I'm thinking, f'rinstance, that there is a bunch of code in things like Spamassassin that looks at headers and switches out to routines

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

The ones I wrote certainly didn't require v=1 to come first. ;-) But you're right: there's probably cause to be concerned. Tony On 2/8/18, 10:08 AM, "ietf-dkim on behalf of John R. Levine" wrote: > "v=1" doesn't have to

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/2018 9:09 AM, John R. Levine wrote: They seek to distinguish important differences in processing for what is claimed to be the /same/ protocol. Except really they don't. Except when they do.  I'm thinking, f'rinstance, that there is a bunch of code in things like Spamassassin that

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/2018 9:45 AM, John R. Levine wrote: Huh?  v=1 code doesn't know what the new features would be. Re-read what I wrote. The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. d/ -- Dave Crocker Brandenburg InternetWorking

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

Dave, Our respective ages are getting up there and my senility is setting in in earnest, so I have some sympathy along these lines, but given that you are the author of RFC 5234, you might want to check section 2.3 of that document: ABNF permits the specification of literal text strings

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

True, but not very interesting.  In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a dkim-signature header and sends it to the DKIM library. Oh.  So v= doesn't dispatch to different code. BTW, this topic tends to eventually produce a claim that

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

On 2/8/2018 8:17 AM, Mark Delany wrote: "v=1" doesn't have to come first. It just usually does. I think there was a version of RFC4871 that did that, but then when challenged we couldn't come up with a good reason to keep it that way. Heh. I'm still waiting to hear a good reason as to why

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

While possibly a nice addition to the specification, including this ABNF rule does not correct an error in RFC 6376. As for header-field name case sensitivity, that is the purview of RFC 5322, not RFC 6376. (FWIW, it does appear that there is an error in RFC 5322, since it does not enforce

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

> "v=1" doesn't have to come first. It just usually does. I think there was > a version of RFC4871 that did that, but then when challenged we couldn't > come up with a good reason to keep it that way. Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/2018 10:03 AM, John R. Levine wrote: The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. True, but not very interesting.  In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

On 2/8/2018 8:05 AM, John R. Levine wrote: I'm not saying any sensible person would do that, but as far as I can tell, that's what the spec says. From a quick review of RFC 5322, I think you are correct. I also believe (know) that this is not what has been intended for header field name

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

Header field name rules are in RFC 5322. That deals with case sensitivity for field name strings. Section 1.2.2 provides the basis for knowing whether a defined string is to be parsed in a case sensitive or insensitive manner. That's right, and all of the fields defined in 5322 have case

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On Thu, 8 Feb 2018, Mark Delany wrote: Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. I had a draft that invented v=2, for headers with a tag syntax that is not quite

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/2018 8:52 AM, John R. Levine wrote: On Thu, 8 Feb 2018, Mark Delany wrote: Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. I had a draft that invented v=2, for

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

the DKIM library.  If it passes a v=2 signature to a library that only knows about v=1, the library will say it's invalid, which isn't ideal but isn't wrong. the code that tests for the v= parameter could, just as easily, check for the presence of the new features. Huh? v=1 code doesn't

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

On 2/8/2018 10:05 AM, Pete Resnick wrote: RFC 7405 is also useful along these lines. If those modifications are used, sure. If not, not so much. So, no error in 5322. As for the erratum below, not having ABNF for the header field does seem like a miss, though I'm not sure it should be

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

On 2/8/2018 11:24 AM, Barry Leiba wrote: I believe the right solution to this, consistent with the intent of how email header fields work, is to add a sentence (via errata) to RFC 5322 section 2.2 or section 3.6 -- or both -- somewhat like this: OLD Header fields are lines beginning with a

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

NEW Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon.

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

> True, but not very interesting. In my spamassassin example, the outside > code knows nothing about DKIM versions, it just sees a dkim-signature > header and sends it to the DKIM library. > > The point of a v=2 flag is to ensure that old v=1 code doesn't As a practical matter haven't you

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

I believe the right solution to this, consistent with the intent of how email header fields work, is to add a sentence (via errata) to RFC 5322 section 2.2 or section 3.6 -- or both -- somewhat like this: OLD Header fields are lines beginning with a field name, followed by a colon (":"),

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

On Thu 08/Feb/2018 19:23:09 +0100 Dave Crocker wrote: > On 2/8/2018 10:05 AM, Pete Resnick wrote: >> >> RFC 7405 is also useful along these lines. > > If those modifications are used, sure.  If not, not so much. > > >> So, no error in 5322. As for the erratum below, not having ABNF for the >>

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

On 8 Feb 2018, at 10:23, Dave Crocker wrote: On 2/8/2018 10:05 AM, Pete Resnick wrote: So, no error in 5322. As for the erratum below, not having ABNF for the header field does seem like a miss, though I'm not sure it should be marked as more than "Hold for document update". Consider: 1.

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

> The question arose because someone had DKIM-Signature changed to > Dkim-Signature > by some (presumably DKIM-unaware) tool. The user thought the culprit was my > signing filter, and reported a bug. I told him to look somewhere else. I > wanted to add that that change can be acceptable if

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

In article <20180208203207.26575.qm...@f3-external.bushwire.net> you write: >After all, what are most senders going to do? They will not want their >signatures to be suddenly unrecognized by 99% of the planet so they'll continue >to generate a v=1 header and they will also want to reap the bennies

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/18 12:32 PM, Mark Delany wrote: I think this is the biggest flaw with the whole v= rationale. There is never going to be a v=2 change that doesn't leave everyone continuing to generate/validate a v=1 header. Is a new header by stealth better engineering than formalizing a new header? I

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/2018 4:42 PM, Michael Thomas wrote: Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. The pandora's box is creating an incompatible new version. All the rest is just engineering and operations tradeoffs. d/ -- Dave Crocker Brandenburg

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/18 4:45 PM, Dave Crocker wrote: On 2/8/2018 4:42 PM, Michael Thomas wrote: Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. The pandora's box is creating an incompatible new version.  All the rest is just engineering and operations tradeoffs.

[ietf-dkim] Where is the formal definition of DKIM-Signature?

Hi, someone asked me about case sensitiveness of the header field name. I looked for an ABNF in RFC6376, but only found examples and informative notes. Is that an error worth being reported? Ale ___ NOTE WELL: This list operates according to

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 08Feb18, John R. Levine allegedly wrote: > On Thu, 8 Feb 2018, Mark Delany wrote: > > Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - > > apart > > from exposing brittle parsers which mistakenly expect it to show up as the > > first > > tag. > > I had a draft that

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. True, but not very interesting. In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a dkim-signature header and sends it to the DKIM

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

someone asked me about case sensitiveness of the header field name. I looked for an ABNF in RFC6376, but only found examples and informative notes. I was going to say that can't possibly be true, but it's true, there's no ABNF for the header. So, for example, I don't know whether the v=

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

On Thu, Feb 8, 2018 at 5:22 AM, John R. Levine wrote: > someone asked me about case sensitiveness of the header field name. I >> looked >> for an ABNF in RFC6376, but only found examples and informative notes. >> > > I was going to say that can't possibly be true, but it's true,

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

"v=1" doesn't have to come first. It just usually does. I think there was a version of RFC4871 that did that, but then when challenged we couldn't come up with a good reason to keep it that way. I wonder how many DKIM libraries will accept a signature where it doesn't. Regards, John Levine,

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

On 2/8/2018 5:22 AM, John R. Levine wrote: someone asked me about case sensitiveness of the header field name.  I looked for an ABNF in RFC6376, but only found examples and informative notes. Header field name rules are in RFC 5322. That deals with case sensitivity for field name strings.