On Mon 31/Mar/2025 21:32:54 +0200 John Levine wrote:
Most (all?) non-trace headers are defined to occur only once, like From: and
Subject:
How about we say that if a signer or verifier sees more than one of them, stop
and the result is failure, no oversigning needed.
+1, make this part of
When calling to have a wg adopt a draft, it is worth reviewing comments
on that draft beforehand Apologies for not responding to this
semi-official response to my unofficial review of the draft in January.
I will note that Allen's was the only response to my detailed review.
And it was only t
On 4/1/25 10:07 AM, John R Levine wrote:
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
Sorry for being unclear. What I meant was that, given DKIM2, a DKIM1
verifier could be updated to handle DKIM2 signatures —if DKIM2
signatures were specified with compatibility in mind.
That makes no sense
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
The only trace header I think it's likely we'll sign is the previous DKIM2
signatures which is easy enough, just sign them in order up through the
current one.
Rather than signing DKIM2-Signature:'s (or whatever they're named), the idea
of an hh= h
On Tue 01/Apr/2025 19:07:40 +0200 John R Levine wrote:
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
Sorry for being unclear. What I meant was that, given DKIM2, a DKIM1 verifier
could be updated to handle DKIM2 signatures —if DKIM2 signatures were
specified with compatibility in mind.
That ma
On 31 Mar 2025, at 10:53, Murray S. Kucherawy wrote:
> On Mon, Mar 31, 2025 at 10:45 AM Jim Fenton wrote:
>> I get the sense that some feel there’s a stigma associated with the name
>> DKIM, so the new thing ought to be given a different name. I have thought
>> much the opposite, that calling th
On Mon 31/Mar/2025 18:40:30 +0200 John Levine wrote:
It appears that Murray S. Kucherawy said:
On Mon, Mar 31, 2025 at 1:56 AM Alessandro Vesely wrote:
There is room for a lot of compatibility. If we don't change the
canonicalizations, a DKIM1 verifier will be able to verify a DKIM2
signat
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
That makes no sense at all. Why would you waste time making a semi-broken
DKIM verifier rather than just using a DKIM2 verifier? It's just a
software library.
The resulting DKIM verifier is not semi-broken, it's DKIM2-tolerant. And
it's not just
On Tue, Apr 1, 2025 at 10:26 AM Alessandro Vesely wrote:
> The resulting DKIM verifier is not semi-broken, it's DKIM2-tolerant. And
> it's
> not just a library change, it's also the MTA interface.
>
First you said: "a DKIM1 verifier will be able to verify a DKIM2 signature,
limited to DKIM1 sem
On 4/1/25 10:41 AM, John R Levine wrote:
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
That makes no sense at all. Why would you waste time making a
semi-broken DKIM verifier rather than just using a DKIM2 verifier?
It's just a software library.
The resulting DKIM verifier is not semi-broke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Michael
Thomas writes
>Two different code paths, two different places for screw ups and
>maintenance. I'm with Murray that there is a lot of appeal to backward
>compatibility.
why would you want to maintain a codebase that handled bo
On Mon, Mar 31, 2025 at 12:32 PM John Levine wrote:
> It appears that Wei Chuang said:
> >To sign a message, the signer must find the maximum instance tag "i=n",
> >denoted as M. To add a new DKIM2-Signature, first verify that there isn't
> >any to be defined in the future indication that the
On 4/1/25 3:19 PM, Richard Clayton wrote:
In message , Michael
Thomas writes
> Two different code paths, two different places for screw ups and
> maintenance. I'm with Murray that there is a lot of appeal to backward
> compatibility.
why would you want to maintain a codebase that handled both
On just a couple of process points:
On 1 Apr 2025, at 22:30, Dave Crocker wrote:
When calling to have a wg adopt a draft, it is worth reviewing
comments on that draft beforehand
The draft version that was called for adoption is drastically different
than the draft on which you commented, and
On Tue, Apr 1, 2025 at 7:52 PM Michael Thomas wrote:
> On Mon, Mar 31, 2025 at 12:32 PM John Levine wrote:
>
>> It appears that Wei Chuang said:
>> >To sign a message, the signer must find the maximum instance tag "i=n",
>> >denoted as M. To add a new DKIM2-Signature, first verify that there
On Mon, Mar 31, 2025 at 10:45 AM Jim Fenton wrote:
> > I seem to recall previous discussions have suggested that the "v" tag
> > shouldn't have been included in the first place; if things are so
> different
> > that you need to change the version, you may as well change the name of
> the
> > head
On Tue, 1 Apr 2025, Michael Thomas wrote:
Either way it seems like a severe waste of time to do that rather than make
DKIM2 work. I see no chance that DKIM2 or EKIM or whatever we call it will
use the same signature header so it's purely hypothetical anyway.
What protocol draft are you basing
On 4/1/25 11:08 AM, John R. Levine wrote:
On Tue, 1 Apr 2025, Michael Thomas wrote:
Either way it seems like a severe waste of time to do that rather
than make DKIM2 work. I see no chance that DKIM2 or EKIM or
whatever we call it will use the same signature header so it's
purely hypothetical
On Tue, 1 Apr 2025, Alessandro Vesely wrote:
Sorry for being unclear. What I meant was that, given DKIM2, a DKIM1 verifier
could be updated to handle DKIM2 signatures —if DKIM2 signatures were
specified with compatibility in mind.
That makes no sense at all. Why would you waste time making a
19 matches
Mail list logo
