I've trimmed out all the places where we agree, so this one is mercifully
short.
Sec 3.2 2nd pp on page 9: "most direct conflict operationally with
DKIM" ->
"widest range of possible interactions with DKIM" or something like
that.
I don't see any confict at all.
Well the point is to address the fact that a lot of MLM actions disrupt DKIM
signature validation. Maybe "conflict" is too strong a word, but
"interactions" feels too soft as well. "Friction" feels like the right
ballpark, but sounds too negative. How about "foil", "thwart" or "frustrate"?
Nope. Those all imply that it's important for recipients to validate
the contributors' signatures, which it's not. They really do have the
widest range of interactions, the most complex signup processes, the
mst complex techniques for deciding what to accept, and the most
varied modifications to the messages.
"If an author knows that the MLM to which a message is being sent is a
non-participating resending MLM, the author is advised to be cautious when
deciding whether or not to send to the list when that mail would be signed."
This takes the signing decision away from the user, which I think resolves
your concern.
But for the sake of discussion: I don't think the broken signature is worse
and I know you don't think that, but we've encountered implementations that
do. I think it's reasonable for this document to acknowledge that this
(incorrect) choice has been made and exists out there, and sometimes we'll
have to deal with it.
In general, I think it's better to tell people to fix their bugs than to
encoourage the rest of the world to work around them. If the point is
that you may experience trouble delivering to systems with flawed DKIM
code that erroneously penalizes broken signatures, why not just say that,
and make it clear where the fault lies?
I believe the thinking was: This stream of mail from me might get mangled, or
associated with traffic over which I have no control (and get munged in with
the reputations of people on mailing lists to which I subscribe), so I might
want to keep those separate.
Seems awfully convoluted, but again, if that's the thinking, better to
say that.
PS: If I didn't say so before, thanks for all the work you've put into
this.
My pleasure! Thanks for the feedback!
Thanks again. Looking forward to the next round.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html