Greg Troxel writes:

> The inner test message had boundary =-=-= originally.  That got remapped
> whent he message was forwarded, which I suppose is ok.

Yeah, Gnus is a bit eager with regenerating MIME (you can tame it using
message-forward-show-mml).

> But it got remaped to ===-=-= and that's the same value that was
> chosen for the outer message's multipart/signed.
[...]
> It looks like the key code is in mml.el in gnus, but I haven't
> understood it yet.

My analysis so far:

(a) mml-multipart-number is let-bound on recursive descend of
    mml-generate-mime.  So mml-compute-boundary potentially generates
    duplicate delimiters unless the collision test prevents it.

(b) The collision test code doesn't look at the content of
    message/rfc822 [#mml] handles.

(c) If it would look at them, it wouldn't note a collision generated by
    (a) since the handle still contains the untranslated
    [#multipart]-tags instead of MIME.

I think (b) needs to be fixed anyway because a collision could occur
independently of (a).  Now either fixing (a) or (c) should prevent the
generation of broken MIME.  I guess squishing the bug the (b) + (c) way
is more adequate since it's less invasive.  Will push in a jiffy.

Thanks for your elaborate report,
andreas