> Mime-Version: 1.0

Looks odd, usually it's "MIME-Version".
Not that it should matter.
And it could be gmane that's altering it.


> Archived-At: <http://permalink.gmane.org/gmane.comp.emulators.wine.patches/21235>

Which means that it's also available at:
http://article.gmane.org/gmane.comp.emulators.wine.patches/21235

So it's not really missing from gmane, or?


Anyway, the MIME structure of the email is:

body: multipart/mixed
      |
      +-- multipart/signed
      |   |
      |   +-- multipart/mixed
      |   |   |
      |   |   +-- text/plain                       (Jonathan's mail)
      |   |   |
      |   |   +-- text/x-patch [attachment]        (Jonathan's patch)
      |   |
      |   +-- section: application/pgp-signature   (Jonathan's pgp sig)
      |
      +-- text/plain                               (blank text/plain?!)


So looking at the inner multipart/mixed, it contains a "text/plain" which is Jonathan's bread text, and a "text/x-patch" with an attachment flag, which is obviously his attachment.

But if you take a look at the outer multipart/mixed, there's a multipart/signed and then there's a completely blank text/plain section:

> --===============0121623449==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
>
>
> --===============0121623449==--

Which makes no sense to me at all.

If I were writing a mail parser, I'd have serious trouble choosing what to do with this kind of c... too :-).

I think I'd choose to merge all the text/plain sections (without attachment flags) into a single entity and consider that the bread text.

Pipermail seems to choose to pick the first text/plain section, the outer one (which happens to be empty) and just use that.
And then scrub that other multipart/signed part, who needs that anyway.
Right?