I suspect that my review of motivation-02 was missed because I sent it
in the middle if IETF week, so I’m resending it below. I see that a
couple of the comments (intended status, use of “header field”) have
been addressed elsewhere.
-Jim
Forwarded message:
From: Jim Fenton
To: ietf-dkim@i
On 4/3/25 7:42 PM, Pete Resnick wrote:
On 3 Apr 2025, at 16:56, Michael Thomas wrote:
I'd feel more comfortable if a few changes were made:
1. change i= to be something else that doesn't collide with STD 76
2. change t= back to x=. there doesn't seem to be any difference
parp
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@
On 4/3/25 2:20 PM, John R Levine wrote:
This short document proposes the tag structure for the DKIM2 header
and sketches out some of the other things DKIM2 will do.
It's a reasonable start on the spec and I think we should adopt it.
To the objection that we haven't agreed to use a different h
On 3 Apr 2025, at 16:56, Michael Thomas wrote:
I'd feel more comfortable if a few changes were made:
1. change i= to be something else that doesn't collide with STD 76
2. change t= back to x=. there doesn't seem to be any difference
beyond a different tag name.
3. Explain the anti-replay me
This short document proposes the tag structure for the DKIM2 header and
sketches out some of the other things DKIM2 will do.
It's a reasonable start on the spec and I think we should adopt it.
To the objection that we haven't agreed to use a different header rather
than extending existing DKIM
This document explains how a DKIM2 signer can describe the changes it's
made since a prior signature. I have concerns about some minor details,
like how it handles spacing and folding of headers, but it's definitely on
the right track so I think we should adopt it.
I hope that before we are d
