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://mi
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
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
> ABN
"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, j
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. S
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 inse
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 spe
> "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 exposin
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=
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 backw
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 heade
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
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
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
>
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
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 loo
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 k
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
b
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 lib
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 d
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 dkim-s
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
mar
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 th
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 (":"), fo
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
>> he
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. R
> 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 cano
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
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. I
> 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 effe
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
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
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 InternetWorkin
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.
Than
34 matches
Mail list logo