Mozilla サポートの検索

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

詳しく学ぶ

このスレッドはアーカイブに保管されました。 必要であれば新たに質問してください。

Cannot send email

  • 32 件の返信
  • 4 人がこの問題に困っています
  • 6 回表示
  • 最後の返信者: Matt

more options

This is a problem that has been in thunderbird for years, thru many versions and reported by many, most recently here http://forums.mozillazine.org/viewtopic.php?f=39&t=3060830 and the reportees include me. It is an intermittent problem - does not happen often - but it is still going on (v68.6.0). The usual responses of disconnects passwords etc are simply ineffective, at least in my case. I've figured out some workarounds that do work, and I got so frustrated today that I trapped the screenshots (2), and attach them herewith: 1. pressing send - gets the login failed message (fail1 image) 2. pressing cancel - gets the send message failure panel (fail2 image).

By accident I found a way that worked, and with experience discovered there are others that also work without any recourse to changing smtp login data: workaround 1 - immediately press send again: frequently sends OK workaround 2 - save the message as draft, and then change the focus of TB to anything eg read a message in the inbox. Then select draft, open the message draft waiting there and press send: most often works. workaround 3 - save as draft, close TB, wait, re-open TB, open draft select the message there, and press send. workaround 4 - save as draft, close TB, re-boot the PC, open TB, open draft select the message there, and press send.

It seems clear that the issue is with TB in some way, it is beyond irritating and I cannot understand why after all the reports that have been made the TB coders have not isolated a cause and fixed it.

This is a problem that has been in thunderbird for years, thru many versions and reported by many, most recently here http://forums.mozillazine.org/viewtopic.php?f=39&t=3060830 and the reportees include me. It is an intermittent problem - does not happen often - but it is still going on (v68.6.0). The usual responses of disconnects passwords etc are simply ineffective, at least in my case. I've figured out some workarounds that do work, and I got so frustrated today that I trapped the screenshots (2), and attach them herewith: 1. pressing send - gets the login failed message (fail1 image) 2. pressing cancel - gets the send message failure panel (fail2 image). By accident I found a way that worked, and with experience discovered there are others that also work without any recourse to changing smtp login data: workaround 1 - immediately press send again: frequently sends OK workaround 2 - save the message as draft, and then change the focus of TB to anything eg read a message in the inbox. Then select draft, open the message draft waiting there and press send: most often works. workaround 3 - save as draft, close TB, wait, re-open TB, open draft select the message there, and press send. workaround 4 - save as draft, close TB, re-boot the PC, open TB, open draft select the message there, and press send. It seems clear that the issue is with TB in some way, it is beyond irritating and I cannot understand why after all the reports that have been made the TB coders have not isolated a cause and fixed it.
添付されたスクリーンショット

すべての返信 (20)

more options

What are your outgoing server settings? According to iprimus, it should be smtp.iprimus.com.au on port 25, connection security = none, authentication = password, transmitted insecurely, User Name = part of address before @.

Apart from using a mail service that doesn't offer secure connections, sending on this server on port 25 probably won't work if you're connected to a non-iprimus network.

more options

Not terribly helpful. I looked at the primus link you included, some differences: - I have IMAP set for the receive server not POP, but this should not make any difference to sending - the send smtp server is the same - port number is the same - authentication is normal password - connection security is STARTTLS - user name is correct

A non-iprimus network is the normal condition in Australia, as it is for every other ISP: they buy bandwidth from the national wholesale carrier who supplies the physical infrastructure. So your comment in that respect is not understood.

What irritates me is that 'send' using the currently set parameters works - most of the time. And I am not alone; a review the TB sites shows this has been occurring for a long while with a lot of different users: which does not speak to it being a single user or network condition. And when it doesn't work, a workaround re-set as described will fix it.

Is there a timing issue involved here - TB getting to the server too late or too early in the communication exchange??

more options

