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
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 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
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
> 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
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
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
> 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 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
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
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
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
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
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
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
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
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 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: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
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
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
>
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
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 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
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: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=
> "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: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
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 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
"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 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
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
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
34 matches
Mail list logo