On 2/2/23 3:18 PM, Tim Wicinski wrote:
the problem statement should just bang out the problems in all their
ugly glory.
it should not attempt to suggest solutions, as that would be up to the
working group
to hammer out.
(this is my opinion and of course am probably totally off base)
I guess my concern is more along the lines of what solutions *aren't*.
There are a bunch of drafts trying to tie the envelope to the email and
I think there needs to be a meta discussion of whether that is a good
idea or not in general. Frankly that seems like an email architecture
question not just a DKIM question. It would be nice to know if there is
precedent for that in the larger community and what the implications
are. Fwiw, I don't really consider the DMARC "alignment" as tickling the
larger question because all it is doing is reporting on it, but a case
could certainly be made that it is.
Mike
On Thu, Feb 2, 2023 at 5:32 PM Michael Thomas <[email protected]> wrote:
On 2/2/23 2:16 PM, Tim Wicinski wrote:
On Thu, Feb 2, 2023 at 5:07 PM Michael Thomas <[email protected]> wrote:
So here is what sticks in my craw. I think I brought up the
problem
statement, but maybe somebody else did before me. It's easy
to say "here
is the problem, fix it!" without any context to what any
proposed fixes
might break. It would be really bad imo to slap out a minimal
problem
statement and then proceed to solutions without any analysis
of what any
solution space should and should not do at a protocol level.
I guess
that's a little bit more requirement-y, but I'm not exactly
sure what
process-wise I'm asking for. DKIM is extremely widely
deployed so we
need to be really careful about not breaking existing
practices or doing
unnatural acts that have implications to the wider email
community.
My feeling part of the problem statement will be to document
various solutions
and how testing should be done and what to look for (breaking
existing practice would
be key).
It may be that one solution is protocol rev which works outside
of current dkim.
We wrestled with this in the early days of DPRIVE - adding
additional encryption onto
DNS was viewed in a similar manner.
I don't know if there is a formal IETF definitely of what
constitutes a problem statement but it's easy to imagine a problem
statement that... just states the problem. I don't think we have
discussed what should actually be in scope for this problem
statement. I guess we could suss that out before there are chairs,
but obviously we'd need them to make consensus calls.
Mike
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
