[Ietf-dkim] Re: New drafts published

On Wed, Mar 19, 2025 at 10:49 AM Jim Fenton wrote: > I agree that the single-address-per-envelope model doesn’t have that > problem. But I wonder if it might make it a little easier for > implementations to operate only on the message header and not the envelope > itself, so perhaps having the re

[Ietf-dkim] Re: Review of draft-gondwana-dkim2-modification-alegbra-01

On Sun, Mar 16, 2025, at 22:33, Wei Chuang wrote: > Review of draft-gondwana-dkim2-modification-alegbra-01 > > > Overall: I'm very supportive of the direction of this draft, which is to > describe mutations in me

[Ietf-dkim] RFC 9057 Author: header (Was: Re: Goal of "mutations" objective?)

Steffen Nurpmeso wrote in <20250131180457.6WWds9D3@steffen%sdaoden.eu>: |John Levine wrote in | <20250131155823.b9661bab1...@ary.qy>: ||It appears that Dave Crocker said: ||>On 1/30/2025 1:39 PM, Jeremy Harris wrote: ||>> One useful thing from being able to recover the message as it arrived

[Ietf-dkim] Re: Forwarding, was Review: draft-gondwana-dkim2-motivation-01

On Sun 16/Mar/2025 04:59:57 +0100 Bron Gondwana wrote: On Sun, Mar 16, 2025, at 04:50, Alessandro Vesely wrote: I think an argument could be made that this definition doesn't apply to all relays. Systems that don't need to change 821.From or 821.To and don't modify the message being transferred

[Ietf-dkim] Re: Forwarding, was Review: draft-gondwana-dkim2-motivation-01

Alessandro Vesely wrote in <36be1ab7-4317-4ae6-9370-f2f2e8323...@tana.it>: ... |[.] Indeed, a DKIM signing filter running |during the outgoing connection can take also into account any 8BITMIME and |SMTPUTF8 parameters, which current DKIM implementations can only try \ |to guess. To say that

[Ietf-dkim] Re: New drafts published

On 3/5/25 9:14 PM, Murray S. Kucherawy wrote: On Wed, Mar 5, 2025 at 1:08 PM Michael Thomas wrote: I've been reading the draft mentioned in the charter re: replay and rcpt-to and don't understand why that changes anything wrt replay. If there is a message that a spammer has discove

[Ietf-dkim] Re: comments on draft-gondwana-dkim2-motivation

On 3/17/25 12:08 PM, Richard Clayton wrote: In message, Michael Thomas writes On 3/16/25 5:34 PM, Richard Clayton wrote:     PPS: I'm don't understand why this requires the rt= to be limited     to just one address. simplicity ... at the point at which an email is being signed it is not pos

[Ietf-dkim] Re: New drafts published

On 19 Mar 2025, at 1:30, Michael Thomas wrote: > On 3/5/25 9:14 PM, Murray S. Kucherawy wrote: >> On Wed, Mar 5, 2025 at 1:08 PM Michael Thomas wrote: >> >> I've been reading the draft mentioned in the charter re: replay and >> rcpt-to and don't understand why that changes anything wrt re

[Ietf-dkim] Re: New drafts published

On Wed, Mar 19, 2025 at 1:30 AM Michael Thomas wrote: > On 3/5/25 9:14 PM, Murray S. Kucherawy wrote: > > On Wed, Mar 5, 2025 at 1:08 PM Michael Thomas wrote: > >> I've been reading the draft mentioned in the charter re: replay and >> rcpt-to and don't understand why that changes anything wrt re

[Ietf-dkim] Re: New drafts published

On 19 Mar 2025, at 10:08, Murray S. Kucherawy wrote: > One of my long-ago drafts on this topic included the envelope as part of > what gets fed to the hash, and thus signed, but never adds it to the > signature or any other header field. That binds the signature to the > envelope recipient withou

[Ietf-dkim] Re: New drafts published

On Wed, Mar 19, 2025 at 10:14 AM Jim Fenton wrote: > I’d still be concerned about the confidentiality of the bcc recipient > addresses. If a recipient wanted to ask, “Did Bob get bcc’ed on this?” they > could potentially find out by trying to add Bob’s email address and seeing > if the hash match

[Ietf-dkim] Re: comments on draft-gondwana-dkim2-motivation

On Mon 17/Mar/2025 20:08:04 +0100 Richard Clayton wrote: In message , Michael Thomas writes On 3/16/25 5:34 PM, Richard Clayton wrote:     PPS: I'm don't understand why this requires the rt= to be limited     to just one address. simplicity ... at the point at which an email is being signe

[Ietf-dkim] Re: Review of draft-gondwana-dkim2-modification-alegbra-01

On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana wrote: > On Sun, Mar 16, 2025, at 22:33, Wei Chuang wrote: > > Review of draft-gondwana-dkim2-modification-alegbra-01 > > > Overall: I'm very supportive of the directi

[Ietf-dkim] Re: comments on draft-gondwana-dkim2-motivation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <746bd827-77d0-4991-ba67-507d84566...@mtcc.com>, Michael Thomas writes > simplicity ... at the point at which an email is being signed it is not possible to know how many recipients the receiving MTA will accept after each M

[Ietf-dkim] Re: New drafts published

On 19 Mar 2025, at 10:19, Murray S. Kucherawy wrote: > On Wed, Mar 19, 2025 at 10:14 AM Jim Fenton wrote: > >> I’d still be concerned about the confidentiality of the bcc recipient >> addresses. If a recipient wanted to ask, “Did Bob get bcc’ed on this?” they >> could potentially find out by tryi

[Ietf-dkim] Re: New drafts published

On Wed, Mar 19, 2025 at 10:29 AM Jim Fenton wrote: > If I understand what you are describing properly, the verifying MTA can > verify the signature, but an individual recipient wouldn’t have the > envelope information to do that with — they would rely on the > Authentication-Results header field

[Ietf-dkim] new AD, new co-chair

Greetings all, I am Andy Newton, incoming ART AD and new responsible AD for this working group. I would like to thank our outgoing ART AD, Murray, for all that he has done for DKIM. After Murray has stepped down as AD, I will be appointing him as a co-chair of DKIM alongside Pete (whom I am also

[Ietf-dkim] Re: New drafts published

On 19 Mar 2025, at 10:34, Murray S. Kucherawy wrote: > On Wed, Mar 19, 2025 at 10:29 AM Jim Fenton wrote: > >> If I understand what you are describing properly, the verifying MTA can >> verify the signature, but an individual recipient wouldn’t have the >> envelope information to do that with — t