Mainframes are part of computing history too but there’s more than one of them
in production as we speak. If there is no protocol and only a best practice
solution then so be it.
--srs
From: Ietf-dkim on behalf of Michael Thomas
Sent: Monday, March 20, 2023
Took a moment to go over this purported problem with replays:
1.1. The problem
Since many domains (including those of bad actors) list DKIM records,
receiving systems track the history of messages using a DKIM-based
domain name, to formulate a reputation for the name, and then to
On 3/19/23 11:57 AM, Wei Chuang wrote:
On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins
wrote:
...
One of the panel members has shared the following from what he
said at the session:
* RFC 6376 itself says "x=" is not a viable mechanism to deal with
replay.
* There may
On March 19, 2023 6:57:13 PM UTC, Wei Chuang
wrote:
>On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins wrote:
>
>> ...
>> One of the panel members has shared the following from what he said at the
>> session:
>>
>> * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay.
>> *
On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins wrote:
> ...
> One of the panel members has shared the following from what he said at the
> session:
>
> * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay.
> * There may only be a best practices solution, and not a protocol
On 3/19/23 10:08 AM, Wei Chuang wrote:
* DKIM replay was considered during development of RFC- hence
the "x=" tag
Considering that x= was mine from the beginning, I can say without
question that replay wasn't what I had in mind. I always considered the
replay problem to be bogus since
I was one of the M3AAWG 57 SF DKIM replay session organizers that helped
put together the slides, so I can try to summarize some of the things in
the slides. (I was hit with Covid so couldn't attend in person) M3AAWG
has a confidentiality policy to permit greater knowledge sharing among
