739110 - Copy messages to Gmail via TB IMAP create duplicates

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: IMAP, defect)

Description

[F.C.]

User Agent: Mozilla/5.0 (Windows NT 6.2) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11

Steps to reproduce:

I migrated emails from Gmail to a new Gmail account via IMAP using TB 10.0.2 (Win 7 32 bit).

I think from the user point of view I understand clearly the special Gmail IMAP implementation and the difference between Gmail labels and IMAP folders and also how it should work, but I got some unexpected issues.
 
I started the migration with [Gmail]/All Mail IMAP folder, which has all the emails in the account. Everything was fine, resulted in having all the e-mails in the new account (also in the [Gmail]/All Mail IMAP folder).
I started to have problems when started to migrate the rest of the Gmail labels/IMAP folders. I know that Gmail only stores every emails just once in [Gmail]/All and assigns labels to these, which will end up in separated e-mails in the different IMAP folders with multiple copies.
 
When I migrate for the first time a label/IMAP folder (e.g. [Gmail]/Sent Mail or ANY OTHER ONE, but let's mention now Sent Mail for this description) from the IMAP point of view the destination folder is empty and it copies all the e-mails from the source folder to the destination folder, which is the expected situation. On the Gmail side the target server recognises the already existing e-mails (always in the [Gmail]/All Mail folder where the e-mails are physically stored) and assigns the label to it based on the target folder where the IMAP client copies it to (e.g. [Gmail]/Sent Mail). From the IMAP point of view it will result no additional emails in [Gmail]/All Mail folder and having the same number of emails in the source and target [Gmail]/Sent Mail folders.
 
Reproducible: Always
Steps to Reproduce:
(0. Prerequisite/done first successfully: [Gmail]/All Mail IMAP folder migrated successfully from the source Gmail account to the target Gmail account)
1. Attempt to copying a different IMAP folder from from the source Gmail account to the target Gmail account, e.g. [Gmail]/Sent Mail IMAP folder either by drag&drop or by using the context menu.
2. It is only partly successful, the problems are always with the same messages.



Actual results:

It works great without a problem in about 90%, but in the remaining ~10% (being a different amount of emails in the different IMAP folders) there are problems: instead of being only labelled in the target account (e.g. by [Gmail]/Sent Mail) a duplicate is created in [Gmail]/All Mail and the desired label ([Gmail]/Sent) is assigned to the duplicate e-mail instead of the already existing original message in [Gmail]/All Mail.

The duplicated pairs in the target Gmail account (in [Gmail]/All) are totally identical including the message ID, header and the body.



Expected results:

According to my understanding none of the messages should be duplicated within the Gmail account on the server, the existing messages in All Mail should only be labelled with the given labels according to the source IMAP folder, e.g. [Gmail]/Sent Mail.
It works fine with the far majority of the emails I think in some cases Gmail cannot identify that the e-mail is already in the target account (in [Gmail]/All Mail) and it creates a duplicate in  in [Gmail]/All Mail.

It is not easy to find anything special in the header of the duplicated messages, it looks quite random to me. On the other hand I could notice that a bigger part (the majority) of the duplicated message have:
*no subject or replies to no subject or forwarded email with no subject, e.g.:  "", "Re: ", "Re:  Re:  Re:", "Fwd:"… I mean "no_subject", "Re: no_subject", "Re:  Re:  Re: no_subject", "Fwd: no_subject"… OR
*only a few (~1-3) characters in the subject, for example ":)", ":(", "?", "CV", "..", "..."  OR
*Reply or Forwarded messages of the ~1-3  characters long subject messages: "FW:  :)", "Fwd: :)" "Re: CV" or Delivery status notification(s), etc.

This identified "pattern" may help to find the solution. On the other hand not all the messages meeting the pattern above get duplicated!
 
Have you got any ideas why in the majority of the cases (around 90%+) it works perfectly, but in some cases (around up to 10%) Gmail cannot match in the target account the already existing e-mail in [Gmail]/All with the message that TB copies to the [Gmail]/Sent Mail IMAP folder? And as wrote earlier it is not with [Gmail]/Sent folder, it happens with any other IMAP folder/Gmail label.

Are there any way to avoid the annoying duplicates and keeping all the labels correctly and threads correctly in Gmail? It is especially annoying as after identifying the duplicates and deleting the original or the duplicated email does not restore the normal working way, the duplicate-free status.

Comment 1

[F.C.]

FYI - I have tried on two different PCs, both have Win 32 bit, one of them ia Win 7, the other is Win 8 having the same issues.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to F.C. from comment #0)
> Actual results:
>(snip)
> The duplicated pairs in the target Gmail account (in [Gmail]/All) are
> totally identical including the message ID, header and the body.

Tb doesn't exclude duplicated mail data with different UID. Mail of different UID is absolutely different mail for mail client such as Tb, even if absolutely same mail data. And Tb simply uses IMAP append command to upload mail data and passes mail data to IMAP server.
"Decision on duplicate or not" is all up to Gmail. Gmail may see Tb's message header such as X-Mozilla-...: which is added to mail in local mail folder(POP3, "Local Folders").

Can you show us following data of the "duplicated mails in [Gmail]/All Mail"?
(1) UID of the duplicates.
    Show "Order Received" column(column value is UID if IMAP).
(2) Save mails to .eml, and attach .eml or diff of .eml to this bug, .
    (don't paste if long data, please) 

Anyway, see meta bug 402793 and bugs listed in dependency tree for that bug(with "Show Resolved"), before adding comments on funny phenomenon for you with Gmail and/or Gmail IMAP.

Comment 3

[rsx11m]

This is neither a crash nor data loss, thus reducing severity. Also, moving to MailNews Core as it's obviously an IMAP-related problem.

Comment 4

[Ludovic Hirlimann [:Usul]]

F.C. for analysis and answering comment #2 you will need an imap log that was taken while the issue is running (see https://wiki.mozilla.org/MailNews:Logging).

Comment 5

[F.C.]

Attachment: Original migrated email in "[Gmail]/All Mail"

This email was created in "[Gmail]/All Mail" when the "[Gmail]/All Mail" folder was migrated from SRC_account to DEST_account. It happened as expected without issues.

Comment 6

[F.C.]

Attachment: Duplicated email in "[Gmail]/All Mail"

This email was created as a duplicate in "[Gmail]/All Mail" when the "[Gmail]/Sent Mail)" folder was migrated from SRC_account to DEST_account. The duplicate was created instead of only having the already existing e-mail labeled!

Comment 7

[F.C.]

Thank you for the fast responses.

I understand now that it is up to Gmail to decide that if the uploaded email (by the IMAP client using append command) already existed or not in [Gmail]/All Mail, and based on this the email is only labelled only or duplicated.

I created the data requested. I am attaching a pair of email which  was duplicated in "[Gmail]/All Mail" when migrating the "[Gmail]/Sent Mail)" folder. This example had no subject.

I added the original and duplicated words to the files names to indicated which were the original and duplicated.
	(Please notice the original email addresses were replaced before uploading: to: [e-mail] and [e-mail])

The 2 eml files are identical, except the UID/Order Received: 11500 vs. 111555, which is shown in the files names also (after saving it from TB).

I also tried to create the IMAP log, but failed.
I set the environmental settings according to  https://wiki.mozilla.org/MailNews:Logging, but the imap.log file was not created. I double-checked everything according to the description:
-Settings are ok:
	NSPR_LOG_MODULES=imap:5
	NSPR_LOG_FILE=%USERPROFILE%\Desktop\imap.log "%ProgramFiles%\Mozilla Thunderbird\thunderbird.exe"
-I have write access to the directory specified 
-I did shut down the TB application at the end
-I have admin rights when ran the batch file

If the IMAP log is needed to find the issue please let me know while it is not created. I tried it several times, but no file was created in the given desktop folder.

Thank you again.

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to F.C. from comment #7)
> The 2 eml files are identical, except the UID/Order Received: 11500 vs.
> 111555, which is shown in the files names also (after saving it from TB).

Actually UID=11500 and UID=111555 in [Gmail]/All Mail of same Gmail IMAP account?
Note: 111555 - 11500 = 10055 mails were appended(and some are deleted) since upload of UID=11500 or mail arrival of UID=11500, because Gmail IMAP starts from UID=1 for any Gmail IMAP folder and UID in different Gmail IMAP folder is independent even if same mail of different Gmail Label.
If so, "Gmail version when the mail was uploaded" may be relevant.

If so, can you see your problem by next?
(1) Move mail of UID=11500 to [Gmail]/Trash.
(2) Copy mail of UID=111555 to local mail folder.
(3) Copy the mail in local mail folder to [Gmail]/All Mail.
(4) Copy the mail in local mail folder to [Gmail]/All Mail again.
Dup mail happen?  
(5) Copy back mail in [Gmail]/Trash to [Gmail]/All Mail.
What happens?

Comment 9

[WADA:World Anti-bad-Duping Agency]

Other possibility.
Did you you copy mail to "[Gmail]All Mail" with offline-use=On and view mails while Work Offline mode of Tb? (Folder Properties/Synchronization)
If yes, it's very normal phenomenon.

Comment 10

[Ludovic Hirlimann [:Usul]]

(In reply to F.C. from comment #7)
 
> If the IMAP log is needed to find the issue please let me know while it is
> not created. I tried it several times, but no file was created in the given
> desktop folder.

If you followed the docs, can you check the rights on the folder (just in case you don't have write access to it) ?

Comment 11

[F.C.]

> Other possibility.
> Did you you copy mail to "[Gmail]All Mail" with offline-use=On and view mails
> while Work Offline mode of Tb? (Folder Properties/Synchronization)
> If yes, it's very normal phenomenon.

The copy was made between the 2 Google accounts being online with TB, so the "Work Offline" mode was not ON.

> Actually UID=11500 and UID=111555 in [Gmail]/All Mail of same Gmail IMAP
> account?
> Note: 111555 - 11500 = 10055 mails were appended(and some are deleted) since
> upload of UID=11500 or mail arrival of UID=11500, because Gmail IMAP starts
> from UID=1 for any Gmail IMAP folder and UID in different Gmail IMAP folder
> is independent even if same mail of different Gmail Label.
> If so, "Gmail version when the mail was uploaded" may be relevant.

Yes, e-mails with UID=111500 and UID=111555 are in the same account's "[Gmail]/All Mail folder". I think there was a typo, there are only 55 mail arrivals/appends between the two example emails. (I have saved the 2 emails from my migration_TARGET account.)

> 
> If so, can you see your problem by next?
> (1) Move mail of UID=11500 to [Gmail]/Trash.
> (2) Copy mail of UID=111555 to local mail folder.
> (3) Copy the mail in local mail folder to [Gmail]/All Mail.
> (4) Copy the mail in local mail folder to [Gmail]/All Mail again.
> Dup mail happen?  
> (5) Copy back mail in [Gmail]/Trash to [Gmail]/All Mail.
> What happens?

No problem, I have done what you suggested above, I provide all the details for going sure.
FYI - I have set the following IMAP settings for deletion:
(A) GMAIL side: 
  -Auto-Expunge OFF - Wait for the client to update the server
  -When a message is marked as deleted and expunged from the last visible IMAP folder: Move the message to the Trash
(B) TB: Move it this folder: Trash

(0) START STATE:
-I have both e-mails in [Gmail]/All Mail with UID=111500 and UID=111555 in the MIGRATION_TARGET account. (The UID 11500 was the result of copying it from MIGRATION_SOURCE account/[Gmail]/All Mail folder. The UID=111500 is the duplicate which was created when migrating it from MIGRATION_SOURCE account/[Gmail]/Sent Mail folder to MIGRATION_TARGET account/Sent Mail)

-I also have the same e-mail in [Gmail]/Sent Mail with UID=23939 in the MIGRATION_TARGET account, which was created when migrating from MIGRATION_SOURCE account/[Gmail]/Sent Mail folder to MIGRATION_TARGET account/Sent Mail folder)
(FYI - in the Gmail user interface it seems that the Sent label is assigned to the duplicate/2nd e-mail in the [Gmail]/All Mail folder!)

(1) STEP: I moved mail of UID=111500 to [Gmail]/Trash in my MIGRATION_TARGET account. (This first mail was copied when the [Gmail]/All Mail was migrated from the MIGRATION_SOURCE account). 
RESULT of STEP 1 in the MIGRATION_TARGET account:
-UID=111500 is in the Trash (Having UID 65332 in the Trash)
-UID=111555 remained in [Gmail]/All Mail
-UID=23939 remained in [Gmail]/Sent Mail (it also shows me that the Sent label was assigned to the duplicate message)

(2) STEP: I copied mail of UID=111555 to local mail folder from my MIGRATION_TARGET account/[Gmail]/All Mail folder.
RESULT of STEP 2:
-no change in the MIGRATION_TARGET account
-Copy of UID=111555 created in local mail folder -> UID=0. FYI: If I save this email to .eml it has 3 extra lines at the beginning and a empty line at the end (153 bytes bigger then the original message), otherwise it is the same:
"X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
"

(3) STEP: I copied the mail in local mail folder with UID=0 to [Gmail]/All Mail in my MIGRATION_TARGET account.
RESULT of STEP 3:
-no change in the local folder
-A "duplicate" is created in [Gmail]/All Mail in my MIGRATION_TARGET account with UID=111556, but in a very starange way! It looks exact duplicate for the first time in the message list as having the same subject ("Re:"), the same sender, the same recipient, the same time and date (2007.03.08 13:14), only the size is 1.9KB instead of 1.8 KB. I check out this email further, everything is different in the message header and in the body! I recognized the message, it the first half part of an earlier message, having UID=65062 (4.4 KB). I do not understand this at all. I saved this email to .eml as well. Let's call this message as a "screwed up duplicate".

(4) STEP: I copied the mail in local mail folder with UID=0 to [Gmail]/All Mail again to [Gmail]/All Mail in my MIGRATION_TARGET account.
RESULT of STEP 3:
The same strange thing happened, like as a result of STEP 3!
-no change in the local folder
-A "screwed up duplicate" is created AGAIN in [Gmail]/All Mail in my MIGRATION_TARGET account, this time with UID=111557 It also looks exact duplicate to the original for the first time in the message list as having the same subject ("Re:"), the same sender, the same recipient, the same time and date (2007.03.08 13:14), only the size is 1.9KB instead of 1.8 KB, but everything is different in the message header and in the body!
I saved this email to .eml as well, it is identical to the "screwed up duplicate" created in STEP 3, it is the first half part of an earlier message, having UID=65062 (4.4 KB).

> Dup mail happen?  
In the described very strange way.
FYI: the email with UID 65062 is the first email in the [Gmail]/All Mail folder in my MIGRATION_TARGET account, this email even had a different sender, it was sent by Gmail Team (subject: "Gmail is different. Here's what you need to know") in 2006, when the MIGRATION_SOURCE account was created. I guess the reason is why UID is not 1 for the first email is that I have redone the migration again when I started to have the duplication issues in the first migration round. Of course I started the 2nd migration attempt with an empty mailbox, before starting the 2nd migration I deleted all the e-mails and folders in Gmail (in the Web UI). This first email has UID 1 in the TB in the MIGRATION_SOURCE account/[Gmail]/All Mail folder.

(5) STEP: I copied back mail from [Gmail]/Trash with UID 65332 in the Trash (originally UID=111500 in All Mails) to [Gmail]/All Mail in my MIGRATION_TARGET account.
RESULT of STEP 5:
-Message with UID=65332 is gone from the Trash folder (originally UID=111500 in All Mails)
-The restored message from Trash is back in All Mail with UID=111558, it is identical to the duplicate untouched in All Mail with UID=111555.

To sum up: there are now 4 emails in All Mails (related to the test), see screen shot also attached:
(111500 original message in All Mail deleted)
1. UID=111555 - duplicate created earlier
2. UID=111556 - "screwed up duplicate"
3. UID=111557 - "screwed up duplicate"
4. UID=111558 - the original message restored from Trash

It seems even more strange when I checked out at Gmail web UI. I can see the 4 e-mails being identical to each other: including the message header and body in the UI view:

[e-mail]
Re: - 2007-03-08
	 	
[e-mail]
Re: - 2007-03-08
	 	
[e-mail] (2)
Re: - 2007-03-08

Now the situation is worse than before, there is an extra problem. I can see different things in Gmail GUI and TB client in terms of 2 out of these mentioned 4 e-mails.
I pressed Download/Sync now, but did not help to see the exactly the same for the mentioned 2 emails in TB!
Should I run "repair folder" in the settings? I guess it would download the full folder again (including headers and messages) meaning being slow as the account is quite full (7.5 GB).

(FYI - I downloaded the source of the 4 emails from the Gmail Web GUI), which looked exactly the same on the web reading panel. 2 emails were identical to the original, the 2 others were 100 bytes bigger, at the beginning of the file like described in the 2nd test below: 
"X-Mozilla-Keys:                                                                                 
"

Just to go one step further, I repeated the recommended 5 step test with a different message which duplicated in All Mail when it was migrated from MIGRATION_SOURCE account/[Gmail]/Sent Mail folder to MIGRATION_TARGET account/Sent Mail, results described short, this message also had subject "Re:".

Start status: Original and the duplicate emails in the [Gmail]/All Mail folders and in the [Gmail]/Sent Mail are identical.

(1) Move original email from [Gmail]/All Mail to [Gmail]/Trash.
  Result: message moved to Trash, item merged to Sent Mail stayed.

(2) Copy duplicated email (UID=111562) from [Gmail]/All Mail to local mail folder.
  Result: Interesting, in the local folder it got UID 2007 (in spite of the fact that it was the 2nd message in the folder).

(3) Copy back the mail in local mail folder (UID 2007) to [Gmail]/All Mail.
  Result: Duplicated item with UID=111563 in [Gmail]/All Mail. Comparing the .eml files (UID 111562 and 111563), but they are not identical fully: 111563 is 100 bytes longer, there are 2 lines with the text and some same spaces at the beginning (see below) and an enter at the end of the file, otherwise there are the same:
"X-Mozilla-Keys:                                                                                 
"

(4) Copy back the mail in local mail folder to [Gmail]/All Mail again.
  Result: Duplicated item created again with UID=111564 in [Gmail]/All Mail. Comparing the .eml files (UID 111563 and 111564) are identical. So the 2 new duplicates are totally the same, but there are the additional 100 bytes comparing to the original message.

(5) Copy back mail in [Gmail]/Trash to [Gmail]/All Mail.
What happens?
  Result: Duplicated item created again with UID=111565 in [Gmail]/All Mail. This is identical to the original message.

Result summary after the 2nd test:
(Original message in All Mail deleted)
4 emails in the [Gmail]/All Mail:
1. UID=111562 - duplicate, identical to the original
2. UID=111563 - duplicate with 100 additional bytes (described above) 
3. UID=111554 - duplicate with 100 additional bytes (described above)
4. UID=111565 - identical to the original (copied back from Trash)

It seems that 2 two tests had the same result, even more in that first test the 2 duplicated and modified emails were screwed up on the TB client side, which may be a new problem.

I attached the files of the first test, please find the following 8 files attached:
-email from the local folder
-4 emails from (UID 111555-111558) [Gmail]/All Mail folder
-Migrated email from the [Gmail]/Sent Mail folder (UID: 23939)
-First email from the [Gmail]/All Mail folder (sent by Google, UID=65062)
-Screenshot of TB message list

Let me know please how I can help further to find the issue.
Thank you.

Comment 12

[F.C.]

Attachment: email copied to the local folder (1st test)

Comment 13

[F.C.]

Attachment: 1/4 emails from (UID 111555-111558) [Gmail]/All Mail folder (1st test)

Comment 14

[F.C.]

Attachment: 2/4 emails from (UID 111555-111558) [Gmail]/All Mail folder (1st test)

Comment 15

[F.C.]

Attachment: 3/4 emails from (UID 111555-111558) [Gmail]/All Mail folder (1st test)

Comment 16

[F.C.]

Attachment: 2/4 emails from (UID 111555-111558) [Gmail]/All Mail folder (1st test)

Comment 17

[F.C.]

Attachment: Migrated email from the [Gmail]/Sent Mail folder (UID: 23939) (1st test)

Comment 18

[F.C.]

Attachment: First email from the [Gmail]/All Mail folder (sent by Google, UID=65062)

Comment 19

[F.C.]

Attachment: Screenshot of TB message list after 1st test

Comment 20

[F.C.]

(In reply to Ludovic Hirlimann [:Usul] from comment #10)
> If you followed the docs, can you check the rights on the folder (just in
> case you don't have write access to it) ?
As I wrote in the earlier post I had checked the write right on the Desktop folders. Just for going sure I have just double-checked, I can create and writes files there. Any other ideas? Let me know, please. Thank you.

Comment 21

[WADA:World Anti-bad-Duping Agency]

(In reply to F.C. from comment #11)
>   -Auto-Expunge OFF - Wait for the client to update the server

Perhaps it's the reason.

As you say following, you did mail copy between two Gmail IMAP account, Tb did (i) fetch from Gmail IMAP account-1, and (ii) append to Gmail IMAP account-2.
> The copy was made between the 2 Google accounts being online with TB, (snip)

Gmail manages mails by X-GM-THRID, X-GM-MSGID, and adds X-GM-LABELS to a mail.
X-GM-THRID, X-GM-MSGID, is unique value in Gmail system.  
(1) At Gmail IMAP account-1, a mail of following attribute is held.
       X-GM-MSGID=1T1, X-GM-MSGID=1M1, X-GM-LABELS : FolderA, FolderB
    At Tb's Gmail IMAP account-1, two mails are shown for the single mail.
       FolderA : UID=1A1, Call mail-1-A
       FolderB : UID=1B1, Call mail-1-B
(2) At Gmail IMAP account-2, no mail data of mail-1-A(==mail-1-B) is held.
    At Tb's Gmail IMAP account-2, 
       FolderC : Highest UID=2C0 (FolderC=[Gmail]/All Mail in your case)
(3) Copy mail-1-A in FolderA of account-1 to FolderC.
     uid fetch 1A1 BODY[] at account-1/FolderA
     append to account-2/FolderC
     => UID=(2C0+1)=2C1 is returned.
        FolderC : UID=2C1, Highest UID=2C1
     => At Gmail account-2, following mail is generated in Gmail's DB
           X-GM-MSGID=2T1, X-GM-MSGID=2M1, X-GM-LABELS : FolderC
(3) Copy mail-1-B in FolderB of account-1 to FolderC.
     uid fetch 1B1 BODY[] at account-1/FolderB  
     append to account-2/FolderC
     => UID=(2C1+1)=2C2 is returned, because UIDPLUS is supported.
        For Tb, FolderC : UID=2C1
(4) At Gmail account-2, following mail already exists in Gmail's DB for same
    mail data and same Gmail Label, and it's re-used for "FolderC : UID=2C1".
      FolderC : UID=2C1 == X-GM-MSGID=2T1, X-GM-MSGID=2M1, X-GM-LABELS : FolderC
      FolderC : UID=2C2 == X-GM-MSGID=2T1, X-GM-MSGID=2M1, X-GM-LABELS : FolderC
    Then delete of UID=2C2 occurs at IMAP server side.
    This is similar to "delete of UID=2C2 by other IMAP client", perhaps except
    that \Deleted flag is not stored in this case.

(5) If Auto-Expunge=On, dulicated/deleted "FolderC : UID=2C2" is automatically
    removed by Gmail, and removal of "FolderC : UID=2C2" is notified by
    Gmail via unsol *EXPUNGE nnn (nnn=message sequence number).
    And, for "uid 2C2 fetch", Gmail IMAP returns "UID=2C2 doesn't exist".
    => "FolderC : UID=2C2" disappears at Tb.
    This is similar to selective expunge of specific UID. 

(6) If Auto-Expunge=Off, removal of "FolderC : UID=2C2" is not automatically
    invoked in Gmail IMAP.
    => "FolderC : UID=2C2" still remains at Tb too.

Above (6) may be [Gmail]/All Mail only phenomenon, because \Deleted flag is not supported for [Gmail]/All Mail in Gmail IMAP. "uid xxx store +Flags \Deleted" is always ignored by Gmail IMAP if [Gmail]/All Mail.

Can you see duplicated mails by append of two identical mails to Gmail IMAP folder other than [Gmail]/All Mail, [Gmail]/Trash, [Gmail]/Spam, with Auto-Expunge=Off?
If duplicated mails occur on other folder(ordinal Gmail Label), can you see "flagged \Deleted status" by "Just mark it as deleted" model?
(Server Settings. If flagged as \Deleted, mail is shown with strike-thru line at thread pane)

Comment 22

[WADA:World Anti-bad-Duping Agency]

See bug 721316 for X-GM-THRID, X-GM-MSGID, X-GM-LABELS.

Comment 23

[WADA:World Anti-bad-Duping Agency]

Gmail IMAP behaviour with dup mail upload was different.
(1) Auto-Expunge=Off.
    By append, UID=2285 exists in [Gmail]/All Mail.
    Mail has ordinal Subject: header(short ascii only), simple text/plain mail.
    Number of mails in [Gmail]/All Mail == 1905, Highest UID=2285
(2) append same mail to [Gmail]/All Mail.
> 56 append "[Gmail]/All Mail" (\Seen) "21-Mar-2012 09:00:15 +0900" {457}
> * 1905 EXPUNGE  <= 1905-th mail was expunged (== mail of UID=2285) 
> * 1905 EXISTS   <= After apped and above expunge, total number of mails=1905
> 56 OK [APPENDUID 602171751 2286] (Success) 
(3) By "* 1905 EXPUNGE" response, Tb removes mail of UID=2285. 
(4) fetch for newly appended mail(UID=2286)
> 60 UID fetch 2286:* (FLAGS) 
> * 1905 FETCH (UID 2286 FLAGS (\Seen))
> 60 OK Success 
> 61 UID fetch 2286 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc ...
> * 1905 FETCH (UID 2286 RFC822.SIZE 457 FLAGS (\Seen) BODY[HEADER.FIELDS (From To Cc ... )] {215} 
> S-[Gmail]/All Mail:STREAM:OPEN Size: 457: Begin Message Download Stream
> mail data is downloaded

Current Gmail IMAP's behaviour with Auto-Expunge=Off was:
  If duplicated mail is uploaded, assign new UID to mail,
  and automatically deletes/expunges UID of dup mail.
It may be different if Auto-Expunge=On.

If Tb's problem like "loss of * 1905 EXPUNGE response"(Tb fails to remove mail of UID=2285), "misinterpretation of * 1905 EXPUNGE response"(Tb tries to remove wrong UID), duplicated mail should disappear by restart of Tb and first open of [Gmail]/All Mail, because UID/flags of all existent mails is retrieved again.
> 11 UID fetch 1:* (FLAGS) 
> * nnnn FETCH (UID uuuu FLAGS (NonJunk,...)) 
> 11 OK Success

Do you see duplicated mail in [Gmail]/All Mail even after restart of Tb?

Comment 24

[F.C.]

Thank you for the long answer. I hope I could understand correctly everywhere, it is well beyond a user level. :) I try to answer for everything, which also helps to make sure my interpretation is right.

(In reply to WADA from comment #21)
> (In reply to F.C. from comment #11)
> >   -Auto-Expunge OFF - Wait for the client to update the server
> 
> Perhaps it's the reason.

Let's check out.
My only concern is the following: I did not change this settings during the migration, it has been set this way from the beginning and I think if it would be (the only) issue the behaviour should be consistent, but as I see it is not the case: in about 90% duplicates were not created (the mail match was identified when migrating the 2nd (Sent Mail) folder) and the right label was added on the Gmail side. The issue only happened in the remaining ~10% when the mail match was not identified on the Gmail side and the mail got duplicated.

> 
> As you say following, you did mail copy between two Gmail IMAP account, Tb
> did (i) fetch from Gmail IMAP account-1, and (ii) append to Gmail IMAP
> account-2.

Exactly. The source mailbox (Gmail IMAP account-1) was quite full and the destination mailbox (Gmail IMAP account-2) is empty.
I started with copying account-1/[Gmail]/All Mail to account-2/[Gmail]/All Mail. As a result all the emails were appended correctly to account-2/[Gmail]/All Mail.

In the second step I started to migrate account-1/[Gmail]/Sent Mail to account-2/[Gmail]/Sent Mail. At this step I started to have the duplicates in account-2/[Gmail]/All Mail in about 10% of the emails, the target mailbox (account-2). Migrating the labels could not be finished as account-2 became full very soon according to the unwanted duplicates.

> > The copy was made between the 2 Google accounts being online with TB, (snip)
> 
> Gmail manages mails by X-GM-THRID, X-GM-MSGID, and adds X-GM-LABELS to a
> mail.
> X-GM-THRID, X-GM-MSGID, is unique value in Gmail system.

It is good to learn. Where can you see these unique IDs? Is it possible to see somewhere in TB or in Gmail Web UI? Or can it be only queried through IMAP (GM extension)?
Are these used any was in TB? Of course I understand this is not standard IMAP.
  
> (1) At Gmail IMAP account-1, a mail of following attribute is held.
>        X-GM-MSGID=1T1, X-GM-MSGID=1M1, X-GM-LABELS : FolderA, FolderB
>     At Tb's Gmail IMAP account-1, two mails are shown for the single mail.
>        FolderA : UID=1A1, Call mail-1-A
>        FolderB : UID=1B1, Call mail-1-B

If FolderA can be [Gmail]/All Mail and FolderB can be [Gmail]/Sent Mail this is exactly what I did originally.

> (2) At Gmail IMAP account-2, no mail data of mail-1-A(==mail-1-B) is held.
>     At Tb's Gmail IMAP account-2, 
>        FolderC : Highest UID=2C0 (FolderC=[Gmail]/All Mail in your case)

Exactly. Before first migration step [Gmail]/All Mail target directory was empty in Gmail IMAP account-2.


> (3) Copy mail-1-A in FolderA of account-1 to FolderC.
>      uid fetch 1A1 BODY[] at account-1/FolderA
>      append to account-2/FolderC
>      => UID=(2C0+1)=2C1 is returned.
>         FolderC : UID=2C1, Highest UID=2C1
>      => At Gmail account-2, following mail is generated in Gmail's DB
>            X-GM-MSGID=2T1, X-GM-MSGID=2M1, X-GM-LABELS : FolderC

I think this happened in the first migration step e-mail by email when migrating account-1/[Gmail]/All Mail to account-2/[Gmail]/All Mail.


> (3) Copy mail-1-B in FolderB of account-1 to FolderC.
>      uid fetch 1B1 BODY[] at account-1/FolderB  
>      append to account-2/FolderC
>      => UID=(2C1+1)=2C2 is returned, because UIDPLUS is supported.
>         For Tb, FolderC : UID=2C1

In the second migration step I migrated account-1/[Gmail]/Sent Mail (FolderB) to account-2/[Gmail]/SENT Mail, I think instead of FolderC FolderD would describe my original case. Does it make difference in finding the solution?
I guess you meant UID=2C2 in TB.


> (4) At Gmail account-2, following mail already exists in Gmail's DB for same
>     mail data and same Gmail Label, and it's re-used for "FolderC : UID=2C1".
>       FolderC : UID=2C1 == X-GM-MSGID=2T1, X-GM-MSGID=2M1, X-GM-LABELS :
> FolderC
>       FolderC : UID=2C2 == X-GM-MSGID=2T1, X-GM-MSGID=2M1, X-GM-LABELS :
> FolderC
>     Then delete of UID=2C2 occurs at IMAP server side.
>     This is similar to "delete of UID=2C2 by other IMAP client", perhaps
> except
>     that \Deleted flag is not stored in this case.

I see. So this is happening when Gmail identifies that the email already exists in account-2/[Gmail]/All Mail (according to Gmail's DB):
-re-using the already existing 2C1 in FolderC
-deleting of UID=2C2 occurs at IMAP server side.
Right?

If the copy is a bit different according to the migration step 2 as I did:
(MODIFIED_3) Copy mail-1-B in FolderB of account-1 to FolderD (meaning Sent Mail to Sent Mail in my case).
     uid fetch 1B1 BODY[] at account-1/FolderB  
     append to account-2/FolderD
     => UID=(2D0+1)=2D1
        For Tb, FolderD : UID=2D1

(I hope I modified the lines correctly.)
According to my understanding in this case Gmail also should recognize that the email already exists in FolderC ([Gmail]/All Mail) as Gmail always stores every emails in [Gmail]/All Mail. So if I understand correctly, 2C1 in FolderC is reused 
 and in this case 2D1 in FolderD should be also appended and not deleted in this case. Please let tme know if my thinking is correct.

> 
> (5) If Auto-Expunge=On, dulicated/deleted "FolderC : UID=2C2" is
> automatically
>     removed by Gmail, and removal of "FolderC : UID=2C2" is notified by
>     Gmail via unsol *EXPUNGE nnn (nnn=message sequence number).
>     And, for "uid 2C2 fetch", Gmail IMAP returns "UID=2C2 doesn't exist".
>     => "FolderC : UID=2C2" disappears at Tb.
>     This is similar to selective expunge of specific UID. 
> 
> (6) If Auto-Expunge=Off, removal of "FolderC : UID=2C2" is not automatically
>     invoked in Gmail IMAP.
>     => "FolderC : UID=2C2" still remains at Tb too.

I see the difference now in your example between Auto-Expunge=Off and Auto-Expunge=On. Let's see later if the Auto-Expunge=On.

I have a question here. If the copy happened in the 2nd migration step that I tried to describe in (MODIFIED_3) point above and Gmail can successfully identify that the email appended to FolderD ([Gmail]/Sent Mail) already exists in FolderC ([Gmail]/All Mail) than there is no deletion on the IMAP side as the appended mail is also needed in FolderD. Is it true? I think in this case the result should be like this in account-1 and account-2:

(Gmail IMAP account-1) as the source as you wrote
       X-GM-THRID=1T1, X-GM-MSGID=1M1, X-GM-LABELS : FolderA, FolderB
    At Tb's Gmail IMAP account-1, two mails are shown for the single mail.
       FolderA : UID=1A1, Call mail-1-A
       FolderB : UID=1B1, Call mail-1-B

(Gmail IMAP account-2) after the successful migration:
       X-GM-THRID=2T1, X-GM-MSGID=2M1, X-GM-LABELS : FolderC, FolderD
    At Tb's Gmail IMAP account-2, two mails are shown for the single mail.
       FolderC : UID=2C1
       FolderD : UID=2D1

I thing I have this result in about 90%.
Just let me know if I wrote something incorrectly.

In the remaining 10% I have a result with duplicate(s) something like this:

(i)(Gmail IMAP account-1) as the source as you wrote
       X-GM-THRID=1T1, X-GM-MSGID=1M1, X-GM-LABELS : FolderA, FolderB
    At Tb's Gmail IMAP account-1, two mails are shown for the single mail.
       FolderA : UID=1A1, Call mail-1-A
       FolderB : UID=1B1, Call mail-1-B

(ii) (Gmail IMAP account-2) when duplicate is created:
    2 emails on Gmail server in 2 threds:
       X-GM-THRID=2T1, X-GM-MSGID=2M1, X-GM-LABELS : FolderC (the original email)
       X-GM-THRID=2T2, X-GM-MSGID=2M2, X-GM-LABELS : FolderC, FolderD (the duplicate set with Sent Mail label)
    At Tb's Gmail IMAP account-2, 3 mails are shown for the 2 emails:
       FolderC : UID=2C1
       FolderC : UID=2C2
       FolderD : UID=2D1

The most annoying thing is that the result with duplicated emails cannot be corrected perfectly, the "duplicates free original" state cannot be restored with deletion:
(1) If the 2nd item is deleted from the duplicates (X-GM-MSGID=2M2/UID=2C2): from the IMAP point of view [Gmail]/All Mail folder will be identical to the source in the mail client, but the given item will disappear from [Gmail]/Sent Mail folder (like before having the Sent Mail folder migrated, not having the Sent label). 

(2) If the 1st item is deleted from the duplicates (X-GM-MSGID=2M1/UID=2C1): from the IMAP point of view [Gmail]/Sent Mail folder will be fine and identical to the source, only one instance will stay in [Gmail]/All Mail, but the related thread will be detached in Gmail due to a different X-GM-THRID. E.g. If the duplicated email originally was part of a 3 emails thread, it is going to be 2 separated thread with 2+1 emails.

> 
> Above (6) may be [Gmail]/All Mail only phenomenon, because \Deleted flag is
> not supported for [Gmail]/All Mail in Gmail IMAP. "uid xxx store +Flags
> \Deleted" is always ignored by Gmail IMAP if [Gmail]/All Mail.

I changed IMAP settings in Gmail: Auto-Expunge=On.
I did 2 tests with the modified settings:

(a) The same that I did originally and cause the initial issue: having duplicates in [Gmail]/All Mail when migrating [Gmail]/Sent Mail (in the 2nd step). I did the test with an email which were duplicated earlier, having no subject.
The result was the same, see above at point (ii)(Gmail IMAP account-2) when duplicate is created:". So switching Auto-Expunge=On did not help.

(b) Did the same 5 steps you suggested in Comment 8 with the duplicated email created in test (a) above (UID=111566):
(1) Move mail of UID=111566 (duplicate) to [Gmail]/Trash.
(2) Copy mail of UID=111506 (original) to local mail folder.
(3) Copy the mail in local mail folder to [Gmail]/All Mail.
    Result: duplicate created: UID=111567, .eml is 100 bytes longer with extra line: "X-Mozilla-Keys:".
(4) Copy the mail in local mail folder to [Gmail]/All Mail again.
    Result: duplicate created AGAIN: UID=111568, .eml is 100 bytes longer with extra line: "X-Mozilla-Keys:".
(5) Copy back mail in [Gmail]/Trash to [Gmail]/All Mail.
    Result: duplicate created AGAIN: UID=111569, .eml is identical to original email.

It seems to me that there was no difference in test result between the Auto-Expunge=On and Auto-Expunge=off settings.

> 
> Can you see duplicated mails by append of two identical mails to Gmail IMAP
> folder other than [Gmail]/All Mail, [Gmail]/Trash, [Gmail]/Spam, with
> Auto-Expunge=Off?

I focused on migrating the emails first in [Gmail]/All Mail first and than the labels afterwards, like [Gmail]/Sent Mail folder, [Gmail]/Drafts, [Gmail]/Important, [Gmail]/Starred, [Gmail]/Important and the user labels. As they were no duplicates in any folders in the source account (account-1), there were no duplicates in account-2, except in [Gmail]/All Mail in those cases where Gmail could not recognize the already existing message in account-2/[Gmail]/All Mail when rest of the labels/folders were migrated. If a problematic email had more labels in account-1, that e-mail is replicated in account-2/[Gmail]/All Mail as many times as many label it had in account-1.

After your question I tested it more, also with Auto-Expunge=Off. It seems to me that we always need to dived the cases into 2 categories:
(i) OK emails: where Gmail has no problems with recognizing if the email exists in the account-2. 
(ii) Problematic emails: where Gmail is not able to recognize if the email exists in the account-2. See the pattern about the subject I tried to identify in my first post. 

category (i): With OK emails everything works fine:
-it does not matter how many labels it has, it will be never duplicated in [Gmail]/All Mail or in any other folders. These emails have only 1 copy in [Gmail]/All Mail and you can find this email repeated ONCE in those IMAP folders which labels are assigned to it.
-I can even copy these messages several times to account-2/[Gmail]/All Mail from account-1 or even from the local folder (!), these will be never duplicated. The only thing happens the UID will be replaced from the actual value to the last UID+1. Now I understand why thanks to your explanation. It works perfect even with Auto-Expunge=Off, so the IMAP deletion which happens in the background does not cause problems.
If I copy these messages to any other IMAP folders, only the target folder label will be assigned and never duplicated in any folders, not even if the email already existed in the target folder.

Category (ii): problematic emails:
-Gmail cannot recognize these emails being already in account-2.
-These messages will be replicated as many times in account-2/[Gmail]/All Mail as many labels these have in account-1. E.g. if an emails has 2 labels in account-1, it will have 2 duplicates in in account-2/[Gmail]/All Mail additionally to the original email.
-I tested it more, over the migration I did. If I copy these problematic emails to any other folders it will duplicated in [Gmail]/All Mail for sure and if this email existed in the target folder than it will be duplicated there as well. E.g. If a copy a problematic email from account-1 to account-2/[Gmail]/Sent Mail folder for the 2nd time, at the end it will result in 3 copies in [Gmail]/All Mail and 2 copies in [Gmail]/Sent Mail:

[Gmail]/All Mail:
  1: original email
  2: 1st duplicate - created at the 1st copy to Sent Mail
  3: 2nd duplicate - created at the 2nd copy to Sent Mail
[Gmail]/Sent Mail
  1: original email - created at the 1st copy to Sent Mail
  2: 1st duplicate - created at the 2nd copy to Sent Mail

At normal working it only should have 1 instance in [Gmail]/All Mail and 1 instance in [Gmail]/Sent Mail, regardless how many times it is copied.
Right?

> If duplicated mails occur on other folder(ordinal Gmail Label), can you see
> "flagged \Deleted status" by "Just mark it as deleted" model?
> (Server Settings. If flagged as \Deleted, mail is shown with strike-thru
> line at thread pane)

As described above it can occur everywhere with the problematic emails.

Can it be related of managing no ("") subjects differently? Like "", no_subject, no-subject, no subject, etc. I am not sure if it is a smart question. :) I am just asking as majority of the problematic emails have no subject or are in threads with no subject or has just a few chars in the subject. It is interesting an email with "CV" subject is problematic, but a different one with also 2 char subject, e.g. "Ar" is fine.

> Do you see duplicated mail in [Gmail]/All Mail even after restart of Tb?
Restarting TB or compacting folders do not help, duplicates remain there and I can see them also on Gmail Web UI.


Please advice and let me know what else I can do.

Comment 25

[WADA:World Anti-bad-Duping Agency]

(In reply to F.C. from comment #24)
> Where can you see these unique IDs?
> Is it possible to see somewhere in TB or in Gmail Web UI?
> Or can it be only queried through IMAP (GM extension)?

It's by "through IMAP" only, if access from client PC. Read Google's document pointed in Bug 721316, please. If you can use tool like telnet-ssl, you can test GM extention manually.

Comment 26

[WADA:World Anti-bad-Duping Agency]

(In reply to F.C. from comment #24)
> At normal working it only should have 1 instance in [Gmail]/All Mail and 1
> instance in [Gmail]/Sent Mail, regardless how many times it is copied.
> Right?

Yes.
I couldn't observe duplicated mail in [Gmail]/All Mail nor [Gmail]/Sent etc., even when I uploaded mail data to which some additional headers such as X-Mozilla-Keys: are added.
(Gmail ignores non-essential header such as BCC:, X-Mozilla-Keys: in duplication check. See bug 450368 comment #4 for BCC: case)  

I could observe following phenomenon also.
  1. Upload your original mail in local mail folder(no Tb's tag) to [Gmail]/All Mail,
     add tag of Tb to the mail, copy the mail to [Gmail]/Sent.
  2. Move the mail to [Gmail]/Trash. Any copy in any folder(Gmail Label) is removed.
  3. Upload again your original mail in local mail folder(no tag) to [Gmail]/All Mail.
  => Mail in [Gmail]/Trash disappears.
     Mail uploaded to [Gmail]/All Mail has tag added at step 1.
     Mail appears again, with tag, in [Gmail]/Sent too.
  i.e. By upload again, Gmail IMAP execued "move back from [Gmail]/Trash to [Gmail/]All Mail".
     
Did you have original duplicated mail in [Gmail]/Trash when you did your test?

If No and [Gmail]/Trash was empty when you tested, I can't imagine other than bug of Gmail such as "uninitialized memory data use", bug in Gmail's IMAP related setting(e.g. When a message is marked as deleted and expunged from the last visible IMAP folder:), because duplicated mails with different UID was returned from your Gmail IMAP even after restart of Tb and first open of [Gmail]/IMAP.

Comment 27

[F.C.]

(In reply to WADA from comment #25)
> It's by "through IMAP" only, if access from client PC. Read Google's
> document pointed in Bug 721316, please. If you can use tool like telnet-ssl,
> you can test GM extention manually.

Thank you, I see. Are there any ways, TB Add-ons or any tools that would copy/set X-GM-LABELS also when copying emails between 2 Gmail account? In this case it would be enough to copy only [Gmail]/All Mail and duplicates I have could be avoided.

I will be able to do some further testing later today.

Comment 28

[WADA:World Anti-bad-Duping Agency]

(In reply to F.C. from comment #19)
> Created attachment 610317 [details]
> Screenshot of TB message list after 1st test

Binary compare result of saved eml files from [Gmail]/All Mail(FC /B on Win).
   UID=111555 == UID=111558, UID=111556 == UID=111557
What happens by next on dup mails in [Gmai]/All Mail and [Gmail]/Trash?

(1) Empty Trash at [Gmai]/Trash 
(2-1) Move UID=111555 from [Gmai]/All Mail to [Gmail]/Trash.
(2-2) Move UID=111558 from [Gmai]/All Mail to [Gmail]/Trash.
(3-1) Move back mail (UID was 111555) in [Gmail]/Trash to [Gmai]/All Mail
(3-2) Move back mail (UID was 111558) in [Gmail]/Trash to [Gmai]/All Mail
Is UID=111555 and UID=111558 are different mail for Gmail/Gmail IMAP?


(4) ove UID=111555 & UID=111558 from [Gmai]/All Mail to [Gmail]/Trash.
    Empty Trash at [Gmai]/Trash 
(5) Upload .eml file for UID=111555 to [Gmai]/All Mail.
    (Drag&Drop .eml file to thread pane of [Gmail]/All Mail)
(6) Upload .eml file for UID=111558 to [Gmai]/All Mail.
    (Drag&Drop .eml file to thread pane of [Gmail]/All Mail)
Is dup mail observed again?

In my test, if assigned UID=NNN at spep (5), UID=NNN automatically disappeared and UID=(NNN+1) appeared always.
It was also true in next test.
(8) .eml has "Subject: Re: Re: Re: Re:   ".
    Upload this .eml => "Re:" is shown at thread pane.
    Note: Subject at thread pane is obtained by fetch body.headers(... Subject
           ...). Gmail returns subject data after interpreting Subject: header.
(9) Upload .eml files of same data except "number of Re:" and new line character.
    - Number of Re: in Subject header : 0 to 4
      If number of Re: = 0, sumber of spaces : 0, 1, or 4
    - Newline character in .eml : CRLF only, LF only, CR only
By upload of any .eml file, UID was incremented by one, and Subject at thread pane was always kept as "Re:", and Viw/Source always showed "Subject: Re: Re: Re: Re:" which was initially uploaded at step (7).

Because data of partial multipart/alternative mail is seen in UID=111556/UID=111557, dup mail may be a phenomenon when error while uploading happens.
1. Gmail-Thread-ID=T1, Gmail-Message-ID=M1 is created for UID=N1 in [Gmail]/All
   by upload of mail data from IMAP client. And network error or something wrong
   occurs while uploading, then Gmail-Thread-ID=T1, Gmail-Message-ID=M1 is
   marked as Not-reusable. UID=N1 in [Gmail]/All Mail is not removed because
   error is not critical one, or timing related problem.
   (If timeout at Tb side due to server busy case, mismatch between status at)
   (server and status at Tb may occur, because of protocol named IMAP is used)
2. Same mail data is uploaded again, and Gmail-Thread-ID=T1, Gmail-Message-ID=M2
   is assigned to mail, and UID=N2 is assigned at [Gmail]/All.
As you say "two same mails in a Gmail's coversation(==thread) is seen at Gmail's Web mail interface, different Gmail-Message-ID is perhaps assigned by Gmail.

Comment 29

[WADA:World Anti-bad-Duping Agency]

FYI. Bug 735542 looks tryyng to access X-GM-LABELS.

Comment 30

[WADA:World Anti-bad-Duping Agency]

Attachment: Partial multipart/aternative of UID=111556 is complemented

(In reply to F.C. from comment #16)
> Created attachment 610313 [details]
> 2/4 emails from (UID 111555-111558) [Gmail]/All Mail folder (1st test)

Original file name = 20070308-no_subject-111556_1st_screwed_duplicate.eml
Phenomenon of "Dup mail with different UID in [Gmail]/All Mail" was observed by next test.
(1) Upload original no_subject-111556_1st_screwed_duplicate.eml.
    (partial multipart/alternative mail. No boundry for text/html part)
    Call mail-A, UID=A. 
(2) Upload attached .eml file.
    (boundary, text/html part, close boundary is added manually)
    => New UID=B is assigned. Partial mail of UID=A remained.
    Call mail-B, UID=B.
I this case, data shown by View/Message Source is different.

(3) Add a text line to 20070308-no_subject-111556_1st_screwed_duplicate.eml,
    and upload the modified .eml.
    => UID of mail-A is incremented.
(4) Remove close boundary line and CRLF after it from attached mail,
    and upload the .eml of "no close boundary".
    => UID of mail-B is incremented.
(5) Remove text/html part till end, exept boundary line for text/html part,
    and upload the .eml of "no data for second part".
    => New duplicate is generated. 
    Call mail-C, UID=C.

Decision on "dup or not of partially uploaded mail" is all up to Gmail.

Comment 31

[Wayne Mery (:wsmwk)]

Atul, is this effectively fixed in TB17 by Bug 721316 ?

Comment 32

[Atul Jangra [:atuljangra]]

Wayne, it should be fixed in TB17. But I would love if reporter can check it for us?

Comment 33

[Wayne Mery (:wsmwk)]

F.C. you can get TB17 beta at http://www.mozilla.org/en-US/thunderbird/channel/

Comment 34

[Wayne Mery (:wsmwk)]

(In reply to Atul Jangra [:atuljangra] from comment #32)
> ... I would love if reporter can check it [thunderbird 17] for us?

Comment 35

[Phoenix]

Resolved per whiteboard