[Mailman-Developers] dkim-signature headers

[Joe Peterson]

I really do not think that a From address should be changed.  This is
where "Sender" comes in (and Sender is more "behind the scenes" and less
important to the end user).  So what Mailman does not, I believe, is
correct: keep From set to the person who sent the email and set Sender
to reflect that the mail list is the sender.

I also do agree with Barry that the responsible party for an email from
a mailing list should be the mail list and not the original person who
sent it.  If you are subscribed to a mailing list, you need to be able
to verify that the message indeed came from the list itself (and you can
do this if the mail list host adds its own DKIM sig).  Ideally, the mail
list host would do the initial DKIM check from the original person
sending the message and mark the header to reflect that it passed, and
then the receiver's host can check the DKIM sig from the mail list.
This "chain" of verification would be sufficient to verify the message
itself.

Now, what about the original DKIM sig...?  If left in the header, the
end receiver might try to check it and get a bad match, even if the
newer sig added by the mail list would verify.  Yeah, I know that a "bad
sig is like no sig", but this just seems ugly.  Then there's the
additional problem of the milter not re-signing if there exists a sig
already (these were the two motivations for cleansing the sigs from the
mail in Mailman).

Bottom line is that if we let the system do two separate DKIM checks
(orig sender -> mail list, and then mail list -> receiver), it avoids
all the issues of changes made to the message.  Somehow this seems more
clean to me.

					-Joe


Michael Thomas wrote:
> Barry Warsaw wrote:
>> I'm not sure how much I like that anyway, so comments are definitely 
>> welcome.  After mulling over this post for an hour ;) I'm starting to 
>> believe that it's the mailing list system that needs to vouch for the 
>> messages its recipients receive.  Of course, it could be Mailman doing 
>> the DKIM signing, or it could be Mailman's outgoing MTA, etc.  But, 
>> ISTM Mailman is ultimately deciding what goes into the list copy, so 
>> it is responsible for it.
> 
> The big problem with the way that mailing lists interact is that in some
> scenarios they're not terribly different from a .forward file, and in other
> cases they for all intents and purposes completely originating a completely
> new message, cf translators, digestors, etc, etc. The _problems_ arise when
> the mailing list keeps the 822.From address intact from the original 
> submitter.
> For things like digests it pretty much does the right thing: it sets the 
> 2822.From
> to be something related to the list. For normal list traffic it keeps 
> the original
> 2822.From.
> 
> What it seems to me is that maybe we should look close at that behavior of
> when a list ought to take From: responsibility for a message ala 
> digests. When
> a list completely mangles a message, is it really reasonable for it to 
> keep acting
> as if it came from the original From: address? There's probably not a 
> bright line
> here, but maybe we should force the issue with DKIM in that something that
> mangles a message in a way that it's impossible to have the original 
> signature
> survive to... set the From: address to something list related so that 
> it's the lists
> reputation that's considered rather than getting caught up in no-man's 
> land of
> "it looks like a forgery because we/they sign all mail, but..."
> 
>        Mike
>