Computer Nerd Kev Posted July 25, 2020 Posted July 25, 2020 Hello,I've come to the conclusion that the non-SSL SMTP email port on Tommy doesn't actually work without SSL (aka TLS).The background is that some of my Email software is old and when Tommy was upgraded after the crash, the new encryption libraries were no longer compatible with my old software. I've been slowly working to get that software working with a newer OpenSSL library, and making do until then in various ways.I recently set up a new email account (using a unique password) for which security isn't very important, so I tried going unencrypted using the non-SSL port for SMTP (587 on Tommy). But it wouldn't work.Long story short, the email server software isn't providing any authentication methods to the client unless STARTTLS is used to enable encryption.Here I'm trying to connect without SSL: <-- 220-tommy.heliohost.org ESMTP Exim 4.92 #2 Sat, 25 Jul 2020 05:38:10 +0000 <-- 220-We do not authorize the use of this system to transport unsolicited, <-- 220 and/or bulk e-mail. --> EHLO heliohost.org <-- 250-tommy.heliohost.org Hello heliohost.org [1.136.169.170] <-- 250-SIZE 52428800 <-- 250-8BITMIME <-- 250-PIPELINING <-- 250-STARTTLS <-- 250 HELP --> QUIT <-- 221 tommy.heliohost.org closing connection msmtp: the server does not support authentication msmtp: could not send mail Here's what it looks like talking unencrypted to another server where it does work properly (some info redacted): <-- 220 [SERVERNAME] ESMTP Postfix (Ubuntu) --> EHLO localhost <-- 250-[SERVERNAME] <-- 250-PIPELINING <-- 250-SIZE 10240000 <-- 250-VRFY <-- 250-ETRN <-- 250-STARTTLS <-- 250-AUTH PLAIN LOGIN <---- We don't get this on Tommy! <-- 250-ENHANCEDSTATUSCODES <-- 250-8BITMIME <-- 250-DSN <-- 250 SMTPUTF8 --> AUTH PLAIN [ENCODED PASSWORD] <---- It tells us that we can do this <-- 235 2.7.0 Authentication successful --> MAIL FROM:<[MY EMAIL ADDRESS]> --> RCPT TO:<[RECEIVER'S EMAIL ADDRESS]> --> DATA <-- 250 2.1.0 Ok <-- 250 2.1.5 Ok <-- 354 End data with <CR><LF>.<CR><LF> --> Date: Sat, 25 Jul 2020 15:14:05 +1000 [MESSAGE] --> . <-- 250 2.0.0 Ok: queued as 7C7FE3B25F1 --> QUIT <-- 221 2.0.0 Bye Here I'm back with Tommy using another client where the SSL is new enough to work, and STARTTLS is enabled (this is still on the non-SSL port 587): * Connecting to SMTP server: mail.ombertech.com ... [17:02:20] SMTP< 220-tommy.heliohost.org ESMTP Exim 4.92 #2 Sat, 25 Jul 2020 06:56:29 +0000 [17:02:20] SMTP< 220-We do not authorize the use of this system to transport unsolicited, [17:02:20] SMTP< 220 and/or bulk e-mail. [17:02:20] ESMTP> EHLO The-Overheating-Giant [17:02:20] ESMTP< 250-tommy.heliohost.org Hello The-Overheating-Giant [1.136.166.92] [17:02:20] ESMTP< 250-SIZE 52428800 [17:02:20] ESMTP< 250-8BITMIME [17:02:20] ESMTP< 250-PIPELINING [17:02:20] ESMTP< 250-STARTTLS [17:02:20] ESMTP< 250 HELP [17:02:20] ESMTP> STARTTLS [17:02:21] ESMTP< 220 TLS go ahead * SSL certificate of mail.ombertech.com previously accepted [17:02:21] ESMTP> EHLO The-Overheating-Giant [17:02:21] ESMTP< 250-tommy.heliohost.org Hello The-Overheating-Giant [1.136.166.92] [17:02:21] ESMTP< 250-SIZE 52428800 [17:02:21] ESMTP< 250-8BITMIME [17:02:21] ESMTP< 250-PIPELINING [17:02:21] ESMTP< 250-AUTH PLAIN LOGIN <---- Now Tommy talks about AUTH, but only after STARTTLS has enabled TLS/SSL [17:02:22] ESMTP< 250 HELP [17:02:22] ESMTP> AUTH PLAIN ******** [17:02:22] ESMTP< 235 Authentication succeeded [17:02:22] SMTP> MAIL FROM:<[MY EMAIL ADDRESS]> [17:02:22] SMTP< 250 OK [17:02:22] SMTP> RCPT TO:<[RECEIVER'S EMAIL ADDRESS]> [17:02:22] SMTP< 250 Accepted [17:02:22] SMTP> DATA [17:02:23] SMTP< 354 Enter message, ending with "." on a line by itself [17:02:23] SMTP> . (EOM) [17:02:23] SMTP< 250 OK id=1jzE6i-000PnH-MD [17:02:23] SMTP> QUIT [17:02:24] SMTP< 221 tommy.heliohost.org closing connection In that same client if I disable STARTTLS it fails like on the other system. Here though I can force it to attempt the AUTH command even though no AUTH methods are provided by the server, but the server won't accept that: * Connecting to SMTP server: mail.ombertech.com ... [16:31:38] SMTP< 220-tommy.heliohost.org ESMTP Exim 4.92 #2 Sat, 25 Jul 2020 06:25:47 +0000 [16:31:38] SMTP< 220-We do not authorize the use of this system to transport unsolicited, [16:31:38] SMTP< 220 and/or bulk e-mail. [16:31:38] ESMTP> EHLO The-Overheating-Giant [16:31:38] ESMTP< 250-tommy.heliohost.org Hello The-Overheating-Giant [1.136.169.176] [16:31:38] ESMTP< 250-SIZE 52428800 [16:31:38] ESMTP< 250-8BITMIME [16:31:38] ESMTP< 250-PIPELINING [16:31:38] ESMTP< 250-STARTTLS [16:31:38] ESMTP< 250 HELP [16:31:38] ESMTP> AUTH PLAIN ******** [16:31:38] ESMTP< 503 AUTH command used when not advertised <---- Tommy knows when I'm trying to cheat ** LibSylph-WARNING: [16:31:38] error occurred on SMTP session ** error occurred on SMTP session ** Sylpheed-WARNING: send: error: 503 AUTH command used when not advertised ** LibSylph-WARNING: [16:31:38] Error occurred while sending the message. ** Error occurred while sending the message. The intended SSL Port 465 works fine, if the client's encryption library is new enough. Perhaps port 587 is actually supposed to only work with STARTTLS and therefore SSL, even though the CPanel info suggests differently. So if it's intentional I'll go away with my tail between my legs and try to wrestle my old systems into the modern encrypted world (which I'm working on anyway). If it's a mistake in Exim's configuration though, I'd be glad to see it fixed. PS. No my current ISP doesn't have an authentication-free SMTP server available to customers, which I could use for sending by using my Heliohost-hosted email address in the "From:" header.
wolstech Posted July 25, 2020 Posted July 25, 2020 It's likely intentional because AUTH PLAIN is a security issue (this is the default setting too). The issue you're seeing is because of this option in WHM that we have turned on: Require clients to connect with SSL or issue the STARTTLS command before they are allowed to authenticate with the server. [?]Disabling this option will significantly decrease the security of the server by allowing the plaintext transmission of authentication credentials. I've actually turned this off briefly a few times to confirm this exact problem was the issue with my apps, but since it's a security issue I turned it back on and found more secure solutions once I knew where the problem was. I'd be looking for newer software. If the software is old enough to need this option turned off, it's old enough to have god knows how many other security issues. I have a PHP mail client from 2011 installed on my account, and even it supports STARTTLS...
Computer Nerd Kev Posted July 26, 2020 Author Posted July 26, 2020 It's intentional because AUTH PLAIN is a security issue. Technically it doesn't have to be AUTH PLAIN, it could be AUTH CRAM-MD5 (or similar) for a little more security, but I'm not sure if this is relevent to the rest of your reply because that's nothing to do with STARTTLS or SSL/TLS in general. The AUTH method is just the way of specifying the password, with methods that make it more secure do so over unencrypted connections. Require clients to connect with SSL or issue the STARTTLS command before they are allowed to authenticate with the server. [?] Disabling this option will significantly decrease the security of the server by allowing the plaintext transmission of authentication credentials.I've actually turned this off briefly a few times to confirm this exact problem was the issue with my apps, but since it's a security issue I turned it back on and found more secure solutions once I knew where the problem was. Well the security risk is that without SSL/TLS the authentication details can be read by someone snooping on the connection. That won't compromise the server itself (it's the same info as in the logs that I posted), but of course they can use them to get passwords that other people use to send email. That's why I was only looking to do it with one account where security isn't very important and the password isn't used for anything else. Similar to how FTP and HTTP CPanel/Webmail is enabled even though they're unencrypted, presumably for people who aren't concerned about a targeted attack on their account. There is an argument that someone snooping on all of the internet traffic that goes to Heliohost (eg. a hacked machine or rogue employee at the datacentre or an ISP) could pick out the passwords for all Heliohost email accounts that users connect to without encryption. Then they could use Heliohost for sending spam out via other user's accounts - without an easy way of blocking them (if they connect from a large range of IP addresses). So from that perspective it could be a risk to the whole server because if it gets Heliohost on spam blacklists, and can't be fixed while there are users connecting unencrypted to their email, it would affect all users on the system. But Tommy does accept webmail logins over unencrypted HTTP at port 2085, which is just as bad as unencrypted SMTP (maybe worse because I'm not sure if there's anything like CRAM-MD5 for HTTP) for security of authentication details. Also IMAP on port 143 works without SSL/TLS. As the same passwords are used with SMTP for sending email, then that risk is still open via those routes. Sorry for the lecture, I'm just trying to cover all sides of the topic. Security stuff always gets complicated. I'd be looking for newer software. If the software is old enough to need this option turned off, it's old enough to have god knows how many other security issues. I have a PHP mail client from 2011 installed on my account, and even it supports STARTTLS... Technically the software I'm using does support STARTTLS and SSL/TLS directly on port 465. This still works on other servers. The trouble is that the encryption library used by my software is old and Tommy's software no longer supports any of the encryption methods that it can use. That's presumably because they've all got security issues, so I am resigned to trying to upgrade eventually (complicated by me wanting to use software that isn't maintained - I'm currently looking at installing a separate MDA and MTA (msmtp from the first SSL log) instead of the ones built into my old MUA, but what do you know I'm having trouble getting the SSL support to compile...). I'm not trying to draw Heliohost into my own world of software frustration, and do plan to get my Email working everywhere over the latest encryption eventually. This was just an attempt at a quick fix for one account where encryption doesn't matter in the first place, and seeing as unencrypted connections are allowed for pretty much everything else (including webmail and IMAP) it seemed unlikely that SMTP was deliberately meant to be SSL-only. If it is deliberate, then I think the logic is a bit inconsistent, but I won't tell you to re-evaluate everything just for the sake of my temporary issue, not unless you want to anyway.
wolstech Posted July 26, 2020 Posted July 26, 2020 It's the default setting in cPanel these days, which is why it's turned on. We like to leave things alone when possible to improve security as well as ease of rebuilding the server later (if we change the default, it's one more thing we have to remember to change in rebuilds). It does seem silly that we allow insecure IMAP but not SMTP though. As you said, the passwords are the same in both directions. The insecure webmail is intentional. We also offer insecure cPanel on 2082 (and 80 via the cpanel.domain.heliohost.org subdomain) as well). These are provided for a few reasons:Many enterprise/school networks block SSL on non-standard ports (or block SSL entirely except to approved sites)...we have tons of users who access us from work, or who use our services for educational use at school.We have users in countries where private use of encryption is banned (yes these exist).Some lesser reasons that aren't as important these days (WinXP support comes to mind...we used to have a decent number of users in places like China running XP, not sure if we still do)While I think you've answered your own question (you're admittedly using obsolete software), lets see if Krydos is willing to turn this off considering the fact we already allow a bunch of other insecure email services like IMAP.
Computer Nerd Kev Posted July 26, 2020 Author Posted July 26, 2020 Well as it turns out I've now managed to get msmtp to build with SSL/TLS support, and got my old email MUA to use it instead of the built-in MTA (which took a bit more scripting than I expected), so I can do SMTP with encryption on port 465 now. So whether or not you want to change the default so that SMTP works unencrypted, I don't need it now personally. Ideally I would still prefer the option to use unencrypted SMTP in case of future troubles though. Thanks for the explainations and for looking into this. Now to try and set up an MRA/MDA for the IMAP side of things...
Recommended Posts