287845 - Spaces in attachment headers get moved around whichs corrupts header

Status: RESOLVED EXPIRED

(Thunderbird :: General, defect)

Description

[PreferToKeep Anonymous]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla Thunderbird version 1.0 (20041206)

I received an uuencoded attachment on an email.  The header was:

begin 666 Cor   pusIndustryUpdateS.pdf

What it should have been:

begin 666 Corpus Industry Update S.pdf

I have seen this same type corruption in yenc headers coming in from newsgroups,
and reported the corruption in a bug that was marked as DUPLICATE (280850).  I
understood the reasons for marking that bug as duplicate, but now that I am
seeing the problem in both uuencode and yenc headers, I am opening a new bug
rather than reopening the old bug.

This type of corruption is not consistent.  Sometimes the spaces get moved
around, and sometimes they don't.  This sort of behavior is particularly
devastating when downloading multi-part messages when some headers are corrupted
and others are not.  Programs like WinZip and yEnc cannot properly recontruct
the multipart messages.

WinZip reports missing parts and won't decode the  message.

yEnc has an even worse problem because of the way spaces get moved around.  On a
multi-part message, it is possible to see the following behavior:

=ybegin par    t=43line=128size=10614832name=BenW.vol036+27.PAR2
=ybegin part=44 line=128 size=10740654 name=Ben W.vol036+27.PAR2

The first one gets decoded to "BenW.vol036+27.PAR2", and is reported as being
corrupt, and the second one gets decoded to "Ben W.vol036+27.PAR2" and is not
reported as corrupt.  However, at the end of decoding all the parts, yEnc
reports that "BenW.vol036+27.PAR2" and "Ben W.vol036+27.PAR2" are incomplete. 
So now I have two files containing various parts of what the reconstructed file
is supposed to be.

I have created workarounds for this problem.  For a file containing an uuencoded
multi-part message, I simply edit the file and correct the filenames (a pain in
the neck...).  For file containing a yEnc multi-part message, I wrote a utility
in perl that corrects the filenames.  (These files come from downloading
messages from newsgroups.)

One thing that I have noticed is that the corruption seems to be fairly
consistent when it does occur.  Either all the spaces in the name field are
relocated in a yEnc or uuencode header, or none of them are.  With the
corruption in the rest of a yEnc header, I cannot say for sure if the all the
spaces get moved or not, but I think there is some consistency in that
corruption as well.

I don't receive many base64 encoded attachments, so I cannot speak to whether
those get corrupted as well.

For the reproducibility, when I say "Sometimes, but not always", I see the
uuencode header corruption less often than the yEnc header corruption, which I
see all the time.  This may be a result of most names being used for uuecoded
data often not having spaces in their names.

Reproducible: Sometimes

Steps to Reproduce:
1. Find a multi-part news article that has a yEnc encoded or uuencoded attachment.
2. Download and save all the parts into a sub-folder.
3. Try to decode the sub-folder file (or simply examine the headers).

Actual Results:  
The headers in the downloaded articles are often corrupted.

Expected Results:  
The headers should not get corrupted.

Comment 1

[PreferToKeep Anonymous]

Attachment: Example of yEnc headers and producing two files

I was incorrect about yEnc reporting corruption on the individual pieces of the
multi-part message.

Comment 2

[PreferToKeep Anonymous]

I need to clarify something about what I mean by the header corruption in
multi-part uuencoded files.

For a given uuencoded file posted in multiple parts, there is only one header
(unlike yenc).

However, things like games are often posted in multiple .rar files (i.e.,
x.part1.rar, x.part2.rar, etc.).

The error you can see if the name has spaces in it is that the various parts
will decode with different names:
    a fun game.part1.rar
    afungame.part2.rar
    afungame.part3.rar
    a fun game.part4.rar
Subsequent decoding will fail.

The error I reported as coming from WinZip ("WinZip reports missing parts and
won't decode the  message.") is a problem with getting all the parts downloaded.
 My apologies.

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.