mail.com email that I send via Thunderbird is fine until I attach anything, I end up with slow transfers, timeouts, multiple transfers, multiples in sent email
I have a MacBook Pro running El Capitan 10.11.5. Thunderbird is 45.2.0. I run AOL and BT accounts through Thunderbird without problems. I have 2 Mail.com accounts and they both suffer the same problem. They both were also prone to putting all incoming mail into the spam folder but i seem to have ironed that one out. The problem may be that mail.com offers me 'mail.com via POP3 & IMAP', then tells me it's a premium feature and will cost something like 25 dollars a year (however, I can't have this feature anyway as England isn't supported!) I let thunderbird automatically configure for the 2 mail.com accounts - I wonder if this may also be part of the problem? Thanks all!
כל התגובות (7)
mail.com show their SMTP settings as Outgoing: Server: smtp.mail.com Port: 587 Encryption: STARTTLS
Is that what you have in Thunderbird. I am not a customer so have no iea what the wizard comes up with. but looking at the database it uses I think it will be selecting SSL
Many thanks for getting back to me Matt. The way I have my BT account set up within Thunderbird (and, hopefully my mail.com accounts) means that I also have a copy saved on my laptop (somewhere), should anything go wrong. Your post shows different settings to the ones I have. I've attached my server settings and advanced server settings screenshots. If I go for the settings you mention, does this mean I lose my laptop copy, but will probably get rid of the problems I originally posted? Hope that makes sense. Thanks again.
You started off talking about trouble with sending, and Matt has given you settings for outgoing mail, but you have shown us settings for incoming.
Open Account Settings, go down to the last item in the list of accounts, "Outgoing Server (SMTP)" and check what it says there for mail.com.
Apologies guys - it's just something that baffles me, luckily not yourselves. Screenshot below.
As Matt predicted, you were set up to use SSL, and in contradiction to the suggested settings on their own site. Having said that, they seem to be quite liberal and it appears they'd accept a connection using TLS or SSL on 465.
But none of this explains a connection that works only until you send a sizeable attachment; you do get a connection, so your settings are working, after a fashion.
I think I'd start by changing those outgoing settings. Just keep your screenshot to hand so you can come back to your current settings if necessary.
I'm thinking about other adjustments that have been known to change the behaviour for large messages, but the one I have in mind is at the network interface and so would affect all accounts - but your non mail.com accounts are working, so that network card setting must be doing the right thing.
Hi Matt / Zenos, I changed the settings as per Matt's suggestion, restarted and there's a fix of sorts there. Normal email without any attachments goes through faster. At a guess, about 25% faster. However, I've just sent an email with a 3mb attachment (I have a broadband speed of around 7mb), it took forever (couple of minutes?) to send it, then it took forever (90 seconds) to save it to 'sent items', then it tried to send it to 'sent items' again, and conked out half way through. However, the email was received, and a copy is in my 'sent items'. Baffling.
With a 50Mb limit per email, It is not size. That is unless you only send attachments of size through Mail.com.
Another possibility is anti virus. Something mac users are learning about and those with mail clients usually have a baptism of fire. Got an anti virus?
in your account setting go to copies and folders and set the save of sent mail to sent on local folders then send an email. Does a copy appear in the sent folder of the account anyway? Google and Hotmail both add sent mail to the sent folder as it passes through their outgoing server. I can see nothing for mail.com but from what you have said it sounds like they might be doing it as well.