On Sun 06/Aug/2023 18:07:15 + Jesse Thompson wrote:
On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
[...]
The replay attackers aren’t sending what we commonly think of as spam
through the signers - as the message is sent to one recipient (not
bulk) and it is opt-in (that recipient wa
On 07/08/2023 05:22, Jesse Thompson wrote:
For messages which are originally submitted as BCC and, depending on the
circumstances, it's necessary for us to identify the recipient in the headers,
what is/should be the standard header to use for this purpose? BCC?
Forwarded-to?
There is no suc
> By all means, let's make this a cesspool of irrelevant junk. Especially for
> junk that clearly has no clue about the
> history of DKIM.
Mike, that's out of line; please stop that sort of characterization.
Barry
___
Ietf-dkim mailing list
Ietf-dkim@
> I wasn't sure if I-Ds should set up normative references. Based on the
> comments I'm guessing that I should
> have. I can make a pass to fix all that.
Yes, sure they should. Things that have to be understood in order to
understand the I-D are normative. Things that just give additional
inf
Jeremy Harris wrote in
<25aead67-8b9f-1db0-076d-12620a394...@wizmail.org>:
|On 07/08/2023 05:22, Jesse Thompson wrote:
|> For messages which are originally submitted as BCC and, depending \
|> on the circumstances, it's necessary for us to identify the recipient \
|> in the headers, what is/sh
Steffen Nurpmeso wrote in
<20230807170617.91_dg%stef...@sdaoden.eu>:
|Jeremy Harris wrote in
| <25aead67-8b9f-1db0-076d-12620a394...@wizmail.org>:
||On 07/08/2023 05:22, Jesse Thompson wrote:
...
|ML-specific headers). That is, enable restoration and DKIM
|checking of the original, pre-modi
Hi,
Some comments after a review of the adopted document:
(1) I find the abstract is more readable if broken into three paragraphs,
with the second starting "DKIM survives ..." and the third "This document
discusses ...".
(2) Throughout the document, the proper term "Replay Attack" (and sometime
On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
...
> (2) Throughout the document, the proper term "Replay Attack" (and sometimes
> "Replay") is used, but it's never directly defined. I don't think you need
> it to be formal, but if you really want to do it that way, please add
On 8/7/2023 3:58 PM, Scott Kitterman wrote:
I think a definition that describes a condition that's technically
distinguishable from normal DKIM operations is essential if we are going to
make any progress.
Except that the draft notes that isn't possible.
There's a fair amount of text in 1.1 th
On August 7, 2023 11:10:07 PM UTC, Dave Crocker wrote:
>On 8/7/2023 3:58 PM, Scott Kitterman wrote:
>> I think a definition that describes a condition that's technically
>> distinguishable from normal DKIM operations is essential if we are going to
>> make any progress.
>
>Except that the draft no
On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman
wrote:
> On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> ...
> > (2) Throughout the document, the proper term "Replay Attack" (and
> sometimes
> > "Replay") is used, but it's never directly defined. I don't think you
> need
> >
On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman
>
> wrote:
> > On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote:
> > ...
> >
> > > (2) Throughout the document, the proper term "Replay Attack" (and
> >
> > som
On Mon, Aug 7, 2023, at 3:42 AM, Alessandro Vesely wrote:
> On Sun 06/Aug/2023 18:07:15 + Jesse Thompson wrote:
> > On Sat, Aug 5, 2023, at 6:50 AM, Laura Atkins wrote:
> >>> [...]
> >>>
> >> The replay attackers aren’t sending what we commonly think of as spam
> >> through the signers - as th
On Sun, Aug 6, 2023 at 10:23 PM Jesse Thompson wrote:
> On Sun, Aug 6, 2023, at 2:00 PM, Emanuel Schorsch wrote:
>
>
>
> On Sun, Aug 6, 2023 at 11:52 AM Wei Chuang 40google@dmarc.ietf.org> wrote:
>
>
>
> On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins
> wrote:
>
>
>
> On 5 Aug 2023, at 02:43, J
On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson wrote:
> Similar to what Emmanuel is saying about detecting SPF/DKIM zone
> misalignment, the solution to DKIM replay is for receivers to maintain some
> state and feed it into bespoke replay detection algorithms. If all
> receivers can maintain this
On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch wrote:
> If there are not that many BCC recipients for a message then it is likely
> not necessary as the duplicate message counting is unlikely to have a
> negative impact. If there are a large number of BCC recipients for a given
> message then I
On Mon, Aug 7, 2023, at 10:24 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson wrote:
>> __
>> Similar to what Emmanuel is saying about detecting SPF/DKIM zone
>> misalignment, the solution to DKIM replay is for receivers to maintain some
>> state and feed it into b
On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch
> wrote:
>> If there are not that many BCC recipients for a message then it is likely
>> not necessary as the duplicate message counting is unlikely to have a
>> negative impact. If th
On Mon, Aug 7, 2023 at 9:23 PM Jesse Thompson wrote:
> On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
>
> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch 40google@dmarc.ietf.org> wrote:
>
> If there are not that many BCC recipients for a message then it is likely
> not necessar
19 matches
Mail list logo
