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

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Michael Eilert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.9.2.15) 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
2. 
3.

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

[Michael Eilert]

Attachment: Doc-file with screenshotd tb, linux server conf & server rlogs

Comment 2

[Michael Eilert]

Attachment: content of mail.warn

Comment 3

[Michael Eilert]

Attachment: TB logging while sending 2Mb email without errors & duplicates

Comment 4

[Michael Eilert]

Attachment: only a textfile with downloadpath of bigger tb-logfiles

Comment 5

[Wayne Mery (:wsmwk)]

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 ?

Comment 6

[Michael Eilert]

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

[Wayne Mery (:wsmwk)]

thanks