-----Original Message-----
From: John Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Friday, August 06, 2010 7:21 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] draft-ietf-dkim-mailinglists-01 review request
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"?
Sec 3.3 "the addition of some list-specific text to the top or bottom
of
the message body." -> "modification of the message body." Lists do a
lot more than add tag lines, as described in subsequent paragraphs.
Done.
under Minor body changes: "pose an immediate problem" -> "will probably
cause
any existing signatures not to verify." Broken signatures are
not a
problem.
Done.
under Major body changes: delete "with little or no hope of
compensation by either the signer or the verifier." There's no
such thing as compensation beyond relaxed canonicanization,
which isn't relevant here
Done.
after "human list manager" add "who hand-edits messages" (that would be
me)
Already changed based on other feedback to:
"... whose workings in preparing a message for distribution could include the
above or even some other changes."
next pp starting "In general", change first sentence to:
In general, an MLM subscriber cannot expect signatures applied
before
the message was processed by the MLM to be valid.
OK.
Sec 3.4 2nd pp: delete sentence starting "The shortest path"
Personally, I
think the shortest path is for the MLM's MTA to sign its outgoing
mail, but I don't think we have consensus either way, so just take
it out.
OK.
Last pp in 3.4: even if there were a new header, few MUAs would
interpret
it. Suggest taking out "Rather than ... purpose" since it's not a
realistic alternative.
OK.
Section 4.1: There's no reason not to sign all the mail you send to a
list.
Even if the MLM breaks the signature, the MLM itself can use the
signature when deciding how to handle the message. The implication
in the first paragraph that a broken signature is worse than no
signature is just wrong according to 4871.
The text now reads, based on other feedback:
"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.
The whole point of this draft is to talk about these things about which the
general public has little understanding. There's a lot of collective
subconscious out there that has equated "bad signature" to "bad message", and
perhaps reasonably so. I think it's better to discuss it in this quasi-BCP
than pretend it's not there and expect everyone to figure it out.
Also, [ADSP] says in
Appendix B not to send mail to lists from discardable domains. So
I suggest replacing the first paragraph with a sentence or two
encouraging people to sign mail sent to lists the same way they
sign mail to anyone else. In the second pp, change "If this is
cause
for concern" to "For domains that publish strict ADSP policies"
Done.
Section 4.2: channelling Dave, standards shouldn't suggest heuristics.
So change the second sentence to something like "Sites whose users
subscribe to non-participating MLMs should be prepared for
legitimate mail to arrive with no valid signature, just as it
always has in the absence of DKIM."
OK.
Section 4.3: I'd just delete it. The second pp is OK, but people using
DKIM are supposed to know that already, aren't they?
I think part of the point of this document is to walk people through some of
the thought processes even if they're clearly the wrong ones. And to some
degree some of the audience of this draft is people who aren't yet using DKIM,
but want to or think they should.
Section 5.1: I'd strengthen it to say that since people aren't
supposed to send mail to lists from discardable domains in the
first place, lists should reject it or perhaps (for people who've
already subscribed so you know it's not spam blowback) drop the
message
and send back a note explaining why.
Let me know what you think of -02 when it comes out. I think it gives a better
treatment.
Section 5.2, second pp: I don't understand the point of creating a
separate signing domain for mail you send to lists. Why would the
reputation of mail that people send to lists be better or worse
than
mail they send anywhere else? It's the same people, I don't see
the
point of a separate mailstream. ADSP isn't a good reason, since
it says not to use discardable for domains with human senders.
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.
In Section 5.4, either delete it or add a sentence at the front that
says THE ADVICE IN THIS SECTION IS SOLELY INTENDED TO WORK AROUND
BRAIN DAMAGE IN FILTERS THAT DO NOT IMPLEMENT DKIM ACCORDING TO THE
SPECIFICATIONS.
(Well, adding an A-R header isn't, but removing signatures that
might be broken sure is.)
Minus the caps, I've added a note to indicate something about that.
In Section 5,5, add a ref to [ADSP] Appendix B.5 which says not to
send discardable mail to lists.
Done.
In Section 5.6, first pp: add a sentence noting that recipient system
will likely use the MLM's signature to recognize list mail and
develop a (presumably good) reputation for the list itself.
Done.
In Section 5.7 add to the end "if senders misuse ADSP" or the like.
OK.
Section 5.9, second pp: change to
Receivers are advised to ignore Authentication-Results
header fields that are not signed by a credible signer.
(Bad guys can sign fake A-R headers.)
OK.
Section 5.9, third pp: if a message fails "discardable" the receiver
should discard it, not reject it. This avoids the bouncing off the
list problem, and you're just following orders -- they said it was
discardable, after all.
I've added a paragraph that specifically discusses "discardable". The
paragraph you cited was meant to talk about "all", where the receiver has more
discretion (via ambiguity) about what to do.
Sections 6, 7, 8, and 9 are flawless.
Excellent!
PS: If I didn't say so before, thanks for all the work you've put into
this.
My pleasure! Thanks for the feedback!
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html