J.D. Falk wrote:
On Mar 31, 2011, at 8:51 AM, Al Iverson wrote:
I think the MLM document makes all of this stuff pretty clear already.
It does to me; it seems like dropping the original signature and
signing with the list manager site signature is the appropriate way to
go.
Yup. The problem isn't that we haven't made this advice public (though
it may carry more weight after last call.) The problem is that it takes a
long time for these ideas to disseminate to all list software deployed
everywhere -- especially the outdated versions of MailMan that many sites
run on autopilot.
FWIW, here's how I got DKIM signatures on messages resent by the lists
I host with MailMan two years ago, without needing to wait for MailMan
to update anything at all:
http://www.circleid.com/posts/dkim_for_discussion_lists/
This is cool J.D.
The DKIM integration for our MLS was very simple and the outline I
provided in DSAP (ideas covered in MLM as well) was written with the
idea for a minimal software design, no failure points promoted by the
changes and simply plug and play with existing software. It had only
two MLS change considerations:
- Restrict POLICY restricted domains as part of the list subscription
process. At the time DSAP was written, this meant disallow
subscription
for a domain using an exclusive signing practice which included a
3rd party signing restriction. If the policy allowed 3rd party
signers
to exist, then the user was allowed to join the list.
- If mail changes will be done, strip old signatures and resign the
message before redistribution.
We finally added this logic last year and the only MLS change was to
add the subscription logic because we designed the framework for
signing is done on the outbound MTA server.
The big change item I originally expected would need to be done in the
MLS adding new DKIM signing options per list turned out to be
unnecessary. We avoided this big software by using the common list
template file used to add additional headers such as all the LIST-*
headers. I used a META header to trigger when a list should be signed.
For example, the template file has:
List-Id: {LT} <{LN}.{LD}>
List-Post: <mailto:{LE}>
List-Unsubscribe: <mailto:{LN}-unsubscribe@{LD}>
List-Subscribe: <mailto:{LN}-subscribe@{LD}>
List-Help: <mailto:{CN}@{LD}?body=help>
WCLS-Signthis: {LD}
So the MLS will do its normal thing of preparing a list distribution,
adding the list-* headers carrying the meta header WLCS-SIGNTHIS:
expanded with the list domain. When the outbound MTA gets this
internal feed, it looks for this meta header, extracts the
list-domain, checks another setup file to signing options for the
list-domain, if any. If found, any header striping options are
followed and the list message message is signed.
So I guess the point is that you can make a MLS DKIM aware by using
meta headers to current setup files and using that information as feed
for edge software.
-
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html