300847 - Reply All breaks if any addresses have an empty <>

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[Greg Ubben]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Official build of Thunderbird 1.0.2 (20050317) for Windows

If any addresses (To, Cc) contain an empty <> email address, the Reply All
function fails to fill in any of the addresses in the message.  In fact, it
disables the recipient and subject fields so that you can't even fix them.  A
work-around is to instead do a plain Reply and then copy/paste all of the valid
addresses into the fields.

This was first seen with a broken list server that puts an extra To: field in
front of the normal To: field with the broken-out members:
    To: "Multiple subscribers of list [e-mail]" <>
    To: [e-mail], [e-mail], [e-mail]
The problem may not happen if the <> is in the last address.


Reproducible: Always

Steps to Reproduce:
1.  Create a message in your mailbox that contains a bogus address like
        To: Bill <>, Mary <[e-mail]>, Jane <[e-mail]>
2.  View the message with Thunderbird and hit Reply All

Actual Results:  
Header fields are greyed out in the message compose window, and in any case
don't contain the [e-mail] and [e-mail] addresses.

Expected Results:  
Should have ignored the bogus <> address and listed the remaining good addresses
as normal.  Or should have put a blank recipient address for the bogus address
to make the problem more apparent.

The <> is invalid per RFC 2822 but it shouldn't behave *this* way.  This problem
has existed since at least Mozilla 1.1 (seen on Unix), though it didn't actually
disable the fields in Mozilla; it just left them empty.  See also bug 202554,
and maybe bug 42465.

Comment 1

[Greg Ubben]

I found these additional related bugs:
Bug 208577 - Illegal Reply-To address truncated or omitted in Mozilla
Bug 276228 - Illegal Reply-To breaks Thunderbird replies (fields disabled)
Bug 229880 - Same problems editing a draft with a bad address

Comment 2

[Mike Cowperthwaite]

I don't think 208577 is (directly) related, but the other two certainly are.

However: this is behaving much better in TB 1.5b1-0904: I get an address field 
for each recipient in the list, but the invalid recipient's field is simply 
blank -- just as requested in the Expected Results.

Greg Ubben, please get 1.5b1 (or 1.6a1 trunk build) and confirm; assuming you 
see the same thing, please mark this bug:   Resolved | WorksForMe

Comment 3

[Mike Cowperthwaite]

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

Comment 4

[Mike Cowperthwaite]

No response from reporter  => WFM