[Ietf-dkim] Re: Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On 4 Apr 2025, at 14:31, John R. Levine wrote: > On Fri, 4 Apr 2025, Jim Fenton wrote: >>> My understanding is that it means forwarders /always/ rewrite the bounce >>> address. It could be SRS or anything to a similar effect. >> >> They don’t always do that. A “transparent forwarder” (think ~/

[Ietf-dkim] Re: Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On Fri, 4 Apr 2025, Jim Fenton wrote: So the original comment might have been intended to be, “it means forwarders that are compatible with DKIM++ /always/ rewrite the bounce address”. That seems right. It's true, existing forwarders that just change the recipient address aren't compatible b

[Ietf-dkim] Re: Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On 4 Apr 2025, at 15:48, Jim Fenton wrote: > I may have understood Ale’s comment. Apparently transparent forwarders like I > described, which of course will still exist, are not compatible with DKIM++. That should have read, “I may have misunderstood”. -Jim

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

On Wed 02/Apr/2025 10:45:43 +0200 Steve Atkins wrote: On 2 Apr 2025, at 00:26, Michael Thomas wrote: 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

[Ietf-dkim] Re: Whether to adopt draft-gondwana-dkim2-modification-alegbra-01

On 2025/04/04 1:57 AM, John R Levine wrote: I hope that before we are done we can get people who maintain mailing lists involved so we can see how well the algebra describes what they do to messages, or conversely whether they might tweak their changes to make them easier to  describe. I agre

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

On 3/30/25 6:54 PM, Murray S. Kucherawy wrote: On Sun, Mar 30, 2025 at 5:33 PM Michael Thomas wrote: Does this run on the assumption that DKIM isn't a trace header? I keep asking and nobody will answer. Two different working groups, two different bouts of silence. As I recall, we

[Ietf-dkim] Re: Resending: Review of draft-gondwana-dkim2-motivation-02

Jim Fenton wrote in : |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 messa

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

On Sun 30/Mar/2025 21:12:25 +0200 Dave Crocker wrote: On 3/30/2025 12:10 PM, Murray S. Kucherawy 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

[Ietf-dkim] Re: Whether to adopt draft-gondwana-dkim2-modification-alegbra-01

I support adoption of draft-gondwana-dkim2-modification-alegbra to enable further discussion within the DKIM working group. We'll need some form of message "algebra" to get the full promise of DKIM2 meaningfully solving the mailing list problem. It's not perfect as I described on the March 16th t

[Ietf-dkim] Re: Whether to adopt draft-gondwana-dkim2-header-00

On 4 Apr 2025, at 0:53, Michael Thomas wrote: It would be good to see some good faith on the authors... This, and the rest of this message, is completely inappropriate. We do not question the motives of other participants on the list; we stick to the technical content. If you have concerns a

[Ietf-dkim] Re: Whether to adopt draft-gondwana-dkim2-modification-alegbra-01

It appears that Jeremy Harris said: >On 2025/04/04 1:57 AM, John R Levine wrote: >> I hope that before we are done we can get people who maintain mailing lists >> involved so we can see how well the algebra describes what they do to >> messages, or >conversely whether they might tweak their cha

[Ietf-dkim] Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On Wed 02/Apr/2025 23:48:23 +0200 Jim Fenton wrote: Section 2.3: I’m wondering how sending bounces in reverse along the same path will work for large domains. Presumably it does an MX lookup of the sending domain? There might be incoming third-party mail handlers, and the domain itself may have

[Ietf-dkim] Re: Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On 4 Apr 2025, at 9:41, Alessandro Vesely wrote: > On Wed 02/Apr/2025 23:48:23 +0200 Jim Fenton wrote: >> Section 2.3: I’m wondering how sending bounces in reverse along the same >> path will work for large domains. Presumably it does an MX lookup of the >> sending domain? There might be incomin

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

On 31/03/2025 19:35, John Levine wrote: I don't understand what point you are making. The spec says that's wrong. How would the presence or absence of v=2 make it less wrong? It's not about if it's wrong or not, it's only an observation that this behavior already exists in the ecosystem as a

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

On 31/03/2025 17:53, Michael Thomas wrote: It was always a bad idea to strip signatures, and continues to be. The text of DKIM couldn't be more clear that a broken signature is equivalent to no signature and broken signatures have always had forensic value. Unfortunately in reality broken si

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

Alessandro Vesely wrote in <87ebd93e-931a-4c74-99f5-256dd947c...@tana.it>: |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

[Ietf-dkim] IETF 122 DKIM Meeting Minutes

Murray posted the meeting minutes the other day, but I dropped the ball on announcing them. They are here: https://datatracker.ietf.org/doc/minutes-122-dkim/ Please review and let us know if anything needs fixing. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are te

[Ietf-dkim] Re: DKIM2 Signature Hashing Strawman

On 4/1/25 7:46 PM, Wei Chuang 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 isn't

[Ietf-dkim] Re: Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On Fri, 4 Apr 2025, Jim Fenton wrote: They don’t always do that. A “transparent forwarder” (think ~/.forward or /etc/aliases in *nix) typically leaves the envelope-from address alone. That is a long-standing behavior that isn’t likely to change. Keeping the original bounce address, alias forw

[Ietf-dkim] Review of draft-gondwana-dkim2-motivation-02

This describes the motivation for DKIM2/EKIM. I see it as a place to track what we're trying to do and what features do those things. I do not expect it to turn into an RFC. With the agreed change that it should be info rather than std (or maybe historic to note that it's not intended to liv

[Ietf-dkim] The DKIM WG has placed draft-gondwana-dkim2-modification-alegbra in state "Candidate for WG Adoption"

The DKIM WG has placed draft-gondwana-dkim2-modification-alegbra in state Candidate for WG Adoption (entered by Murray Kucherawy) The document is available at https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/ ___ Ietf-dkim ma

[Ietf-dkim] Milestones changed for dkim WG

Changed milestone "Adopt overview document", set due date to April 2025 from March 2025. Changed milestone "Adopt mechanism document", set due date to April 2025 from March 2025. URL: https://datatracker.ietf.org/wg/dkim/about/ ___ Ietf-dkim mailing li

[Ietf-dkim] Re: Bounces, was Resending: Review of draft-gondwana-dkim2-motivation-02

On Fri, 4 Apr 2025, Jim Fenton wrote: My understanding is that it means forwarders /always/ rewrite the bounce address. It could be SRS or anything to a similar effect. They don’t always do that. A “transparent forwarder” (think ~/.forward or /etc/aliases in *nix) typically leaves the envelo

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

It appears that Alessandro Vesely said: >> I'd say that if DKIM1 passes a signature that is supposed to fail, that is >> badly broken. > >In that case, having two separate signatures, DKIM1 and DKIM2, would produce >the same result, DKIM1 passes while DKIM2 fails, with both verifiers perfectly

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

On 3/30/25 6:25 PM, Allen Robinson wrote: On Sun, Mar 30, 2025, 8:33 p.m. Michael Thomas wrote: On 3/30/25 5:21 PM, John Levine wrote: It appears that Michael Thomas said: I seem to recall previous discussions have suggested that the "v" tag shouldn'