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
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
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
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
> 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
On 08Feb18, Michael Thomas allegedly wrote:
> I dunno, it's not like there isn't precedent for this. oh say, like ipv4
> vs. ipv6?
Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
survived numerous upgraded and enhancements over a 36 year period and managed to
do just fin
On 2/9/2018 12:26 PM, Mark Delany wrote:
On 08Feb18, Michael Thomas allegedly wrote:
I dunno, it's not like there isn't precedent for this. oh say, like ipv4
vs. ipv6?
Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
survived numerous upgraded and enhancements over a 36
In article <20180209202621.31355.qm...@f3-external.bushwire.net>,
Mark Delany wrote:
Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
survived numerous upgraded and enhancements over a 36 year period and managed
to do just fine without a version.
RFC 822 may not have ve
On 09Feb18, John R. Levine allegedly wrote:
> RFC 822 may not have versions but 821/2821/5321 sure do.
>
> As soon as 2821 added EHLO, SMTP got service extensions and pretty
> much by their nature, those extensions are not backward compatible.
>
> Well-known examples are 8BITMIME and SMTPUTF8.
On Fri 09/Feb/2018 23:31:41 +0100 John R. Levine wrote:
>
> The DKIM v=2 hack I proposed is a lot like SMTP extensions in that if
> your signature doesn't need the new semantics, don't ask for them, so
> you should sign with v=1, so the old and new will coexist forever.
> Since they can easily be
On 2/9/2018 2:31 PM, John R. Levine wrote:
In article <20180209202621.31355.qm...@f3-external.bushwire.net>,
Mark Delany wrote:
Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
survived numerous upgraded and enhancements over a 36 year period and
managed
to do just fin
Sorry. Where is the version number for SMTP?
MAIL FROM:<Борис@пример.ru> SMTPUTF8<--
These are not 'version' flags. They are feature indicators.
They're both. If you use the feature, you're using the new version of the
message.
R's,
John_
22 matches
Mail list logo
