
Transferring email to another account
I have set up two e-mail accounts, both GMail. I often need to transfer e-mail from one account to another within the client. Transferring messages from one account to another goes smoothly when they do not have attachments or when the attachment is less than 5MB in size When the message I move contains attachments weighing more than 5MB, Thunderbird crashes and the transfer does not happen. The only solution found, which I would like to avoid, is to download the message with a ‘'save as,’' then drag the .eml file to the right folder in the different account. I have checked and Google does not block the transfer nor are there any problems with quotas (I am a Google Wokspace administrator). Google support confirms to me that there are no blocks and that the operation should go smoothly. They suggest that I contact Thunderbird support. Is there a procedure or setting in the program that allows messages to be transferred smoothly from one account to another even when they contain attachments? Thank you
All Replies (9)
What you are doing is what I routinely recommend. When you copy IMAP messages, you are really downloading to PC and then uploading to the other IMAP account, yet IMAP was never designed for large uploads. The concurrent download and upload puts a strain on thunderbird. By separating the tasks, as you do with 'save as', you reduce the load.
Thank you David. Even if it is the procedure is correct and recommended, I would like to simplify it by making it possible to transfer the message directly into Thunderbird. For example, I tried changing the mailnews.tcptimeout parameter from 100 (default value) to 1000. No result. What I'm asking is: is there a way within Thunderbird, for example a different setup of the configuration parameters, to allow transfering of an email with attachment from one account to another?
What I am trying to communicate is that thunderbird is forced to deal with the internet connections to do what you want. Thunderbird sends the requests to the servers, but thunderbird cannot control the servers.
david said
What you are doing is what I routinely recommend. When you copy IMAP messages, you are really downloading to PC and then uploading to the other IMAP account, yet IMAP was never designed for large uploads. The concurrent download and upload puts a strain on thunderbird. By separating the tasks, as you do with 'save as', you reduce the load.
I am having the same problem while converting an Outlook account to Gmail account. Yet TB being the go to mail client cannot handle the transfers because it's too taxing, sounds like TB needs to beefed up. What software would you suggest we use if TB cannot handle it? Should we use Apple Mail, Microsoft Mail or Outlook Desktop? Let us all know so we can get on with the transfers. Thanks.
As I mentioned to the other individual, the email client tasked with the work isn't the problem; the problem is the immensity of the task at hand. Moving large amounts of data across the network to a protocol (IMAP) that was never designed to be the recipient, is difficult. The server is more likely to stumble than the email client.
Nearly the same problem with two Yahoo accounts. TB sometimes simply stops or starts to download the same folder again.
Are we talking about x000 emails as "large amount of data"? Or more? Or even less? Can we somehow measure it in GB in order to have e.g more smaller folders?
Thanks for sharing your ideas.
My original point in responding on this thread was to clarify that Thunderbird isn't responsible for internet performance. Actual network performance is above my pay grade.
David: can you please be more specific ... When we use TB/IMAP for downloading a big folder with 11 000 emails with attachments - say 5 GB in total - how it works in reality? How many passes it makes and when?
In my latest attempt it simply stopped after reaching 10 000. No workaround found including increasing the default tcp setting from 100 to 300 and even more.
Thanks for sharing your knowledge when badly needed.
Well, you could change the synchronization&storage to just sync most recent 30 days. All you need are the headers to retrieve other messages. If a large number are just history, those could be kept in a separate folder. The challenge we all face is that keeping everything in one folder puts a strain on all resources. Another option is to download history items. Another option is to pay for premium server support. Everything becomes a compromise. :)