Closed Bug 131327 Opened 18 years ago Closed 10 years ago

UUencode detecting heuristics have nasty false positive


(MailNews Core :: Networking: NNTP, defect, P4)



(Not tracked)



(Reporter: donald, Unassigned)




(Whiteboard: closeme 2010-04-01)


(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020310
BuildID:    2002031008

When browsing the message referred to above using Mozilla's MailNews component,
the entire body was detected by Mozilla as an attachment with the filename
"".  More stringent checks that the potential
attachment is valid (all lines conform to the UUencode character set, existence
of the CRLF "end" CRLF terminator) should be applied before labeling something
as an attachment.

The bug is NOT reproducable either by receiving similarly formatted e-mail or by
saving similarly formatted text as a draft and viewing it.  The bug IS
reproducable when the "Copy To ->" feature is used to copy the message to a
local folder and then viewed.

Reproducible: Always
Steps to Reproduce:
1. Compose a new Usenet message in any news client.
2. Add any line that matches the regexp "^begin [0-7]{3} +.+$"
3. Post the message using NNTP.
4. View the posted message in Mozilla using NNTP.

Actual Results:  All text subsequent to the false "begin nnn ..." line is
swallowed up and turned into an attachment, typically containing binary garbage.

Expected Results:  The false "begin nnn ..." line and all subsequent lines
should remain as part of the body unless Mozilla can validate that the
attachment is a strictly valid uuencoded file.  A user can always do a
File->Save As and manually decode it with external software if the attachment is
really that important.

The only known workarounds are (A) to do a View->Message Source, or (B) to do a
File->Save As and open the message in an external text editor.  The latter is
extraordinarily inconvenient, and the former would not be obvious to a novice.
Confirming.  Thanks for this _excellent_ bug report, Donald.  Jean-Francois, can
you take a look at this, thanks!  I saw this with 2002-03-21-08, Windows 2000.

Ever confirmed: true
OS: Linux → All
Hardware: PC → All
This bug has two duplicates, which are not marked as such:

bug 142992 "handling of inline uuencoded files behaves badly"
bug 161253 "news article display with bogus uuencode header broken"

Microsoft Outlook Express is also broken in this respect, for discussion see:;EN-US;q265230
I also saw this bug in my 2--2121607 build
This works for me in Mozilla 1.4a (never bothered to upgrade because I now use
Closed: 16 years ago
Resolution: --- → WORKSFORME
Yet reports have been posted in nl.newsgroups by several people that this bug is
not resolved, even in 1.5
Strange that you do not have this problem Erik...

Bit premature to set the status to worksforme maybe?
Reopening because of new test case.

The regex given by the reporter does not trigger the bug. You have to have four
digits before the bug kicks in.

Eg, this is not detected as an attachment:

begin 777 test.txt

but this is:

begin 2777 test.txt
Priority: -- → P4
Resolution: WORKSFORME → ---
*** Bug 142992 has been marked as a duplicate of this bug. ***
*** Bug 161253 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend →
Product: Core → MailNews Core
Has anyone been bit by this bug in recent months?
Whiteboard: closeme 2010-04-01
RESOLVED INCOMPLETE due to lack of response to last question. If you feel this change was made in error, please respond to this bug with your reasons why.
Closed: 16 years ago10 years ago
Resolution: --- → INCOMPLETE
Depends on: 1313986
You need to log in before you can comment on or make changes to this bug.