Usually Thunderbird is not in communications with the server at all. The anti virus product is. And they are buggy and rarely suspected because people don't see a dialog with Norton on it. I am to the point of suggesting to people just get rid of any third party product and use windows defender. What they don't put on their label is they slow the machine around 20%. So if you even suspect a timing issue. Something that slows your machine 20% is probably a good starting point.

  • Disable, any scanning of SSL/TLS communications. (some AV products appear to think email and the web are equally risky) if you understand what you are doing, Thunderbird makes email almost as safe as plain text documents.
  • Disable any outgoing mail scanning (a complete waste of time really, but fraught with issues when it goes wrong)
  • Ensure your temp folder is cleared regularly. (system tools on the start menu) When you running slow to start with having a few hundred thousand orphaned files in temp folder is not going to help at all.
  • Ensure you are using a currently supported operating system from your provider (reliance on AV product is not the same as having a secure system)
more options

Matt, Thanks for that. What made me think there was a timing issue involved was simply the discovery of workaround #1 previously posted. If I try to send again immediately I've cancelled the 2nd error box, it usually sends OK. There's clearly a suggestion here that the original send was "out of sync" but the 2nd one was in synch because of a persistence or timing lag somewhere. My point about TB issues is that with no changes at all in the smtp account settings or the password, when a send occasionally fails, I can can cause TB to work correctly by re-send, reset and re-send, or re-start and re-send. And the mode of failure being reported is the same by many users. Comment on your 4 points; 1. Really, same as point 2: there is no scanning on outbound mails configured to use STARTTLS, in fact no scanning of send mails at all. I've attached a screenshot of the AVG security setting for email, which I have not changed. What it does do is scan incoming mail. 2. see 1. above 3. I do this regularly - mainly to transfer mails I want to keep to a local folder, so I don't clog the ISP's mail server. Mails I don't want - eg advertising or out of date events - just get deleted and the trash emptied several times a week. 4. No, I'm running windows 7, as patched to the end of support date 20 Jan 20. I haven't upgraded to win 10 because frankly I tried 3 times and each time the OS broke something essential, a different something each time. After weeks of driver regressions , updates to various MS redistributables and software re-installs, I just gave it up: fault finding the OS isn't what I use a computer for. Win10 also gets upgraded to effectively a new version every 6 months and that causes lots of issues I note in the various websites. Whereas, windows7 is as mature and stable as it can get and from this year at least no longer subject to change, and it runs everything I need to use without any issues.

more options

What can I say, I offered some usage points, you know better. That is what happens when folks have to guess because you do not include full information.

Use the AVG VPN disaster. It caused mail problems https://support.avg.com/SupportArticleView?l=en&urlName=Troubleshoot-AVG-Secure-VPN-email&q=Troubleshoot+Secure+VPN+email&supportType=home

Have you lowered your security by accepting a dummy certificate https://support.avg.com/answers?id=9060N0000000alpQAA

Or the second last comment here https://support.avg.com/answers?id=9060N000000LmdfQAC

That requires the module turned of, not the outgoing mail not checked. I suggest you look over at AVG some more.

more options

Hi Matt, Thanks for continuing with this. Addressing your points: 1. VPN. I've never used one. What a VPN does is provide a closed circuit over intermediary links between end-points to prevent eavesdropping. The ISP internet access point has to know, because it provides the service. Activating a VPN between me and that device really hasn't seemed useful, and could be a hazard, because the VPN servers are more often than not international. Bottom line: there isn't a VPN active in my PC/internet connection, and never has been, so this could not be the source of this send issue. 2. Dummy certificates. The discussion in those links is all about receiving emails, not sending them. The users with those problems fixed them by turning off email scans, which is your 3rd point. 3. AVG Email scanner - is now turned off. This is how it presents now, in your face when the main AVG panel is opened; the settings email panel is similar. Main panel screenshot attached.

But since doing that I have sent emails, and the send issue is not resolved. To send mail, I had to use workaround 1: exit 2 warning message boxes and immediately re-send - and it goes.

So far, all the suggestions have not made an impact: I still think there are issued within TB that lead to this.

more options

I've been using the 'email scanner off' configuration for several days now. It hasn't solved the issue of send mail rejections, still occurring in about 50% of mail "sends". but it does seem to have improved the workaround response - using the immediate send again approach works.

So, there does seem to be some sort of systemic delay. And I get it whether I am using a "no security send" or a "starttls encrypted password" send. The latter I prefer to minimise mail hacks at the server level - which has happened in the past: specifically after the heartbleed issue some years ago, when many mail servers got hacked. I had issues then that could only be attributed to that.

