Marco De Rossi wrote:
Marco De Rossi wrote:
We use X.509 certificate.
Could I send to the list a little attachment to see if problem is present
with mailman-users mailing list too?
The message you sent has a PKCS7 (RFC 2315) signature. Of course, the
signature was broken by the mailman-users list because content
filtering removed one of the signed parts.
For the specific issue of your lists, here's what I think, but I'm not
at all knowledgable about PKCS7, so I'm not sure.
I skimmed over RFC 2315 and also looked at the message structure. The
original message has
The content consists of a
part and a
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
part. The multipart/mixed part consists of a text/plain part and an
Such a message structure with a Open PGP/MIME signature rather than a
PKCS7 signature can pass through a Mailman list without breaking the
signature as long as the list does no content filtering and doesn't
add any list header or footer. Depending on the client verifying the
signature, even the addition of a list header or footer may not break
the signature (actually, the signature doesn't break, but clients may
refuse to recognize the message as signed if the multipart/signed
content is not the top level of the message).
In your case, I would expect the message could also pass through a
Mailman list with no content filtering and no added list header or
footer without breaking the signature, and in fact you said it does if
the message originates from a Linux system.
So the question is, what is different about the Windows system that
results in Mailman's breaking the signature.
I see the following in RFC 2315 section 9 step 1.
1. For each signer, a message digest is computed on
the content with a signer-specific message-digest
algorithm. (If two signers employ the same message-digest
algorithm, then the message digest need be computed for
only one of them.) If the signer is authenticating any
information other than the content (see Section 9.2), the
message digest of the content and the other information are
digested with the signer's message digest algorithm, and
the result becomes the "message digest."
This says to me that the "message digest" which is signed can
optionally include some message headers which may be altered by
Mailman - e.g., perhaps a Subject: which has a prefix added - thus,
breaking the signature.
Or, possibly the Windows client is doing some unorthodox treatment of
trailing whitespace in the message content, but this seems unlikely if
the signatures normally validate.
Thus, you could try making the list's subject_prefix empty and see if
that helps, or better still, if you can set the Windows clients to
sign only the content and not any headers, try that.
Mark Sapiro <msapiro at value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan