ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request

2010-08-10 10:04:01
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

<Prev in Thread] Current Thread [Next in Thread>