[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

2024-11-07 Thread Burke, Evan
I also strongly support this initiative. I really like what I've seen of the work on this so far; it's clear a lot of thought has been put into this design, and I want to express my appreciation to Wei, Bron, and Richard for their efforts on this - as well as anyone else who's contributed. My inte

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

2025-04-14 Thread Burke, Evan
Regardless of the specific words we may use to describe it, I've seen some very large email platforms omit some important headers in their DKIM signatures - headers explicitly recommended by the DKIM RFC - and I've seen that absence enable real-world abuse. Based on samples from multiple senders o

[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 Burke, Evan
ntext of DKIM replay. On Mon, Apr 14, 2025 at 9:08 PM Dave Crocker wrote: > On 4/14/2025 11:41 PM, Burke, Evan wrote: > > Regardless of the specific words we may use to describe it, I've seen some > very large email platforms omit some important headers in their DKIM > signat

[Ietf-dkim] Re: Replay abuse, was New Version Notification for draft-crocker-dkor-00.txt

2025-06-10 Thread Burke, Evan
1:1 abusive mail flows are not particularly common, but they do currently exist, and will continue to exist, regardless of whether they are direct or indirect mail flows. That's not a flaw here. Anti-spam/anti-abuse systems are more suited for the role of mitigating 1:1 abuse than any authenticati