On 14/11/22 20:38, Murray S. Kucherawy wrote:
On Mon, Nov 14, 2022 at 12:26 AM Scott Kitterman
<skl...@kitterman.com> wrote:
Is compatibility with DKIM sufficient for the charter or should
there be
broader language about compatibility with existing email
architecture? I'm
inclined to say "Yes", but I'm unsure about wording.
I also assume "Yes". I'm having a hard time seeing a charter that
allows broad disruption just to solve this problem.
I would even suggest we don't have to say so, but it's probably a good
idea to mention it.
Even if this seems too obvious to mention in a charter usually, I'd
suggest that the fact at least one architecture-breaking approach is
already being discussed points to the desirability of the charter taking
a specific position on this. Part of the charter's purpose is to help
ensure that all participants have the same understanding of the scope.
Similarly, at least one of them could lead to normal indirect mail
flows being
identified as replay attacks. Is something specific needed about
being
compatible with existing email deployments more generally (beyond
DKIM
deployment compatibility) needed? Once agian, I'd say "Yes", but
am not sure
how to word it.
I would say this falls under "don't allow for false positives"; I'm
not sure a charter needs to say something about that though.
I suspect that this is more difficult, as we're likely to end up
adopting solutions that are generally not going to cause false-positives
but will do so in corner cases. It's likely to be necessary to be
specific about the trade-offs that are being made.
(To the extent that we are successful in identifying harm-free solutions
this question will not arise; the question here is about what to do with
solutions that are useful but cause non-zero harm.)
- Roland
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
