17943 - Messages sent later, are retrieved as READ status in POP account.

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P2)

Description

[laurel]

When testing Send Later/Send Unsent messages, the messages I sent to myself
(seamonkey to seamonkey, same user) were retrieved as read messages.

1.  Launch messenger to POP mail account, login.
2.  Click New Msg.  Address the message to yourself, but send it later
(File|Send Later from compose window menu).
3.  From Messenger window, File|Send Unsent Messages. Status bar text displays
that the message was sent successfully.
4.  Get Msg.
    Result:  message is retrieved but is shown as READ status.

Expected result:  the message should be new/unread.

Found using 1999-11-03-13m11 commercial build on NT 4.0.

Comment 1

[Phil Peterson]

Reassign to putterman

Comment 2

[Karen Huang]

Used all platforms for 12-10-08-m12 builds:

This also happened on the Drafts and Template folders after save as draft & save
as template, updated the summary to reflect for including that:

Changed summary to:
"Messages sent later, save as draft & save as template are retrieved as READ
status."

And it also happened to all platforms, change platform to all.

Comment 3

[esther]

Laurel's bug is for the state of the message after it was sent then retrieved.
Since opening Drafts and Template messages in a compose window (for editing and
sending) is not implemented yet, this bug is only for Send Later at this time.
One more note: this bug is just for POP, IMAP is displaying the newly retrieved
message as Unread. Changing the Summary back to Send Later only bug.

Comment 4

[Karen Huang]

Release Notes for M13.

Comment 5

[lchiang]

Esther - what happens in your steps if you addressed/sent the messages to 
someone else besides yourself?

Comment 6

[scottputterman]

Pratik, could you try this out?

Comment 7

[Pratik Dhupia]

Build 2000-06-27-08 M17 on NT4. 

When you send a message (using File->"send unsent messages") from a pop or imap 
account to another pop a/c, the new message does not appear bold although it 
should. The status for the message, however, says new. 

Sending "Unsent Mail" from Pop to Imap a/c works as expected (messages appear 
bold and status says new). I used the same steps as described above, just two 
different accounts. 

Hope this helps!

Comment 8

[scottputterman]

nominating for nsbeta3 and moving to M18.

Comment 9

[lchiang]

Pratik - in your previous comments, what happens if you send to another profile? 
 I couldn't tell if your accounts were on the same profile or not. Thanks.

Comment 10

[scottputterman]

mail triage marking nsbeta3+ assuming this happens when sending to another 
profile.

Comment 11

[Pratik Dhupia]

Lisa: it doesn't matter if I use the same profile or have different profiles. I 
see the bug in both cases. 

Comment 12

[lchiang]

I think this is working fine now.  I just tried it also using 8-9 m18 build 
win32.  Message comes in as new.

Comment 13

[Pratik Dhupia]

I don't think it is, the message does show "new" as status but it does not 
appear bold. I just checked on 2000-08-11-08 build M18 on NT4. thanx. 

Comment 14

[scottputterman]

reassigning to gayatrib

Comment 15

[lchiang]

second pass: - per mail triage

Comment 16

[scottputterman]

sorry for the extra email. Removing mail2 keyword.

Comment 17

[Oliver Klee]

Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.

Comment 18

[Håkan Waara]

Worksforme using build 20010223, Windows 98. Pratik, can you still reproduce
this? If not, please mark this bug WFM.

Thanks

Comment 19

[Sheela Ravindran]

checked on buildid 2001-04-19-08 this bug still exists on win98.  POP messages 
sent from unsent folder still is received as read.  

Comment 20

[Håkan Waara]

reassign

Comment 21

[grylchan]

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

Comment 22

[grylchan]

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

Comment 23

[Chao Yu]

Attachment: Propose fix: a bug in BuildHeaders() prevents a X-Mozilla-Status email header field from being pruned before sending

Comment 24

[laurel]

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

Comment 25

[Jussi-Pekka Mantere]

Removing nsenterprise nomination. Adding nsBranch.

Comment 26

[Håkan Waara]

Chao, can you please explain the fix?

Comment 27

[Håkan Waara]

Taking to drive this patch in for Chao Yu. I applied the patch in my tree and
finally this bug was fixed!

r=hwaara

mscott, perhaps you could sr= this?

Comment 28

[Chao Yu]

>> Chao, can you please explain the fix?

The reason that Mozilla Mail is exhibiting this bug is because it creates a new 
application specific email header field, X-Mozilla-Status, to store the state 
of the email (such as whether it is a new email or whether it had been read) 
when the email is received by a user. However, it is also temporarily used and 
set when an email is to be send later but not yet send for internal bookkeeping 
purposes. This field was meant to be stripped off of the email header before 
sending to the recipient to remove any confusion with the state of the email on 
the receiving Mozilla Mail app.  But, a bug described at my previous post 
prevented it from being stripped. Changing that single line of code resolves 
the bug (and possiblely other side effects) as you had demonstrated.

Comment 29

[Scott MacGregor]

sr=mscott

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That PL_strlen isn't exactly making things more efficient, and, FWIW, this fix
is causing 8 lines of code to be executed that we never hit before (does it do
the right thing?).  But anyway...

a=dbaron (on behalf of drivers, in response to request from hwaara)

Comment 31

[Håkan Waara]

Thanks Chao for the fix. It is now checked into the trunk.

Comment 32

[Håkan Waara]

QA: when verifying this, you might want to make sure nothing strange happens to
the msg headers when a msg is sent later. or that a X-Mozilla-Status header
slips through the net on outgoing messages.

Comment 33

[Sheela Ravindran]

verified using the following builds:
linux:  2001-09-04-08
mac: 2001-09-04-11
win98: 2001-09-04-10