Agree with Mike regarding ARC. Not a fan of adding more 5322 overhead for an isolated purpose, but I want to further explore how ARC can save broken mail, or more specifically 1) a SMTP forward where SPF now fails at the next unexpected hop or 2) a LIST distribution DKIM 1st party signature failure occurs due to modified content. A resigner is present but not acknowledged in our current frame of authorization thought.
We have two integrated concepts: 1) Use ARC to resolve the broken integrity transition, or 2) Use DMARCBis “auth=“ proposal to resolve a broken SPF or DKIM. — HLS > On Aug 4, 2023, at 2:41 PM, Michael Thomas <[email protected]> wrote: > > > > On 8/4/23 11:31 AM, Tim Wicinski wrote: >> >> Michael >> >> Actually it appears draft-chuang-replay-resistant-arc is listed in the >> charter (I had to check for myself). >> We can have the larger ARC discussion but I'll want to talk to Murray and >> Laura on that also. > And what of the mailing list traversal? That clearly has nothing at all to do > with the current charter. > > DKIM is a full internet standard. ARC is an experiment with no data given to > show that it does anything that DKIM can't. Any proposal should be written in > terms of modifications to DKIM itself, not some unproven experiment. > > Mike > >> >> tim >> >> >> On Fri, Aug 4, 2023 at 2:27 PM Michael Thomas <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> On 8/4/23 11:12 AM, Wei Chuang wrote: >>> > Hi all, >>> > I just wanted to mention two proposals for tolerating mailing list >>> > modifications as suggested in person IETF-117. They both use ARC >>> > headers as infrastructure, but go about tolerating mailing list >>> > modifications in different ways. >>> > 1) Disclose and reverse mailing list transforms so that we can >>> > authenticate those messages with the original DKIM signature: >>> > https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/ >>> > 2) Replay-resistant-arc draft proposes authenticating a sender defined >>> > path from originating sender to receiver. It also has the sender >>> > specify the intended recipient to prevent replay amplification. It is >>> > insensitive to message body modifications: >>> > https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ >>> > Both approaches do not require trusting results in >>> > ARC-Authentication-Results which has been a concern. Instead they >>> > provide signatures and values that a third party can independently and >>> > objectively verify. Discussion of these drafts belong on the DKIM >>> > list ([email protected] <mailto:[email protected]>). Also just >>> > mentioning I've heard there are >>> > other interesting related drafts. >>> > >>> What does this have to do with the current charter? ARC is off-topic and >>> should be banned by the chairs. That is especially true since DKIM is a >>> full internet standard and ARC is an experiment with no supporting data >>> to show that it's done what it claims. >>> >>> Mike >>> >>> _______________________________________________ >>> Ietf-dkim mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/ietf-dkim > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
