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 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. There appears to be a genetically-encoded belief in the value of version numbers, independent of the logic against it. The belief is pervasive and seems to cross all technical cultures, experiential sets, and protocol layers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 exposing brittle parsers which mistakenly expect it to show up as the first tag. It's about as likely to change as "MIME-Version: 1.0", which is to say, never. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 specification, dating back to RFC 733. That is, the capability you note is contrary to what I believe was intended in the RFC 5322 specification. And deviation from iontent is the requirement for qualifying as an errata on an RFC. I suggest you submit it. It will be interesting to see the followup. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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 insensitive names, but as far as I can tell, I could define a header like this: pickle-header = %d80.111.99.107.108.101 ":" CFWS ( "dill" / "garlic" / "kimchee" ) So this is a pickle-header Pickle: dill but this is not: pickle: garlic I'm not saying any sensible person would do that, but as far as I can tell, that's what the spec says. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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. Section 1.2.2 provides the basis for knowing whether a defined string is to be parsed in a case sensitive or insensitive manner. 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= field has to come first. Send an erratum, we'll probably accept it as hold for update. In RFC 6376, note Section 3.2 on tag lists. The ABNF shows no sensitivity to ordering. (The linkage to DKIM-Signature is Section 3.5, first paragraph.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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, there's no > ABNF for the header. So, for example, I don't know whether the v= field > has to come first. Send an erratum, we'll probably accept it as hold for > update. > "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. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
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= field has to come first. Send an erratum, we'll probably accept it as hold for update. By the way, all field names are case insensitive. RFC 5322 doesn't say that explicitly, but the ABNF for the field names makes it pretty clear, On the other hand, RFC 5322 also says that field names can be any printing ASCII character so this is be a valid header. $"%\)': plugh Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[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 http://mipassoc.org/dkim/ietf-list-rules.html
