I have been using E-MailRelay (version 1.9) on a Windows 7 computer for a couple of years to get emails out (to smtp.office365.com or smtp.gmail.com) from devices that can't do TLS. It worked flawlessly. I recently tried to use it on a Windows 10 computer for the same purpose. However, I am getting errors in the event viewer application log. It will work fine for several jobs, but then I will start to see:
emailrelay: warning: winsock select error: 10053
I may get several of these, and the emails still go through. Then, I will get the following two errors in succession:
emailrelay: warning: exception: dns error: smtp.gmail.com:587
emailrelay: error: polling: dns error: smtp.gmail.com:587
When these errors occur, the emails do not go through. The only thing that gets E-MailRelay to start working (temporarily) is a reboot. I don't seem to have any luck stopping and starting the service. Is E-MailRelay compatible with Windows 10, or is something else going on. Please let me know if you need anything else to go on. Any information you could provide would be appreciated. I hope there is a solution because this program has served me very well in the past. Thanks.
I've reworked a lot of the relevant code for 2.0, so please let me know if you would like to beta-test, or just wait for the 2.0 release.
Thanks for the reply, and thanks for the software. Whatever the field, people like you are very appreciated for taking the time to provide something helpful. I will try the 2.0 beta and let you know if it fixes this problem or has any new ones.
Please give this a go:
https://www.dropbox.com/s/dvevkx1jvtmua09/emailrelay-2.0beta-w64.zip?dl=0
sha1sum: 65b82a478242da92f00b726fb1e76fb301e38bda
Thanks. I'll keep you posted.
I installed the beta. Whenever an email gets sent to E-MailRelay, it does not get relayed. The event log has two entries:
emailrelay: info: smtp server on 0.0.0.0:25
and
emailrelay: info: smtp server on ::.25
I don't know if this helps but here is the bat file line that indicates my settings:
start "emailrelay" "C:\Program Files\E-MailRelay\emailrelay.exe" --client-auth C:\ProgramData\E-MailRelay\emailrelay.auth --client-tls --close-stderr --forward-to smtp.office365.com:587 --log --pid-file C:\ProgramData\E-MailRelay\emailrelay.pid --poll 1 --spool-dir C:\ProgramData\E-MailRelay\spool
Please let me know if there is a setting I need to change or you need any other information. Thanks.
If that's all that's in the log then it is not being used; if anything connects to it it will log "smtp connection from...".
I common problem I have in testing is that I have an old process running that is listening on the same port and it steals the traffic from the process I want to test. So please run "netstat -an" from a command prompt and check that there is only one LISTENING line for port 25, and/or check the windows task manager for unexpected emailrelay.exe processes, and/or check the system tray for multiple envelope icons.
Please also add "--verbose" and "--log-time" to the batch file command-line, and I recommend using "--log-time c:\programdata\e-mailrelay\log.txt" rather than fiddling with the windows event viewer.
Also, stop the emailrelay service, if any. For testing it is easiest to run the batch file by double-clicking on it, and then check the system tray for the envelope icon and 'type' the contents of the --log-file file from a command-prompt.
I found out what I was doing wrong. I didn't have "allow remote clients" enabled. Now it relays the email, but I do get this warning in the event viewer:
emailrelay: warning: tls: ssl_tls.c(4587): x509_verify_cert() returned -9984 (-0x2700)
I didn't enable verbose logging yet. If you don't have a quick answer to this warning, I will enable verbose to try and find out what is going on. That aside, I will let this run now and see if it stops relaying emails like the problem I had with version 1.9. I look forward to you suggestions and thanks again for the time and effort!
That warning comes from the TLS library (mbedTLS) and it indicates that the TLS layer is not fully authenticated. In most use cases you would use SMTP rather than TLS for authentication, with the TLS layer used only for encryption. These non-errors from the TLS layer are rather annoying because they are logged at the same level as real errors, so they cannot be suppressed easily.
Well, it has been a week, and the problem seems to be gone. All emails are being relayed without issues. I'll keep you posted if any problems arise.
Thanks for beta testing; v2.0 is now released.