[Ietf-dkim] Re: Review Response #2: DKIM replay

2025-04-15 Thread Burke, Evan
On Sat, Apr 12, 2025 at 12:45 AM Dave Crocker wrote: > > Out in the real world, the problem is caused by lack of adequate > controls over users, on some platforms. Consider an outbound email spam filtering system that's 99.9% accurate. Under normal circumstances, that's good performance. Under

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-15 Thread Dave Crocker
On 4/15/2025 9:21 PM, Bron Gondwana wrote: Honestly, with the capacity to undo header changes from dkim2-modification-algebra I would be more inclined to have the spec list headers which MUST NOT be signed (probably just trace headers), and to list additional headers to not sign, rather than ad

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-15 Thread Bron Gondwana
Honestly, with the capacity to undo header changes from dkim2-modification-algebra I would be more inclined to have the spec list headers which MUST NOT be signed (probably just trace headers), and to list additional headers to not sign, rather than additional headers to sign. I would also ment

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-15 Thread Burke, Evan
It would be impolite to name names at this stage, and the appropriate time to talk publicly about details is once those sending platforms have begun signing the fields recommended in the RFC. That said, I'm sure you can imagine the kinds of problems key unsigned headers might pose in the context of

[Ietf-dkim] Re: what not to sign, was Review Response #7

2025-04-15 Thread John Levine
It appears that Bron Gondwana said: >-=-=-=-=-=- > >Honestly, with the capacity to undo header changes from >dkim2-modification-algebra I would be more inclined to have the spec list >headers which MUST >NOT be signed (probably just trace headers), and to list additional headers to >not sign,

[Ietf-dkim] Re: what not to sign, was Review Response #7

2025-04-15 Thread Bron Gondwana
On Tue, Apr 15, 2025, at 21:10, John Levine wrote: > It appears that Bron Gondwana said: > >-=-=-=-=-=- > > > >Honestly, with the capacity to undo header changes from > >dkim2-modification-algebra I would be more inclined to have the spec list > >headers which MUST > >NOT be signed (probably

[Ietf-dkim] Re: what not to sign, was Review Response #7

2025-04-15 Thread John R Levine
On Tue, 15 Apr 2025, Bron Gondwana wrote: I think it would be workable to say that if a header you sign is a trace or resent header, the signature includes all the instances below the signature itself, and if a mail system reoders them, which it shouldn't, too bad, the signature breaks. The p