The Email Sender app only works when I don’t use an encrypted connection.
Without encryption the test works. With encrypted connection the test gives this error :
“Error: Error: 1996128256:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:…/deps/openssl/openssl/ssl/s23_clnt.c:827:\n”
The SMTP server I’m using is from Office 365.
Anyone an idea on how to solve this? I don’t want to use an unencrypted connection.
You could try a different port, maybe 465.
I don’t have a O365 account to abuse at the moment, but using encryption seems to work fine for me on port 25 and 465.
It does not work on port 587 which you may be using (since consumer ISPs tend to block port 25 outbound). I’m not sure why yet, but I don’t think I disallowed STARTTLS on port 587, so the app might be to blame for that.
O365 does not use SSL/TLS. It uses STARTTLS.
And it only uses ports 25 or 587. No 465.
As I have a business account my ISP doesn’t block anything.
I tried ports 25, 465 and 587, encrypted and not. It only works without encryption.
It looks like it wasn’t actually using STARTTLS on port 25. I just assumed it was, because port 465 is the only standard(ish) SMTP port that assumes TLS. I captured some network traffic however, and the app starts spewing incomprehensible binary junk right away, when the checkbox is checked.
I guess my Exim4 server was just smart enough to think “hmm, this doesn’t look like a plain text command, maybe I should try interpreting it as an encrypted connection… hey, that works!”
There’s some good news though. I looked through the documentation for the library that the app is using to actually do the mailing; even if you do not check the box, STARTTLS will be used as long as it’s advertised by the server: https://nodemailer.com/smtp/#tls-options
I verified this by capturing the handshake part of the conversation:
< 220 AM4PR07CA0003.outlook.office365.com Microsoft ESMTP MAIL Service ready at Wed, 26 Feb 2020 21:11:20 +000
> EHLO [127.0.0.1]
< 250-AM4PR07CA0003.outlook.office365.com Hello [xxx.xxx.xxx.xxx]
< 250-SIZE 157286400
< 250-PIPELINING
< 250-DSN
< 250-ENHANCEDSTATUSCODES
< 250-STARTTLS
< 250-8BITMIME
< 250-BINARYMIME
< 250-CHUNKING
< 250 SMTPUTF8
> STARTTLS
< 220 2.0.0 SMTP server ready..
The only downside is that it’s a bit too voluntary for my liking. If for some reason, O365 would decide to not advertise STARTTLS, the app would happily send stuff “in the clear”.
Assuming someone could intercept your network traffic, it’s reasonable to assume they could do a MitM attack and just forget about that little line advertising STARTTLS, and presto.
If someone were to do this, you might get lucky and the app might not find a supported method to authenticate, as simple username/password authentication schemes are refused over unencrypted connections and several other standard authentication schemes also seem to be refused by O365.
Major bummer I ran into though: even though STARTTLS will be used, there doesn’t seem to be much certificate checking going on. I intentionally used a different host name than my mail server certificate is for, the the app doesn’t care. Sends its stuff anyway. So: no protection from MitM attacks whatsoever, only from casual readers with access to your local network that you could possibly deter.
You may try to install from https://github.com/jordenc/email-sender
Edit app.js en change rejectUnauthorized: false to rejectUnauthorized: true
This should make sure it checks the validity of the certificate versus the hostname. I actually turned it off by default because many people used to use invalid certificates for the hostnames, perhaps I should now turn it on by default.
