On 1/26/25 3:20 AM, Bron Gondwana wrote:
I'm asking about the propriety of making changes to the overall email
architecture in a working group that isn't the appropriate place to do
so. Kitchen sink specifications are not a good thing.
Do you propose that:
a) the work happen somewhere else
b) that it not happen
c) that it be split up into pieces, or
d) something else?
If it has nothing to do with email authentication tech, (a). Part of the
divide and conquer of working groups is getting the right eyeballs on
the right problems. Working on something that's not core to the
technology that's being worked on in a working group (authentication)
seems like it would be better off in a more appropriate venue.
I'm quite concerned by the amount of "NO" energy that this effort is
receiving, and it's a general risk with an organisation that has been
around for as long as the IETF. Everyone wants to have an opinion on
every technology they have touched. Fair enough. But eventually
everything gets mired in molasses and you can't progress any more.
I'm fine with "I don't want to be involved in this"... but there's
real demand for this work. I wish I'd arrived at the IETF before ARC
was published because there would have been a chance to fix ARC rather
than
ARC is precisely why I will remain skeptical, and the implosion last
year of trying to solve the so-called replay problem doesn't give me
much confidence either that much if anything has changed. The idea of
comprehensively tracking mutations that happen from mailing lists is
interesting to me though, but that requires either no changes to the
core DKIM mechanism, or minimal changes done correctly. The idea that we
should cavalierly throw away 20 years of experience to reinvent wheels
doesn't inspire much confidence either. STD's are rare in IETF for a reason.
There is another serious structural problem which is that nobody in the
mailbox community wants to talk about their operational experience and
the way they use DKIM so those of on the outside are blind. It makes it
really hard to evaluate proposed changes and ARC if nothing else proves
"trust me" is not enough.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
