On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas <m...@mtcc.com> wrote:
> > On 2/10/23 10:23 AM, Wei Chuang wrote: > > Hi all, > I've posted an updated version of the draft-chuang-dkim-replay-problem-01 > <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/01/> > draft. It cleans up a lot from the -00 rough draft state so hopefully it's > more clear. It builds a case that spammers are exploiting DKIM through > replay, identifies conflicting scenarios, and outlines a solution space. > > > Again, drop the reference to ARC. it is: 1) Experimental, 2) the claim > about it is wrong (DKIM can already sign a previous auth-res), and 3) this > is the DKIM wg and it holds no power to make changes in it anyway. > I disagree. ARC is a tool to help support modern Indirect Mail Flows, and I believe belongs in the solution space to be explored. The large section in that draft is explicitly to make the point that we need to support those Indirect Mail Flows when we come up with a solution for DKIM Replay. Please come up with a workable proposal preferably in I-D form to support Indirect Mail Flows and prevent DKIM replay. -Wei > When we finally get some chairs, we should make it explicitly out of scope. > > Mike > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
