GNOME Bugzilla – Bug 67554
Misinterpretation of some string as attachment
Last modified: 2004-12-22 21:47:04 UTC
When I put line in post: begin 666 something.txt I see in PAN: Attachment: text/plain - 8bit - lack of file name Attachment: text/plain - 8bit - something.txt (I've translated above from polish). This is Outlook-like bug. Pan should not see attachment, when there's no attachment.
I've confirmed that this happens when there are blank lines above an attachment. Kind of an awkward wart; perhaps Pan could walk through the mime parts and trim out those which are just whitespace.
Fixed in 0.11.90
*** Bug 76358 has been marked as a duplicate of this bug. ***
Reopening, since we regressed on this in later 0.11.9x releases: lines beginning with 'begin <number> <word>' are now displayed as corrupted code. I'll attach an example below. The underlying reason for this regression is related to multi-part binaries: if we're reading the first part and we detect no end marker, we'd fall back to displaying the raw text. For yenc-encoded messages, this filled up the text with a huge chunk of yenc noise. By removing that check for an end marker, we fixed the multi-part problem, but regressed on this bug.
Created attachment 9287 [details] Sample message demonstrating this bug
Note: Christopher Ranschaert <haploc@gmx.net> pointed this out to us.
Since 0.12.9x does show multiparts picture posts, we can add this code back in... anyone care to make a patch from 0.11.90 to 0.12.92? :)
Prioritizing remaining 0.13.0 tasks
*** Bug 91506 has been marked as a duplicate of this bug. ***
Bumped remaining bugs to 0.13.2.
For some reason this is a popular bug to complain about in some newsgroups, so I guess I'll get off my ass and fix it for 0.13.2. :)
Bumped remaining bugs to 0.13.3.
*** Bug 98832 has been marked as a duplicate of this bug. ***
Having looked at this bug some more, I find it hard to believe that something so stupid could be so complex. In order to make uu decoding work in a happy world, anything after the "begin" line that doesn't pass the uu line sniff test is thrown into the bit bucket. so we would really need to rewind back to the beginning of that part and re-run it. Pathological cases with uu begin lines one after another would be troublesome too. Yes I'll fix it, but grumblingly... :) "Doctor, it hurts when I do this."
fixed in cvs for the next release: http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan/base&command=DIFF_FRAMESET&file=util-mime.c&rev1=1.48&rev2=1.49&root=/cvs/gnome http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan&command=DIFF_FRAMESET&file=ANNOUNCE.html&rev1=1.1&rev2=1.2&root=/cvs/gnome I've gone with a lazy fix to just catch the last uu/yenc message in the article. If someone does something nutty like adding two uu begin lines at the top of an article, Pan will probably still get confused. :|