Email send failure 75 - Socket Error 0x0 when testing email settings

[pimjoosten]

In both v3.56 and v3.57 I get the error message “Email send failure 75 - Socket Error 0x0" when testing the Email settings using the Test button. Strangely however, emails are always correctly sent when an image has completed. It seems that somewhere along the way in one of the updates since v3.34 the testing function got broken. When I installed v3.34 I set the email settings and have never changed anything since. Only now when I wanted to change the settings did I notice this. When I restore an image from November 2019 with v3.34 installed the test function works fine.

I have observed this on 3 different systems, all with Windows 7 (x64 or x86), although I only tested going back to v3.34 on one system.

[TeraByte Support]

Not seeing any issue. Double check your settings match any command line operation you're using that works.

[pimjoosten]

Thank you for checking. After reading your reply I re-entered my password and voilà: it works. I don't know what happened, I am not aware that I ever changed my mail password. I do see that there are now more characters in the password field than before, so apparently the password must have changed. I likely must have done something I forgot about on all 3 systems. Normally I would record such a change in my log or remember it.

Thanks again and apologies.

[pimjoosten]

Well, it now turns out it was not something I had done, but it seems that a bug was introduced with IFW v3.48. This error occurs since v3.48 when sending email using a stored password for the SMTP-server. That is the reason why in my previous post I thought that my password had changed. I apparently had forgotten that I used a stored password, which is shorter than the actual SMTP-password.

I started investigating this when I wanted to set a new stored password using v3.61a, which gave me the same error when testing. I then installed older versions, keeping the same stored password, to see in which version it still worked and in which it did not. In v3.47 I do not get the “Email send failure 75 - Socket Error 0x0" message, but after updating to v3.48 I do. It does not only happen when clicking the Test button, the error message is also included in the log when an image has been made.

[TeraByte Support]

Version 3.42 – December 17, 2020

* Obsoleted /cp (CodePage) option and added support for a new registry DWORD value CodePage at HKLM\SOFTWARE\TeraByte Unlimited\Image. Note: If you have any problems with stored passwords or characters in general creating the value as zero will revert the codepage to match what prior versions used.

Otherwise you'll have to change your password and send support the password exactly as you were using to see if there is a character encoding causing some type of issue.

[pimjoosten]

Thank you for your fast reply. I had already read the update history, including the changes in v3.42. At first I also thought this was the likely cause and therefore I specifically tested v3.42, besides other versions. Version 3.42 did however not have any issue. Nevertheless I tried adding a new DWORD registry key with value 0 for CodePage at HKLM\SOFTWARE\TeraByte Unlimited\Image, but that did not solve it.

Thinking about your other suggestion I then wanted to test whether it perhaps has something to do with the combination of a stored password and an SMTP password, because I did not really feel like changing my regular email password.

First I tested whether the stored mail password (in my case {#SMTP *****#} ) could be used for encrypting an image and then restoring it. I used {#SMTP *****#} when making the image and for restoring I used the underlying password of the stored {#SMTP *****#}. That worked.
The conclusion is that the stored {#STMP *****#} can be used for making an image, but not for sending emails. Note that I added {# and #} here, but of course I did not enter them on the Password tab. Also note that I used ***** in the password above to not fully reveal my stored password, but that they are actually alphanumerical characters.

I then tested whether a different stored password would also fail, so I made an extra mailaccount with the password terabyteunlimited. For this account I then created the stored password {#test#} I could send a test email using terabyteunlimited as the password, but not when using the stored password {#test#} This confirms my suspicion that a stored password does not work with email anymore and also that it does not seem to be related to specific characters used in the password.

If you still want me to send an email to support let me know. Because I do not need to send a password, since the issue is not related to a specific password, I thought it was best to add my findings here.

[TeraByte Support]

what's your email line in the .ini file look like? Also show the one from the run (add /logl:11) and then look in the .log file for the email command line option being used.

[pimjoosten]

Thanks again for your fast reply and my apologies for my late reply. I had to solve some other issues first, before I could do some more testing.

The email line in ifw.ini is: Email=smtp.freedom.nl*test@abcde.nl*test@abcde.nl*Image for Windows rapport Convertible*T587*test@abcde.nl*{# hex value #}, where "abcde" replaces the actual domainname, and “hex value” replaces the obfuscated password. The /email options in the log file after making an image with the option /logl:11 is identical to the email line in ifw.ini: /email:"smtp.freedom.nl*test@abcde.nl*test@abcde.nl*Image for Windows rapport Convertible*T587*test@abcde.nl*{# hex value #}" .

I have done some more tests which show some noteworthy results. First, I restored an image from November 2019 with IFW v3.34 installed and {#SMTP ****#} as the stored mail password. I then step by step updated IFW with one version at a time (or two if I did not have the installer for next version). Again, I found that v3.47 did not throw the error, but v3.48 did, but only when testing the email settings. Emails were still sent after completion of a backup. However, after I changed the stored mail password to {#test#} the “Email send failure 75 - Socket Error 0x0” also occurred after making an image. This error persisted after going back to {#SMTP ****#} as the stored mail password.

I have observed this error on several computers with v3.61a, but I only tested downgrading on one computer.

[TeraByte Support]

I still not clear what you're saying. If you create a new password named xyz, then use {#xyz#} you say the test works but after backup doesn't? Is it the same user profile/id running that created it and that is running the software? they have to be the same or it won't work.

Also what characters are you using, what if you test with a password "test123X" ?

[pimjoosten]

I will try to give a more detailed and step by step explanation.

(1) In v3.47 using a stored password as the SMTP password works without any issue. The stored password is named SMTP password which I have entered in the password field on the Email tab of Settings as {#SMTP password#} The actual password contains alphanumerical characters as well as the characters @#<)>(* This has been the setting since I started using IFW v3.34 several years ago, and it kept working well after every update up to and including v3.47.

(2) If I then update to v3.48 keeping the same stored password {#SMTP password#} the test function throws the “Email send failure 75 - Socket Error 0x0” error, but after making a backup the completion email is sent without error.

(3) If I then add a stored password on the Password tab named test where the actual password is “terabyteunlimited” and enter that stored password as {#test#} in the password field on the Email tab of Settings and also change my mail account to an account that has “terabyteunlimited” as its password, then not only does the test function throw the error, but it is also included in the log when a backup has been made and of course no email is sent.
The mailaccount works correctly, because when I do not use a stored password but directly enter the mail password terabyteunlimited in the password field, the test mail is sent without problem.

(4) If I then try to return to the previous stored password named SMTP password by entering {#SMTP password#} in the password field on the Email tab of Settings and change the mailaccount back to the one for which the underlying password of SMTP password is defined, to check whether it restores the behavior under (2) it does not. The behavior is the same as under (3), both testing and the completion mail throw the error.


The behavior of v3.48 is the same in v3.61a and I have observed it on several computers (Win7 x86, Win7 x64, Win10 x64), although I only checked with which version it started to occur on one computer.

I am using the same user/profile id for creating the password and running IFW.

Because I can use {#SMTP password#} to encrypt my backups without problem (I can restore them using the underlying password), it seems that there only is a problem with using a stored password for sending emails.

I hope this is helpful.