On 3/22/23 4:00 PM, Emanuel Schorsch wrote:
On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy
wrote:
On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch
wrote:
In my mind, there are two important things I would like to see
achieved:
1) Distinguish
On Wed, Mar 22, 2023 at 11:29 AM Murray S. Kucherawy
wrote:
> On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch 40google@dmarc.ietf.org> wrote:
>
>> In my mind, there are two important things I would like to see achieved:
>>
>> 1) Distinguish indirect from direct flows (encode in some way
On Sun, Mar 19, 2023 at 11:04 PM Emanuel Schorsch wrote:
> In my mind, there are two important things I would like to see achieved:
>
> 1) Distinguish indirect from direct flows (encode in some way which server
> / mailingList the original DKIM message was intended to come from). This is
>
On Mon 20/Mar/2023 07:04:11 +0100 Emanuel Schorsch wrote:
In my mind, there are two important things I would like to see achieved:
1) Distinguish indirect from direct flows (encode in some way which server /
mailingList the original DKIM message was intended to come from). This is
needed for
In my mind, there are two important things I would like to see achieved:
1) Distinguish indirect from direct flows (encode in some way which server
/ mailingList the original DKIM message was intended to come from). This is
needed for domains that aren't easily identifiable as direct flows (SPF
1:04 AM
To: ietf-dkim@ietf.org
Subject: Re: [Ietf-dkim] Welcome to the rechartered working group
As far as coupling the envelope and body, that seems extremely likely to suffer
from the law of unintended consequences. Frankly, as I wrote in my piece on
throwing my hands up on mailing lists
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
The reason that I think it would be useful in the problem statement is
that it would give a way to get people up to speed.
Both of the Problem Statement drafts have text relevant to the topic of
solution proposal.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 3/10/23 7:54 AM, Scott Kitterman wrote:
On Friday, March 10, 2023 9:14:05 AM EST Laura Atkins wrote:
What about solutions that have been tried but have drawbacks or are
ineffective? It would be nice to know what the current baseline is.
In some respects that depends on what form the final
On 3/10/2023 6:14 AM, Laura Atkins wrote:
Do you have any questions, edits or specific wording related to better
explaining the problem for either of the drafts that are currently
under discussion?
Does anyone have comments on the substance -- and especially about the
differences --
On 3/10/23 6:14 AM, Laura Atkins wrote:
On 9 Mar 2023, at 22:47, Michael Thomas wrote:
On 3/7/23 4:09 AM, Laura Atkins wrote:
There is a current problem statement at
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/.
Please take a moment to read through it and provide
On Friday, March 10, 2023 9:14:05 AM EST Laura Atkins wrote:
> > On 9 Mar 2023, at 22:47, Michael Thomas wrote:
> >
> > On 3/7/23 4:09 AM, Laura Atkins wrote:
> >> There is a current problem statement at
> >> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/.
> >> Please take a
> On 9 Mar 2023, at 22:47, Michael Thomas wrote:
>
>
> On 3/7/23 4:09 AM, Laura Atkins wrote:
>> There is a current problem statement at
>> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. Please
>> take a moment to read through it and provide feedback. This chair thinks
On 3/7/23 4:09 AM, Laura Atkins wrote:
There is a current problem statement at
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/.
Please take a moment to read through it and provide feedback. This
chair thinks we should not be providing solutions in the problem
statement.
All
The DKIM working group is now active again (thanks Murray!). The chairs wanted
to send out a short note to welcome everyone and talk about our next steps.
Our first deadline is next month - to get a consensus problem statement
submitted on the IETF data tracker at
20 matches
Mail list logo
