Manfred said:
(Seems like "seal"ing would be a better term than "oversign"ing.)
We've called it oversigning for a decade now.
R's,
John
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
John Levine wrote in
<20240119192026.dedff8104...@ary.qy>:
|It appears that Evan Burke said:
|>> Insisting on using the same term for these two different cases has an
|>> academic purity to it, but has already been demonstrated to be destructi\
|>> ve
|>> in practical terms, because it
Dave Crocker wrote in
<54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>:
|On 1/19/2024 6:51 AM, Al Iverson wrote:
...
|[.]the scenario of
|sending to a collaborating receiver and re-posting a message that has no
|differences except the envelope rcpt-to value, does not have a know
Steffen Nurpmeso wrote in
<20240120002211.9zE1qqLr@steffen%sdaoden.eu>:
...
|[.]people which[.]
So that is "people who", and then i wanted to apologise for naming
Mr. Kucherawy "Kucheraway" in one of all those of my posts.
Have a nice weekend i wish from Germany,
--steffen
|
|Der Kragenbaer,
Emanuel Schorsch wrote in
:
|I don't have a strong horse in this race. But I'll just chime in that from
|my perspective I was thinking of both of these as DKIM Replay. I have been
|calling any case where the DKIM signature is not broken and the spammer
|resends multiple copies as DKIM Replay.
Steffen Nurpmeso wrote in
<20240119235632.VOlkKoIX@steffen%sdaoden.eu>:
|Dave Crocker wrote in
| <54bcc79e-2cec-4c49-8a5c-0ef64db68...@dcrocker.net>:
||On 1/19/2024 6:51 AM, Al Iverson wrote:
...
||[.]does not have a know
||solution.
|
|There would be a RFC 6376 backward compatible
I don't have a strong horse in this race. But I'll just chime in that from
my perspective I was thinking of both of these as DKIM Replay. I have been
calling any case where the DKIM signature is not broken and the spammer
resends multiple copies as DKIM Replay.
On Fri, Jan 19, 2024 at 11:20 AM
It appears that Evan Burke said:
>> Insisting on using the same term for these two different cases has an
>> academic purity to it, but has already been demonstrated to be destructive
>> in practical terms, because it creates confused discussion.
>No, that's exactly backwards. The oversigning
On Fri, Jan 19, 2024 at 7:01 AM Dave Crocker wrote:
> On 1/19/2024 6:51 AM, Al Iverson wrote:
>
> I'm
> sort of boggling at the attempt to keep potential header changes and
> DKIM oversigning out of the exploit definition and potential solution
> consideration. I just don't think it makes sense
On 1/19/2024 6:51 AM, Al Iverson wrote:
I'm
sort of boggling at the attempt to keep potential header changes and
DKIM oversigning out of the exploit definition and potential solution
consideration. I just don't think it makes sense to exclude this.
It makes sense because oversigning is
I don't know what other people have decided off in spec land to call
this, but here what I'm seeing is somebody taking a message, adding
headers (or not), re-injecting the message to another recipient, it
being received with DKIM signature intact, that's DKIM replay. I'm
sort of boggling at the
11 matches
Mail list logo