Can you make any suggestions about slow processing of the login credentials exchange that could be improved by changes in TB options? Timeouts that could be lengthened?

more options

I would suggest you log SMTP sends and see if the actually log offers clues as the what is happening. https://wiki.mozilla.org/MailNews:Logging#Windows

I would also suggest you go to options > advanced >network and disk space, open the settings button and change the connection to no proxy from system proxy and see if that helps.

more options

Hi Matt, In reverse order, 1. No proxy - interesting for a mail app. I already use that for my firefox browser, and initially confused your remark with that. However, when the light bulb lit, I found that I'd been using a proxy setting in TB for a long time, maybe forever. Now changed.

2. The long bat file. Need some help here, because TB is not installed in the default location - where it is: E:\Thunderbird\thunderbird.exe. And because of that and the commentary in the link you provided I created a bat file whose last line is %DATA_EMAIL%\Thunderbird\thunderbird.exe where data-email is the name of the logical drive E. But it doesn't work. How do i change that last line to get it work??

Further question about the log file; is it created 'new' each time Tb is started, or does each new start for Tb append to the previous log?

more options

I would assume, based on the information you have provided the batch file would look like this

set MOZ_LOG=SMTP:5,timestamp
set MOZ_LOG_FILE=E:\SMTP.log
E:\Thunderbird\thunderbird.exe

I assume to have read write allocate access to the root of the E: drive in setting that location.

Log files are appended and grow very rapidly. so expect a lot of space used for not much action really. As each successful send will be included in the log with the data that makes up the email, large attachments and large mails make for a large log file.

I would suggest you delete the file after each successful send, you only interested in failure here.

more options

Hi Matt, Some results. 1. The 'no proxy' setting in TB doesn't seem to have improved things - TB still gives that send error about 50% of the time. It's still running with the AVG email scanner turned off. That doesn't bother me - the ISP has an AV scan on incoming mail at the mail delivery server level. When I finally get this sorted without the local scanner, I'll turn it back on and check the results.

