Molle Bestefich wrote:
Tony Lambregts wrote:
attached is the message source that I got throught gmane news server.
Thanks.
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...)
Oh, ok.
------------------------------------------------------------------------
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
I missed that, cool.. it archived it with a .bin extention even though I
could open it in gedit fine.
Now the question remains (now that we know it is archived) how do would
one actually find it
http://search.gmane.org/
As a matter of fact I could not find any reference to your post or mine
in this thread
http://search.gmane.org/?query=&email=tony.lambregts%40gmail.com&group=gmane.comp.emulators.wine.devel&sort=date&DEFAULTOP=and&xFILTERS=Gcomp.emulators.wine.devel-Amolle.bestefich%40gmail.com---A
Something to talk to Gmane about?
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?
Is it Jonathan's mailer or gmane that does this???
At this point I am happy that it is archived somewhere at least.
--
Tony Lambregts
