All users were logged out of Bugzilla on October 13th, 2018

moving sent emails with big attachment to SENT folder seems to fail but causes duplicates



8 years ago
6 years ago


(Reporter: info, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: {has protocol logs])


(4 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv: Gecko/20110319 Firefox/3.6.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv: Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9

We face actually several problems, that have to do with moving mails to folders.
- Regulr action of sanding email with attachment of more than about 10 MB, sending is OK, but the automatic action of saving the email in sent folder need much more time time than the sending action to same server, twice or 3 times tb says he's logging in, then complain "saving to sent folder failed, do you want to retry" if user cancels, then at least 2 dups of the email are in sent folder, if he says "retry" , up to six duplicates are saved to sent folder. this can be exactly reproduced.

may be there is some conflict with the auth method, that would explain why tb several times says "sending login data ..." (german "sende login-daten ...")

- deleting (= move to Trash), archiving (move to Archives/20xx ...) or manually moving (on folder to the other of the same account) of more than about 1000 up to 6000 mails causes the imap server to show massive overload and causes up to 6 duplicates of every email in the destination folder and to the mails in the source folder are still there. I could not reproduce it with 5000 mails, i think becuase they were to small (1kb text).  

on the server we use dovecot 1.0 (with ldap auth to ads domain) potfix, openldap


Reproducible: Always

Steps to Reproduce:
1. send email with attachment > 8 MB to anyone or yourself

Actual Results:  
multiple (2-3) duplicates of the sent email are saved to the sent folder.
At 8 MB without warnings or error 

If the attachment is bigger than 12 MB , additionally tb says he couln't save to sent folder....

Expected Results:  
only the email ist saved to the sent folder and no dups

The users receive many big emails, several times the mail comunication was down, rebooting the server didn't help every time. Wehave to solve the problem or completely change the mail-configuration (other groupware ...)

I manually allready had to remove about 120000 mail duplicates.

I collected some more information, because i can see lots of unconfirmed existing bug reports about this problem. for example bugs 541669 227995 359847 618553 610131 ...

I can upload (or provide for download) logs of about 60 MB (TB -logging ,  tb screenshots, server logs, server config, of my reproduction actions.

I tested in the same environment with several other email clients (opera , eMClient, pegasus, ) they all need their time for these actions , but don't complain about errors and don't cause any duplicates.

Comment 1

8 years ago
Created attachment 527949 [details]
Doc-file with screenshotd tb, linux server conf & server rlogs

Comment 2

8 years ago
Created attachment 527950 [details]
content of mail.warn

Comment 3

8 years ago
Created attachment 527951 [details]
TB logging while sending 2Mb email without errors & duplicates

Comment 4

8 years ago
Created attachment 527952 [details]
only a textfile with downloadpath of bigger tb-logfiles
Component: General → Networking: IMAP
Keywords: perf
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Whiteboard: [has protocol logs]

Comment 5

6 years ago
Michael, does this still reproduce?

why do you think your issue is not one of bug 541669, bug 227995, bug 359847, bug 618553, bug 610131 ?
Severity: critical → major
Keywords: perf
Whiteboard: [has protocol logs] → [closeme 2012-07-15][has protocol logs]

Comment 6

6 years ago
High Wayne,
no, I can't reproduce, since I removed the eSata-Device.
It would take me to many hours to rebuild the old configuration (Linux mailserver with esata raid) only for tesing purposes.
May be the solved Bug 538378 is partly this issue, but it's like a puzzle. I still think , there is some other reason, that has not yet been found.

In our case all the problems with the duplicates and Thunderbird hangs disappeared, after we replaced the extern eSata Buffalo Raid - System by a simple internal hard disk within our ubuntu 8.04 LTS dovecot-postfix-Mail Server. 

In some linux newsgroups there was a problem reported with linux eSata-Drivers, but I don't know any details.

Since that change no more overload situations within the mail server or the TB-Clients happened.
So I draw the following conclusion: It was the combination of Thunderbird and the esata raid within the server, that caused this behaviour. No other mail client caused these duplicates, other mail clients got relatively slow when moving mails, but finished the way they should. Thunderbid must be using any parameter within the server that was not reliable. May be this helps to reproduce this strange behaviour.

Comment 7

6 years ago
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2012-07-15][has protocol logs] → {has protocol logs]
You need to log in before you can comment on or make changes to this bug.