Would this effort be better targeted at the various open source as well as
proprietary implementations of DKIM libraries, to flag if not eliminate the
various edge cases that are being gamed by the spammers?
Rolling out software with a sane set of configuration defaults would typically
mean
+1
--srs
From: Ietf-dkim on behalf of Scott Kitterman
Sent: Wednesday, April 5, 2023 1:11:50 AM
To: ietf-dkim@ietf.org
Subject: Re: [Ietf-dkim] Call for adoption
My view as well. +1 for adoption.
Scott K
On April 4, 2023 4:10:41 PM UTC, Barry Leiba wrote:
March 2023 at 7:51 AM
To: Suresh Ramasubramanian , Laura Atkins
Cc: ietf-dkim@ietf.org
Subject: Re: [Ietf-dkim] What has been tried and doesn't work should be
documented in the problem statement
On 3/28/23 7:16 PM, Suresh Ramasubramanian wrote:
Let me clarify that
1. I think Mike’s tone
one of the
other chairs warn Mike.
thanks
--srs
From: Suresh Ramasubramanian
Date: Wednesday, 29 March 2023 at 7:34 AM
To: Michael Thomas , Laura Atkins
Cc: ietf-dkim@ietf.org
Subject: Re: [Ietf-dkim] What has been tried and doesn't work should be
documented in the problem statement
I would
I would request that both the parties in this disengage and refer this to the
other group chairs.
While a difference of opinion on what is and is not in scope for this WG is
fine, this conversation has taken an ugly turn at this point.
From: Ietf-dkim on behalf of Michael Thomas
Date:
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
