Grant Taylor writes:
> I'll agree with you on Mailman's responsibility. However in 10+ years
> of computer work I can assure you that there is quite a bit of software
> out there that /claims/ to do something but falls short of that claim. ;)
Sure. Why Mailman *should* make up for other s
On 01/20/09 03:46, Stephen J. Turnbull wrote:
This isn't really relevant to Mailman, though. MIME messages are by
design recursively structured, and MUAs that claim to support S/MIME
should be able to handle recursive structure. The only
responsibility Mailman has or should accept is to encap
Grant Taylor writes:
> On 1/19/2009 10:19 PM, Taylor, Grant wrote:
> > I will play with forwarding an S/MIME signed / encrypted message and
> > let you know what my MUAs (of choice) do with the message/rfc822 MIME
> > body part.
This isn't really relevant to Mailman, though. MIME messages a
On 1/19/2009 10:19 PM, Taylor, Grant wrote:
I will play with forwarding an S/MIME signed / encrypted message and
let you know what my MUAs (of choice) do with the message/rfc822 MIME
body part.
I just sent my self an S/MIME signed message and then forwarded it as an
attachment (message/rfc82
On 01/16/2009 08:40 PM, Mark Sapiro wrote:
Note that just sticking the header and footer as additional parts
into an original multipart, not_mixed message can't be arbitrarily
done. Clearly, if the original is multipart/alternative, this won't
work and if it is multipart/signed, it would probab
On 01/16/2009 04:43 PM, Brad Knowles wrote:
I don't think it broke the signature, I think what happened is that it
hasn't been encapsulated in the correct manner.
*nod*
At the very least, you can do a message/rfc822 bodypart, and that should
guarantee that the signature is not broken, assumin
Barry Finkel wrote:
>
>Note that Mailman has taken the existing three-part MIME structure
>(plain-text body, HTML-formatted body, and digital signature) and
>instead of placing the list footer as a fourth part in the same MIME
>structure, Mailman has created a new two-part MIME structure with
>the
Grant Taylor wrote:
Don't change anything at all in any of the signed/encrypted part, just
treat it as an opaque object and encapsulate the whole thing.
It sounded like that is what Mailman already did and that by doing so
broke the signature.
I don't think it broke the signature, I think w
On 01/16/09 16:27, Brad Knowles wrote:
Validation could be useful, but the more important issue is to have
Mailman completely encapsulate signed/encrypted messages and then add
whatever additional MIME bodyparts may be necessary to complete the
other parts of the work it has been configured to
Grant Taylor wrote:
I think the more proper thing would be for something (Mailman or it's
MTA interface / handler) to validate S/MIME signed messages and process
them before passing them on.
Validation could be useful, but the more important issue is to have Mailman
completely encapsulate si
On 01/16/09 15:46, Barry Finkel wrote:
Note that Mailman has taken the existing three-part MIME structure
(plain-text body, HTML-formatted body, and digital signature) and
instead of placing the list footer as a fourth part in the same MIME
structure, Mailman has created a new two-part MIME str
I have a collegue who is experimenting with signed mail (S/MIME).
He sent me a test mail and he also sent it to a test Mailman (2.1.11)
list. Here is the basic MIME header structure for the mail sent
directly to me:
++
MIME-Version:
12 matches
Mail list logo