2. I modified the imap log bat file as suggested, ran it, it worked. Whilst TB was open/logging, I answered one email (actually, I sent a query to a friend, he answered, and I replied) and the send refused, twice in succession (workaround #1 failed).

So I saved the reply as draft, backed out to an in-box and opened other mail to read (workaround #2 noted previously). That done, opened the draft, and it sent OK.

Closed TB, opened the log file: wow! Just that short activity generated 1mb of log data. I scanned thru it for the send refusals but could not make much sense of the data. It includes the text of the mails I opened, so I also attach a screenshot of the sent folder for today - just one at this time. However I can't attach the log file here - it's not an image. Renaming it as a .jpg did not work. Is there some way I can get it to you??? I am assuming you or a colleague can make some sense of it???

more options

Matt, No answer yet to the prior query, re interpreting the log. But I found a new workaround to the send problem, really a variation of one of the others. Simply choose save as draft first, then press send.

Despite the send: smtp login failure that looks like a corrupted password (that's what the message panel suggests - change the password), the various alternatives I have found clearly establish that there's nothing wrong with the existing password. Those alternatives seem to indicate that a shift of focus within TB before a send re-try is enough to get what ever is going wrong off its butt and working. The various changes in proxy and AV mail scanner you have suggested are still in place but have not materially helped.

Is there a support tech that can do a dial in analysis of the problem???

more options

So I figured out to fix the email in Thunder Bird. Yes you guys have no clue what your talking about. Took me less than a minute once I figured it out. I was unable after a week to get help from anyone , so I researched it myself. Bring up thunderbird, hit ALT A, go to tools then security, then passwords. You need to change the password with a security key off ATT and walla it will work! Have a great day!

more options

You will have to be a bit more specific about your fix: there's a few steps omitted. Changing a password (for send) here also means changing it on the (smtp) server, and that gets tricky to synchronise. And an explanation for just what is that ATT you mentioned would help???

more options

you have too create a security key with ATT .. Here is the link. You will also have to open up Thunderbird as it will bring you thru steps and how to enter the key once you get it. Make sure you write the key down for future use. https://www.att.com/support/article/email-support/KM1240308 Once the key is put into your passwords, you will have to close thunderbird and reopen. That is how I got mine fixed.

more options

joylee said

So I figured out to fix the email in Thunder Bird. Yes you guys have no clue what your talking about. Took me less than a minute once I figured it out. I was unable after a week to get help from anyone , so I researched it myself. Bring up thunderbird, hit ALT A, go to tools then security, then passwords. You need to change the password with a security key off ATT and walla it will work! Have a great day!

Actually we don't have a clue. That is because this is a change imposed by your mail provider A.T.T. or should I say Yahoo. Did you ask them how to fix their mess. Probably not. If past experience is anything to go by they will not know how to fix it. that is how their contract with Yahoo works, or doesn't. A.T.T. has no clue and get paid for their lack of knowledge.

more options

And if you live in the USA and your ISP is ATT/Yahoo, then I guess that may work. But I'm not in the USA, and ATT as an ISP is 15,000 Km away in another country. And nothing I have found in research so far suggests that my Australian ISP is in any way a problem here. The problem pretty clearly sits with TB - somehow.

I also found an informative article on the mozillazine site (closed??) about smtp connection errors here: [http://kb.mozillazine.org/Connection_errors_-_SMTP] and the image of the first send error message box that I posted - attached - seems to fit the description at login section of that article. It's certainly suggesting a password failure by recommending a change password action.

But I've repeatedly been able to verify within TB that the passwords are intact and correct, I have not changed them, and the various workarounds I have detailed clearly indicate that TB can successfully use them to send smtp mail in the right circumstances. When it fails, changing the focus (eg, from write to read an in-box mail) and then re-send usually works. The issue IS in TB, but how? I'm using supported connection methods within the account settings of the product - now version 68.7.0 (32-bit) on a 64bit win7 platform. What do I do to TB to fix it?

- Could the basic problem be the processor speed: too fast with a cpu (Intel core i3) @3.4ghz - since a slower laptop with a pentium cpu @2.4ghz with the same TB version doesn't seem to have the problem? - TB seems to have been stuck on 32bits forever, and it's been years since 64bit became the majority of installations. Is there a 64bit version of TB?

And before someone suggests upgrade to win10, I've tried that, 3 times using different upgrade methods, and each time it broke several things (different things each time) essential in my computing environment. One of the breaks was a TB profile save/import - failed. I'm not using a computer to be a windows 10 diagnostic technician, so after weeks of heartache and frustration eventually I gave it up. Win7 runs everything fine, it's stable and after 10 years of supported updates, it's better and more reliable than win10 in that respect.

???

more options

So Dave, isn't there someone on TB who can help at all? I see alot of frustration on here with some. Not ok. They should have for all countries to get the help if it is different. What I posted isn't changing the password for you log in, it is changing the password to the server to add a key. I don't understand why this won't work for you but I hope you find a way or someone on here can help. Mozzilla should be able to help if they care about their website etc. Good Luck and have a great day

more options

ok, lets just get back to the real issue.

Davik, The user name is given as file13. is that really your iprimus user name? So you have a file13@iprimus email address? It just looks wrong to me.

Davik03 Question owner said

However I can't attach the log file here - it's not an image. Renaming it as a .jpg did not work. Is there some way I can get it to you???

Email it, the address is in my profile, click my name

Yes there is a 64 bit version, I use it. But while it is in the release channel I do not recommend it. It has issues with MAPI, so sending mail from the windows menus and other applications is a nightmare.

I'm not going to debate windows 10 Vs Windows anything else. I was happy with Windows 7 but I was happy with windows 2000 and NT and windows 3. I have had to move on, but usually a new computer is the impetus for a new operating system.

more options

Matt, Yes, file13 is a valid email address. I have several others, all but one with iprimus, which I try to use for various content types/organisation. The non-iprimus address is with gmail and I use it for - basically - receiving messages from my mobile phone. That the smtp send error occurs on all the send accounts used by TB, but I've focussed on just the file13 address for this topic.

Thanks for the address for the log - I'll send it after I submit this.

  1. 1
  2. 2