Closed Bug 54501 Opened 24 years ago Closed 24 years ago

Int chars in Reply-To,to,cc,etc... field no decoded

Categories

(MailNews Core :: Composition, defect, P2)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

(Keywords: dataloss, Whiteboard: [dogfood-][rtm++])

Attachments

(3 files)

Proposed fix
3.59 KB, patch
Details | Diff | Splinter Review
New fix with better error handling
4.10 KB, patch
Details | Diff | Splinter Review
New fix, should the right way this time to handle errors
3.93 KB, patch
Details | Diff | Splinter Review 
If you have a header reply-to field in a mail like this:
Reply-to: =?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>

Mozilla doesn't decode the header when you press Reply to the mail.

The To field after pressing Reply becomes:
=?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>

Richard is this MIME bug yours?
should be mine. Looks like I need to decode it when I extract it from the 
message headers.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
All other headers seems ok...
Wow.. this bug has some uncool sideeffects. I have a mail with the following 
headers:
---
Reply-To: =?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>
Sender: gemal@projekt.tele.dk.net
-----
If I press reply_to_all on that mail my To field will look like this:
"=?ISO-8859-1?Q?Lars_H=F8jberg?= Sender: gemal@projekt.tele.dk.net al" 
<laho@int.tele.dk>


it's not only with the reply-to header but with any 8bits recipients. BAD BAD 
BAD. We must fix that for RTM. Looks like I forget to translate the recipient!!!

It's a dogfood problem as you cannot reply to 8bits recipient.
Keywords: dogfood, rtm
Priority: P3 → P2
Target Milestone: M19 → M18
a header like this:
From: =?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>
gives me the correct thing when using reply

from is the only field which is correctly decoded. 
However, if you sent a message to yourself and to "יגה"<qwe@qwe.qwe> then try to 
do a reply-all, you will hit the problem as well.
I need to decode the headers using nsMsgI18NDecodeMimePartIIStr(). SHould be a 
very safe fix.
This seems much to rare to be called dogfood, so I'm marking it dogfood-minus.
The work-around is to edit the to-field.  The worst case result is some bounced
mail resulting from some of the extra chars... but you can resend etc.
From the description of the fix, we should very likely consider this for rtm,
and the nomination is already in place.
Whiteboard: [dogfood-]
momoi, is it common to have 8bits characters in a japanese email address?
Attached patch Proposed fix — — Splinter Review 

    
    

    
  
Henrik, can you test the patch (if you able able to build the project)?

    
  
Summary: Int chars in Reply-To field no decoded → Int chars in Reply-To,to,cc,etc... field no decoded
Whiteboard: [dogfood-] → [dogfood-]Fix in hand

    
    

    
  
I applied the patch (original one), I tested the Latin1 header in the bug and
it's fixed by the patch. I also tested Japanese name in reply to, also worked fine.
For the second patch, we can use AssignWithConversion() for the error fallback.


    
    

    
  
cc'ing nhotta. Can you review this last version of the fix. Thanks

    
    

    
  
The latest patch looks fine, r=nhotta.
I applied the latest patch, and tried the ISO-8859-1 data and Japanese data.
Both worked fine.


    
    

    
  
*** Bug 54464 has been marked as a duplicate of this bug. ***

    
  
Whiteboard: [dogfood-]Fix in hand → [dogfood-]Fix in hand, reviewed & tested. Need a + now...

    
    

    
  
rtm+, corrupting 8bit headers.  Adding dataloss keyword.  You still need a super
review to get the ++.

Keywords: dataloss
Whiteboard: [dogfood-]Fix in hand, reviewed & tested. Need a + now... → [dogfood-][rtm+]Fix in hand

    
  
Whiteboard: [dogfood-][rtm+]Fix in hand → [dogfood-][rtm+]Fix in hand, need super review

    
    

    
  
sr=mscott
Whiteboard: [dogfood-][rtm+]Fix in hand, need super review → [dogfood-][rtm+]Fix in hand, reviewed and approved

    
    

    
  
PDT marking [rtm++]

Whiteboard: [dogfood-][rtm+]Fix in hand, reviewed and approved → [dogfood-][rtm++]Fix in hand, reviewed and approved

    
    

    
  
Fixed and checked in Trunk & Branch
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [dogfood-][rtm++]Fix in hand, reviewed and approved → [dogfood-][rtm++]

    
    

    
  
Peter, can you check this bug on the branch, thanks

QA Contact: esther → pmock

    
    

    
  
Verified as fixed on win32, linux, and macos on domestic commercial builds.
 win32 commercial seamonkey build 2000-100909-mn6 installed on P500 Win98
 linux commercial seamonkey build 2000-100909-mn6 installed on P200 RedHat 6.2
 macos commercial seamonkey build 2000-100909-mn6 installed on G3/400 OS 9.04
Status: RESOLVED → VERIFIED

    
    

    
  
Oops. need to be verified on trunck.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Verified on branch.
Adding vtrunk to keyword.
Resolving as fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Keywords: vtrunk
Resolution: --- → FIXED

    
    

    
  
verifying bugs...
build 2001013020

Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: