Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
molle.bestefich at gmail.com
Sat Jan 28 13:34:47 CST 2006
Tony Lambregts wrote:
> attached is the message source that I got throught gmane news server.
gmail seems to like to ruin line endings as much as Outlook does,
so I've attached my reply to preserve the fine ASCII art :-).
Please take a look...
> (I do not get emails from wine patches even though I am subscribed...)
-------------- next part --------------
> 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:
So it's not really missing from gmane, or?
Anyway, the MIME structure of the email is:
| +-- 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:
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
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.
More information about the wine-devel