[ mailman-Patches-1287546 ] Remove DomainKeys (and similar) header lines

SourceForge.net noreply at sourceforge.net
Sun Dec 18 13:42:42 CET 2005 

Patches item #1287546, was opened at 2005-09-11 10:08
Message generated for change (Comment added) made by markonen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: Mailman 2.1
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Joe Peterson (skyrush)
Assigned to: Nobody/Anonymous (nobody)
Summary: Remove DomainKeys (and similar) header lines

Initial Comment:
This simple patch removes the header lines containing
keys used in DomainKeys (Yahoo) and DKIM.  The keys, if
left in the header, will make the email seem forged or
altered to the recipient, since Mailman alters
header/body info.  If the keys are removed, the MTA
will generate new keys (if this is installed on the host).

-Joe


----------------------------------------------------------------------

Comment By: Marko Karppinen (markonen)
Date: 2005-12-18 14:42

Message:
Logged In: YES 
user_id=1406492

Yup, I have DomainKeys working with Mailman. Here's an example 
DomainKeys header of a message that passed through Mailman just fine:

DomainKey-Signature: a=rsa-sha1; s=mail; d=karppinen.fi; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:content-type:message-id:
	content-transfer-encoding:from:subject:date:to:x-mailer;
	b=Jjt8k25KetlHzapxG93zNgC5WmN9UedMi
+WrlZGLW2WDhk72WWvj63xM/
LJIZHvx2heeMbm0gxgMdZ8MuUXn8bRIB0STCLEALHBP4Oq2kbDZpcPTweLIxsL
iH1h6I123ekPNTsB0LPPzDDlfPBjbHMcCekBiTtF+VcNu2HCbLhs=

As you can see, it's possible to add headers like Reply-To without breaking 
the signature. (The choice of headers to sign in the original message is 
largely up to the implementation. I have a feeling that the implementations 
that sign only the absolutely necessary headers will survive better in the 
marketplace.)

I think enterprises will adopt DKIM for the anti-spoofing benefits without 
much concern for things like their employees' participation on mailing lists 
external to the organization. In such a scenario, it's the mailing lists' 
responsibility to try and ensure that people from such protected domains can 
still participate.

Anyway, thanks for looking into this!

----------------------------------------------------------------------

Comment By: Joe Peterson (skyrush)
Date: 2005-12-17 20:51

Message:
Logged In: YES 
user_id=738814

If it's possible to have Mailman pass the message and header
through in a way that does not impact DKIM/DomainKeys,
that's certainly an interesting idea.  I wonder, though, if
header changes required when a message is forwarded via a
mailing list would always be compatible.  Anyway, this as an
option is certainly worth exploring.

Because of things like mailing lists, I do wonder if things
like DKIM and DomainKeys (and even more so SPF - I cannot
believe there as been as much adoption as there has been of
SPF!) will ever be viable.  It seems that to get the
benefit, one would need to set up strict policies, but then
one risks losing mail through mailing lists, etc.


----------------------------------------------------------------------

Comment By: Marko Karppinen (markonen)
Date: 2005-12-16 21:23

Message:
Logged In: YES 
user_id=1406492

I'm currently using mailman 2.1.2, and with it, DomainKeys works OK for 
plain text messages if we disable any subject mangling, list footers etc. It 
doesn't work with attachments, but I've understood that this is because of 
some MIME mangling bugs that have since been fixed.

So, I was looking forward to the case 1) working fully (even with attachments) 
with a current mailman version, but this patch will apparently prevent that.

DomainKeys is, of course, more brittle than unprotected email, but I think its 
impact on intermediate systems is much smaller than with SPF or Sender-ID. 
Mail forwarders only have to forward messages as-is, not do any SPF-specific 
path mangling magic.

I don't deny that removing the DomainKeys headers is a useful option to 
have, however -- but I think it should be an option. (Alternatively, we could 
look at this from the other direction and make the "don't touch anything" an 
option. i.e. have a single master switch that would turn off subject and body 
mangling and preserve DomainKeys headers as-is. S/MIME is the other 
important use case for this.)

----------------------------------------------------------------------

Comment By: Joe Peterson (skyrush)
Date: 2005-12-16 19:01

Message:
Logged In: YES 
user_id=738814

Markonen,

I agree that the whole DKIM/DomainKeys issue is a bit of a
mess.  It makes me wonder about the future of such email
verification schemes.  It seems that any mail list mechanism
has the potential for breaking them.

As to your concern, I believe we are OK in that #2 already
happens.  Mailman adds a "Sender:" header line, and
DKIM/DomainKeys will use this as the source domain to
determine if signing is expected, etc.  So if the sender
host re-signs the email, things should be OK.  The problem
here, of course, is that the receiver will only know that
the email came from the mail list host - not that the
original email came from the original author - less than
ideal.  I was enthusiastic about DKIM, but I am a little
less so now due to these shortcomings.

Your #1 is probably not possible, since I doubt we could
expect Mailman to never modify body/headers...  right?

-Joe


----------------------------------------------------------------------

Comment By: Marko Karppinen (markonen)
Date: 2005-12-16 17:16

Message:
Logged In: YES 
user_id=1406492

I think this is problematic. For intra-organizational lists, removing the 
DomainKeys header works as advertised. However, if a person from a 
DomainKeys-enabled domain posts onto an external list, there is a potential 
for error.

If the sender's domain's DomainKeys settings specify that the domain does 
not send unsigned mail, external MTAs can and will drop an email from that 
domain if the DomainKeys headers are removed.

To make DomainKeys work with mailman as expected, admins have two 
possibilities:
1) Deliver the message as-is, without modifying the Subject header or 
message body (or any header indicated to be signed). The original 
DomainKeys signature will then work.
2) If modifying the message is necessary, the mailing list will have to rewrite 
the From: header in order not to claim that the message originated in the 
DomainKeys -protected sender domain.

Removing the DomainKeys header will only be relevant in the case 2) above. 
For 1) -- the preferred solution for many lists -- it is actively harmful. 
Therefore, automatically removing the DomainKeys header is NOT the way to 
go.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-13 00:59

Message:
Logged In: YES 
user_id=12800

Applied to both Mailman 2.1 branch and trunk (2.2)


----------------------------------------------------------------------

Comment By: Joe Peterson (skyrush)
Date: 2005-09-11 10:09

Message:
Logged In: YES 
user_id=738814

Attached is the patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287546&group_id=103

More information about the Mailman-coders mailing list