On 14/11/22 08:41, Scott Kitterman wrote:
On November 12, 2022 6:46:13 PM UTC, Wei Chuang
<weihaw=40google....@dmarc.ietf.org> wrote:
>
>Received headers are generally not DKIM signed and spammers have
>stripped/probably modified them. Another problem is that while a human can
>interpret the domain names, IP and other information present there in the
>headers, the non-standard naming and format variations means that it's not
>suitable as a machine readable signal in my opinion.
I don't think there's any point in pursuing solutions that require a human to
read/understand anything about header fields.
Having reviewed the proposals again, it seems like anything that actively makes
replays harder without adding additional indirect mail flow failures amounts to
a plan to document the flow of the email to provide additional signal for
receivers to understand what's been replayed versus what's a normal indirect
flow.
Side thought: it occurs to me that any solution that relates to
understanding the path is already addressed by a trivial extension to
ARC, in particular that its headers are sufficiently uniform to be
machine-readable, contain the information required to understand
important information about the path (although not the Received:
headers), and are cryptographically attestable. The required extension
would simply be for forwarders performing non-DKIM-damaging forwarding
to also perform ARC-sealing in order to present reliable information
about the path to receivers. Putting forwarders in the position of
benefiting from implementing ARC (or suffering more from not doing so)
is not ideal but (a) the number who do so at scale is small and getting
smaller, and (b) it doesn't create any dilemmas (vs. e.g. deciding
whether to modify messages in a way which breaks DKIM). This doesn't
need a WG; forwarders are free to do it and receivers are free to rely
on it today.
I'm inclined to think that instead of specifying specific drafts to consider,
the charter should point to the problem statement draft instead.
+1
I get the desire to limit the scope, but limiting the outcomes is the
wrong way to do it.
- Roland
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
