Hi!
On 07.11.2024 22:10, Jim Fenton wrote:
On 7 Nov 2024, at 18:21, Mark E. Mallett wrote:
To gain widespread adoption, it is expected that design proposals will
be tested during the development of specifications. The working group
will favor designs that are tested at scale and may dism
On 11/6/24 4:26 PM, Bron Gondwana wrote:
I think now is an ideal time to re-start this work at the IETF. The
design is still evolving and there's plenty of space for an IETF
working group to improve it further, yet it's also had enough design
work put in by people with operational experience
Hi All,
Fully support this, and looking forward to seeing it through to a working
implementation at Fastmail, and as maintainer of the Mail::DKIM Perl module.
On Thu, 7 Nov 2024, at 11:26 AM, Bron Gondwana wrote:
> Hi All,
>
> I prepared presentations about DKIM2 for two places at IETF121 - ALL
Alessandro Vesely wrote in
<319a066f-5719-4569-8e5e-3d46cef5b...@tana.it>:
|On Thu 07/Nov/2024 01:26:46 +0100 Bron Gondwana wrote:
|> I think now is an ideal time to re-start this work at the IETF. \
|> The design is
|> still evolving and there's plenty of space for an IETF working group \
Am 07.11.24 um 01:26 schrieb Bron Gondwana:
We have a draft charter here: https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA
Hello all,
I also support the proposed work. My focus is not the design in a first place.
I trust the people with much more expertise here ...
I favor the operational view
On 7 Nov 2024, at 18:21, Mark E. Mallett wrote:
> Commenting from the peanut gallery:
>
> I've looked at some of the things that have been sent out in the
> recent past and have been quite interested. I'll follow along and
> participate to some degree once I know where.. But:
>
> On Thu, Nov 07, 2
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
As a member of the sending community I am very excited about the work Bron,
Richard and Co. have already done and have joined here to help continue the
work.
This proposal will help with dkim-reply and if done correctly could
eliminate the need for ARC and possibly even SPF. We need a new way to
On Thu 07/Nov/2024 01:26:46 +0100 Bron Gondwana wrote:
I think now is an ideal time to re-start this work at the IETF. The design is
still evolving and there's plenty of space for an IETF working group to improve
it further, yet it's also had enough design work put in by people with
operatio
I look forward to this work being evaluated by the broader community... with a
specific interest in the production of what the proposed charter describes as
“An algebra for describing how to reverse common changes to email content.”
Fortunately, a proposal has already been submitted for conside
Commenting from the peanut gallery:
I've looked at some of the things that have been sent out in the
recent past and have been quite interested. I'll follow along and
participate to some degree once I know where.. But:
On Thu, Nov 07, 2024 at 03:55:18PM +, Bron Gondwana wrote:
>
> To gain w
The motivations have been stated, and I think most folks agree with them. It
feels like the proposed features should be easily adoptable by a majority of
participants in the ecosystem. Looks to be a good way forward, and an
improvement for parties involved.
--
Alex Brotman
Sr. Engineer, Anti-A
On Thu, 7 Nov 2024, Richard Clayton wrote:
One nit, that can be addressed in one of the outcomes: DKIM2 best DNS
practices. ...
elliptic curve keys are considerably smaller than RSA keys ...
I have heard people argue that we should deprecate RSA keys, but that
would mean that you could not use
I think there are operational documents on key rotation and best practices. I
think M3AAWG has such documents, however, my point is that this group should
strive to design a protocol that makes life easier for all of us.
IETF security goals sometimes fails because operationally it is very heavy.
My experience is a bit old, but I had issues of interoperability with a well
known vendor of large-scale email send. It was very hard to debug the issues,
and they eventually decided to adopt opendkim, because many were using it
already.
I’m not saying these nits should be explicitly in the cha
On 7 Nov 2024, at 16:26, Franck Martin wrote:
This charter looks very good, but.. I think it is missing to address
explicitly the following pain points: key rotation and cypher
upgrades.
Cypher upgrades seems like a reasonable thing to mention in the charter,
even though I'm pretty sure that
On Thu, Nov 7, 2024 at 4:26 PM Franck Martin wrote:
> A last nit, many standardized on opendkim, because of interoperability.
> There were too many weird things happening between different
> implementations of DKIM1. I don’t know if interoperability should be better
> addressed (better debugging,
Hi Bron,
This charter looks very good, but.. I think it is missing to address explicitly
the following pain points: key rotation and cypher upgrades.
It speaks about the transition from DKIM1 to DKIM2, which is very good, but it
should build upon this to ensure a constant evolution of the cyphe
On Thu, Nov 7, 2024 at 9:58 AM Bron Gondwana
wrote:
>
> The proposed charter text has been workshopped by a few people already, but I
> would also welcome any comments here. For posterity, here's the current
> proposed text (for ease of quoting individual paragraphs in responses):
[...]
> As
The proposed charter text has been workshopped by a few people already, but I
would also welcome any comments here. For posterity, here's the current
proposed text (for ease of quoting individual paragraphs in responses):
DKIM2 Draft Charter
Attribution of email is made difficult by the exact p
On Thu, Nov 7, 2024 at 12:27 AM Bron Gondwana wrote:
> We have a draft charter here:
> https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA
>
I've loaded that text into the datatracker for DKIM, and move it to "Draft
Charter" state:
https://datatracker.ietf.org/doc/charter-ietf-dkim/
Comments from peo
I see numerous advantages in many of the proposed changes, and I’m eager to
continue working towards building a consensus around this proposal. In my day
job, we’ve had to allocate significant engineering resources to mitigate DKIM
replay abuse affecting our domains. We’d much prefer to channel
As the former chair of the dissolved working group, I support this work. Unlike
the previous group, this has much more community buy in and folks who are
willing and able to contribute to the effort. This work also focuses on overall
improvements to the protocol in a way that reflects how modern
I'm looking forward to engage in consense finding discussions. At my dayjob at
GMX/Web.de/Mail.com I already reserved engineering time for the coming months
to work on inter-op testing of this.
/ Tobias Herkula
From: Bron Gondwana
Sent: 07 November 202
24 matches
Mail list logo
