168060 - default Sent folder in IMAP account shows Sender header, not recipient

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[David Pletcher]

(Using versions Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826 and earlier.)
When using an IMAP account on a vanilla courier-imap server, sent messages are
routed correctly to the Inbox/Sent folder, but the Sent folder view shows the
sender column rather than the recipient.  Courier-imap does not permit creation
of top-level folders; all new folders must be subfolders of Inbox.

It would also be nice if Sender and Recipient columns could be enabled
independently, in order to support maildrops collecting input from distinct
accounts, but that's another matter.

Comment 1

[Steve Harris]

This bug should be confirmed! It is not even possible to manually configure the
"Sent" listing to display the recipient. This bug is a real pain.

Comment 2

[Antti Boman]

You should be able to bypass the problem by going to Mail Account Settings ->
Copies & Folders, and instead of "Sent" Folder On, select the sent folder from
Other. This is naturally not the way it should be.

Works for my Cyrus IMAP.

Comment 3

[Bernd Brincken]

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

Comment 4

[Scott Advani]

I've experienced the same problem, and the solution from Antti worked for me.

Comment 5

[andrei]

as someone else noted, the problem is not that the recipient field is not there 
by default, but you actually cannot add it, because it doesn't appear at all in 
the column list.

Comment 6

[James Montaldi]

Every folder should adapt display accordingly as whether individual email is
sent by someone else or by account owner, in which case display "To: recipient"
(in Sender column - there'd be no problem labelling the column Sender, as long
as the "To:" is included).  This was already done in NeXT mail all those years ago.

J
 

Comment 7

[Hai Pham]

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

Comment 8

[Peep Chaintreuil]

This also effects the quick filter, leaving it as "Subject or sender contains:"
instead of "Subject or Recipient contains:".  (Antti Boman's workaround bug
168060, comment 2 seems to work for this problem as well.)

bug 166603 may also be a blocker/reason of/for this bug.

Comment 9

[Wade Van Buskirk]

Also sub-folders of folders named "sent" and "sentmail" on remote systems don't
have 'recipient' as an option in the column headers of the message list. Perhaps
'recipient' should always be an option which is by default selected for folders
which include the word 'sent' in their path. This will allow sent mail to be
organized in remote folders and sub-folders by recipient reguardless of the
folder path name.

Comment 10

[Andrew Smith]

There was some code to deal with this here:

http://lxr.mozilla.org/mozilla/source/mailnews/imap/src/nsImapMailFolder.cpp#395

But it was commented out by jefft (on 2000-03-14) in this patch:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/mailnews/imap/src&command=DIFF_FRAMESET&file=nsImapMailFolder.cpp&rev2=1.253&rev1=1.252

I don't see why he commented out the flags for Sent, Drafts and Templates
folders, but left in the flags for Inbox and Trash. The CVS log message for the
patch mentions bug 28301, but I'm not sure how that's relevant.

What this boils down to is the Sent folder needing the MSG_FOLDER_FLAG_SENTMAIL
flag set on it; this flag is detected by the UI and changes the columns
accordingly (look for "swappedhidden" in the code).

Comment 11

[Mike Cowperthwaite]

(In reply to comment #0)
> When using an IMAP account on a vanilla courier-imap server, sent messages are
> routed correctly to the Inbox/Sent folder, but the Sent folder view shows the
> sender column rather than the recipient.  Courier-imap does not permit
> creation of top-level folders; all new folders must be subfolders of Inbox.

My available IMAP account is Fastmail, which has the same restriction on all 
folders being subs of Inbox, but I do not see this problem currently (1.6, 1.7, 
1.8a2).  However, I don't know if that's a Courier server or not.  David 
Fletcher, is this still an issue?


> It would also be nice if Sender and Recipient columns could be enabled
> independently, in order to support maildrops collecting input from distinct
> accounts, but that's another matter.

These can (now) be configured independently, but there are only two independent 
column display modes, one for "sent" (and drafts, unsent) folders, and the other 
for every other type of folder.  Better column configuration is bug 76702; see 
also bug 36489.

Comment 12

[Mike Cowperthwaite]

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

Comment 13

[Andrew Poth]

By clicking on the little "window pane" icon at the top right of the Message Pane, one can select or deselect display of Recipient and Sender columns for the Inbox.  The problem is, if one selects Sender for the Inbox and deselects Recipient, the appearance of ALL the folders under the (AOL) IMAP account change.  One should be able to select Sender for the Sent Items folder only, Recipient for all others.  Selecting Sender appears to display the correct sender address and selecting Recipient shows the correct recipient address; it's just that the SeaMonkey client doesn't remember individual folder settings for an AOL IMAP account.  One can show Sender and Recipient simultaneously, but it requires more screen space and can get confusing.  (This may be true of other IMAP servers, too, but I can only test AOL now.)

Comment 14

[David :Bienvenu]

Andrew, please try 2.0 - I believe these AOL interop issues have been resolved.

Comment 15

[Wayne Mery (:wsmwk)]

is this gone for you with the fixing of bug 114533?

Comment 16

[Andrew Poth]

> Andrew, please try 2.0 - I believe these AOL interop issues have been resolved.
> 

NOTE:  David's comment was off-topic.  He was inadvertently referring to Thunderbird 2.0 (In reply to comment #14)

Comment 17

[Wayne Mery (:wsmwk)]

Andrew writes "When I posted my comment last May, I was using Seamonkey 1.1.1".

David's comment might apply to SM 1.1.4.  I don't follow SM fixes, but 1.1.2 and 1.1.4 picked up a lot including many things fixed in 2.0.
(FWIW my comment about bug 114533 is worthless, given that bug was fixed in 2003)