Solving Unusual SMTP send fault
I have an SMTP sending Password not recognised issue with setting up Thunderbird account. I have worked through solution docs on the web support in this regard to no avail. All my server config settings with my ISP are correct and Thunderbird is fully authorized through Windows defender . Here is what happens and how I have been able to get it to work (after many trial and error attempts in getting Thunderbird to work on 20 x Windows 10 tablets) Installing Thunderbird 68.1.0 and configuring pop3 and smtp account settings always fails smtp password validation - email can be received but not sent. Uninstalling Thunderbird, deleting system User app data, rebooting and reinstalling the same version (Thunderbird 68.1.0) and recreating email account does not resolve the issue. Installing the latest install package Thunderbird 68.1.2 results in precisely the same failure… However if once I have installed the later 68.1.2 package, with a configured email account (which fails to send) then uninstall 68.1.2, and then reboot and reinstall the earlier install package 68.1.0 – immediately before the configuring email account window pops up - the message is presented that “a more recent profile version exists, … do you want to set up an earlier version profile (note - not verbatim here) and if choose yes (choose to accept an earlier version profile), then when I configure the email account Thunderbird sends and receives ok. Once sending email is working ok, the subsequent automatic online update that Thunderbird does itself does not break the successful settings. …It has taken many hours to get this to work since all the online help solutions presented have not solved it. Can anyone tell me if I am missing something here and could there be an easier (quicker) way through this smtp config perplexity?
Wšykne wótegrona (4)
Do you have the TB profile folder added as an Exception in Windows Defender? The default location is:
C:\Users\<winusername>\AppData\Roaming\Thunderbird\Profiles\8charstring.default
Somehow, I think the Encrypted password authentication, which is what they recommend, and is fairly uncommon, is related to this issue.
Wót sfhowes změnjony
Thanks very much for your comment.
Tried the exception statement it but did not resolve the issue.
I am now suspecting it has something to do with how TB maybe initiatialising communication with the mail server on the very first account that is setup on TB, because I am now finding that if I setup a unique email address on the server that is not similar to other email accounts on the server then TB has been setting up the account smoothly and communicating sending and receiving.
However If I am using an email address on TB that is part of a set sequential closely similar email addresses existing on the mail server (eg. with serial email addresses such as ax01@xxx.xxx then ax010@xxx.xxx, ax011, ax012, ax013 for example, then TB has initialising configuration issues every time communicating with the mail server ok and has a send smtp communication failure issue (error message given is that the password is not correct or the account details are not configured correctly .
I cannot work out if this is a mail server issues or TB issue...
But If I then I remove (delete) the first email address account that failed on TB and set up a completely unique email address on the server and on TB then TB smoothly establishes reliable communications ok... (go figure!!). Once this communication is working ok with the server, then I find I can return and set up email accounts on TB even if the email addresses are closely resemble any series of account names on the mail server
So my conclusion is that using a unique email address that has no similarity to other email addresses on the server settles the new installation of TB somehow, because then if I remove that unique working email account on TB and set up a new account which then is part of a close series on the mail server, then the TB account sets up smoothly and establishes smtp coms with the server account with no issues.
This latter discovery seems to be working more reliably for me now than my install /uninstall /reinstall strategy I described in my initial post above which has proved to be a hit and miss - so it is quite confusing what the issue actually might be.. but its what I am finding at this point.
Wót support22 změnjony
Your provider DOES NOT recommend encrypted passwords. Perhaps try disabling that as if they supported it they would say so. Plain text would be the best practice usage here. The SSL/TLS encryption will handle communications.
https://helpdesk.freeparking.co.nz/index.php?/Knowledgebase/Article/View/435/3/general-email-faqs SMTP
Outgoing SMTP server host name: mailx.freeparking.co.nz Secure/Encrypted Connection: Enabled for SSL or SSL/TLS Port number: 465 or 587
Username and password authentication: Enabled and using the same username and password as for the incoming server.
Matt said
Your provider DOES NOT recommend encrypted passwords. Perhaps try disabling that as if they supported it they would say so. Plain text would be the best practice usage here. The SSL/TLS encryption will handle communications. https://helpdesk.freeparking.co.nz/index.php?/Knowledgebase/Article/View/435/3/general-email-faqs
According to this page, the authentication should be Encrypted password. It would not be the first time a service provider gives conflicting instructions.