Closed Bug 254149 Opened 20 years ago Closed 16 years ago

Bad codification of the 'Receipt Notification' subject

Categories

(MailNews Core :: Localization, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 462725

People

(Reporter: laurent.bauvens, Unassigned)

Details

(Whiteboard: closeme 2008-12-24)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7) Gecko/20040707 Thunderbird/0.7.2

When TB send a (french) receipt notification, it doesn't code the subject with
internationalization page code. So the subject appears in the recipient's mail
list like "? xxxx" (where xxxx is the initial subject). In the mail source, it
appears like 'Subject: =?UNKNOWN?Q?Accus=E9_de_r=E9ception_=28affich=E9=29_-?= 
test'.

Reproducible: Always
Steps to Reproduce:
1.Create a mail from a messaging client other than Mozilla Mail 1.7.1 or TB
0.7.2 with subject is 'TEST'
2.Ask for a receipt notification and send the mail
3.Open the mail in the recipient mailbox with TB 0.7.2 FR and accept the
notification.
4.Return in the initial mailbox to receive the notification

Actual Results:  
Subject displayed: ? TEST
Subject coding: =?UNKNOWN?Q?Accus=E9_de_r=E9ception_=28affich=E9=29_-?=  TEST

Expected Results:  
Subject displayed: Accusé de réception (affiché) - TEST
Subject coding: =?iso-8859-1?Q?Accus=E9?= de =?iso-8859-1?Q?r=E9ception?= (
	=?iso-8859-1?Q?affich=E9?=) - TEST
This also happens with the german version of Thunderbird (1.0).

Subject: Empfangsbestätigung (angezeigt) - 
=?iso-8859-1?Q?Unser_Telefongespr=E4ch_CSB6xx?=

Our mailserver (postfix with amavisd-new) rejects to send the message and returns:

Non-encoded 8-bit data (char E4 hex) in message header 'Subject': Subject:
Empfangsbest\344tigung (angezei...
Summary: Bad codification of the 'Receipt Notification' subject → Bad codification of the 'Receipt Notification' subject
is this a dup? I thought I saw a patch for a bug like this...
I currently use Thunderbird 1.5 RC 2 FR and the bug yet exist.

Return receipt is a often used function in corporate area.

So this function seems only to work well in english version.

Please, could you make this bug solved with the final 1.5 release ?

Thanks
The bug is still affecting TB 1.5.0.9 FR and 1.5.0.10 DE.
In EN and IT versions the problem is not observed.

Please fix this for the release of TB 2. Thanks.
Alessandro, have you tried 2.0? I believe this is fixed in 2.0
To be homest no, because in my production env I only have TB 1.5.x

I will try asap.
I tried with TB version 2 beta 2 (20070116) (french version) and after sending the receipt amavis replied with this undeliverable report:

INVALID CHARACTERS IN HEADER

Non-encoded 8-bit data (char E9 hex) in message header 'Subject'
  Subject: Accus\351 de r\351ception (...
                ^
[cut]


So the bug is still there...
this bug was fixed well after beta 2. You should be able to find a newer build here: 

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-l10n
No way. I tried with just downloaded TB 2.0pre (20070319) (french) and the problem persists.
I noticed that the report is a bit different:

INVALID CHARACTERS IN HEADER

Non-encoded 8-bit data (char C3 hex) in message header 'Subject'
  Subject: Accus\303\251 de r\303\251ception...
                ^
Weird, in bug 335534, someone said this was fixed for them with a nightly 2.0 build. See https://bugzilla.mozilla.org/show_bug.cgi?id=335534#c15

It sure looks like you're running a build w/o the fix since the header is not mime2 encoded at all.
I've posted a comment to bug 335534
https://bugzilla.mozilla.org/show_bug.cgi?id=335534#c16
that is marked as RESOLVED FIXED.
Probably the bug fix the issue concerning RFC 2047, but this is not enough.
I don't know how it works in this case: is there any chance that the bug will be opened again?

Unfortunately I don't have time to read involved RFCs, but I am available to do whatever needed to help in fixing this annoyance.
QA Contact: migration
Reporter, does the issue still occur with the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported Thunderbird version 2 is 2.0.0.16)
Whiteboard: closeme 2008-08-28
RESO INCO per lack of response to the last question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
This bug is always there with version 2.0.0.18 (20081105)
Reopening per comment #15.

Marc, does the issue also occur with the latest Shredder trunk nightlies?
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/
Assignee: mscott → nobody
Status: RESOLVED → UNCONFIRMED
Keywords: qawanted
Resolution: INCOMPLETE → ---
Whiteboard: closeme 2008-08-28
Duplicate of bug 462725?
(In reply to comment #17)
> Duplicate of bug 462725?

Alessandro: can you confirm that this works on nightlies after the checkin (you should be fine with any build since 2008-11-03; the b1 possible release builds should be fine. The fr builds seem to have been fixed on trunk with regards to the old problem, try something like Italian.

This is also not a migration bug.
Component: Migration → Localization
Keywords: qawanted
Product: Thunderbird → MailNews Core
QA Contact: migration → localization
Whiteboard: closeme 2008-12-24
Version: unspecified → 1.8 Branch
In lieu of more information, it seems that this is indeed a dupe of bug 462725, so RESO DUP.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.