ietf-dkim
[Top] [All Lists]

Re: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)

2006-01-23 13:09:19

----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>

I didn't find the original mention of this, but I'm not clear on why
adding a mail-list signature would break the original.  It's just an
additional header field, and unless the original signature was
constructed to prevent that (by including DKIM-Signature in the h=
headers) there shouldn't be a problem.  What might break the original
signatures is the modifications to the message that necessitated the
mail-list signature.

Right, so there are 3 designs a LS can take when content modifications
is desired by the list admin:

  - Strip, No Resign  (NEUTRAL, WEAK)
  - Strip, Resign    (NEUTRAL)
  - Resign  (NEUTRAL, STRONG)

Example:

1) An email is submitted to the list from a domain with a WEAK SSP.  The
email is signed by the original domain.  If the LS is intent on content
change, then its only recourse is a STRIP.  If the email was not signed,
then the LS can do what it wants as normal but *not* resign it.

2) An email is submitted to the list from a domain with a NEUTRAL SSP.
The email is signed by the original domain.  If the LS is intent on
content change, then it STRIP and/or RESIGN it. If the email was not
signed, then the LS can do what it wants as normal including resigning
it if it wants.

3) An email is submitted to the list from a domain with a STRONG SSP.
The email is required to be signed by the original domain.  If the LS is
intent on content change, then the LS can only RESIGN it. It can not
strip it.

So the logic is established and consistent with the SSP protocol. The
downlinks verifications will be safe as well.


- Some particular headers may cause difficulty when a
mailing list is re-signing an originally signed message (e.g.
"Reply-To", "Subject").

I didn't get quite this meaning from Frank's message.  I
don't know what the difficulty is;

If the DKIM signature includes the hashing if a Reply-To: header, then
this will cause a problem for "modern LS" that use the Reply-To: as
RFC-ready MUA ergonomic kludge to resolve the issue of "layman" users
who naturally hit the reply button with the intent of replying back to
the list, but inadvertingly send it directly to the author.

So LS offer the options to fix the Reply-To: field as the List Address
and this makes it very easier for users to "naturally" reply back to the
list.  Otherwise, the user has to be aware of clicking "Reply to All"
(like I had to do now) in order to get the list address among the reply
list.  But this causes redundancy with multiple copies, which I really
do not want, but I am too lazy to remove the extra addresss :-)

This is an basically a RFC-ready Mail Reader issue that is "trained" on
a EMAIL vs NEWS concepts where the natural action for the reply button
is:

  EMAIL -> REPLY-TO:, FROM:
  NEWS  -> ALL

Without a Reply-To:, you have to click the unnatural "Reply to All"
button in other to get the list address.

Anyway, if the hash includes a Reply-To: then it breaks this feature
offering of a List Server.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


_______________________________________________
ietf-dkim mailing list
http://dkim.org