Honestly, lately I HATE the way Manager.IO handles SMTP Settings. After the upgrades it drops SSL Errors, TLS Errors. So I install a local postfix, disable TLS, sure it connects but now Manager.IO Forces authentication and doesn’t account null credentials as the Postfix server just takes what it’s given locally and forwards onto our mail gateway.
No Matter what I do with this I CANNOT get anything to work correctly without Bashing my head on a wall or having to perform major hacks because the email settings screen is so restrictive.
Please for the love of god, Make the email settings more configurable, Ability to define ports used and if authentication is required or not and also a checkbox to enable or disable tls.
It is your choice to not use SMTP or the recently inroduced HTTP and configure a way out yourself but your request opens a lot of potential issues prone to making Manager more vulnerable to hacks, most importantly the ability to remove autentication which for SMTP is essential to work safely. We use Server edtiion and some Desktop ones and would never want Manager to do as you suggested nor do most other application I know of that offer SMTP server credentials to do the same.
If this is unsurmountable then maybe consider moving away from Manager as it seem to be frustrating.
I’m sorry, but I fail to see how Manager would be more prone to hacks by opening up client configuration options, It’s a client for SMTP not a Server. You cannot make a connection to it on Port 25 or any other SMTP port. In response to your essential for work safely, that’s rubbish, you can easily use TLS with IP Based authentication methods with SMTP, in fact alot of ISP’s still run relays using this exact method, even here in Australia.
Also with the HTTP option to send emails, even that is barely usable, alot of services use an Authentication Bearer token, Where in Manager.io do you configure that???
Yes we are considering it, it seems ever since the June / July updates that SMTP and TLS has been broken, I had a previous thread about this, but it fell on deaf ears.
In the end I worked around it, Installed and configured Postfix on the same Debian Server box as Manager and configured SASL to authenticate any possible user, and used that to push upstream to mail servers we have that use IP Based Auth, rigmarole but for now it works, untill some other regression in this software rears it’s ugly head.
Despite some forceful language such as “rubbish” the common security risks posed by allowing users to open non-standard SMTP ports and disable authentication are:
Without authentication, the server could become an open relay, allowing spammers to misuse it, damaging your IP/domain reputation and risking blacklisting by ISPs.
Attackers could intercept unencrypted traffic, leading to data theft or impersonation, which enables phishing or fraud.
Unsecured servers can be exploited to spread malware via emails.
Without authentication, it’s hard to trace misuse or identify who sent malicious emails.
Non-standard ports may be more vulnerable to hijacking or targeted attacks, and bypass firewalls.
Disabling authentication hinders integration with protocols like SPF, DKIM, and DMARC, affecting email deliverability and security.
Best practice is to always require authentication, use secure standard ports (465/587), enable anti-spam measures (SPF/DKIM/DMARC), and monitor traffic for anomalies.
I’m sorry but SPF, DKIM and DMARC does not require authentication on SMTP, these are merely methods to verify that the server receiving the email checks DNS txt records that the email from the source is in an allowed list to relay it. There are many articles online on how this works.
TLS while it’s possible attackers could intercept unencrypted traffic, it’s rare unless the source or destination has a device or software on their system which can do MITM. Even encrypted traffic is prone to MITM attacks. Besides if Manager.IO would implement a decent stack that doesn’t go “Hey TLS works fine in the test.” then dumps a “Oh I couldn’t verify TLS” when sending an email, it would be great.
Unsecured servers can be exploited, yes but this is why you set relays to only allow from Systems it knows, like Static IP’s in it’s allow to relay list.
Besides while your points are valid, they are completely useless to this discussion, we are talking about how Manager.IO Implements SMTP CLIENT not SERVERS. It’s the way it limits us from Interacting with Server’s that’s painful, to which in the other thread I pointed out how much more open other products are including MYOB and Quickbooks are with their local running SMTP Client options.
The concerns shift slightly such as your observation regarding SPF, DKIM and DMARC when talking about SMTP security risks in the context of SMTP clients. However, they remain interconnected with the overall email security landscape of the Servers they link to. Here’s a summary of key risk applied to SMTP clients (most are similar to Servers):
Without proper authentication, SMTP clients can send emails without verifying the sender’s identity, leading to impersonation, phishing, or spam.
Clients that don’t enforce encryption (STARTTLS or TLS) risk data interception, exposing sensitive information like login credentials are open to so called Man-in-the-Middle (MITM) Attacks
Clients using non-standard ports or port 25 for outgoing mail without proper security can open up vulnerabilities and allow spam or other attacks.
Without client-side authentication, tracking who sent emails is difficult, which complicates abuse detection.
Compromised clients can send phishing or malware-laden emails, turning them into vehicles for spreading infections. Attackers can exploit unsecured SMTP clients to send spoofed or phishing emails, harming domain reputation and increasing the risk of blacklisting.
Without proper authentication, SMTP clients can send emails without verifying the sender’s identity, leading to impersonation, phishing, or spam.
While this can be true for a fully “Misconfigured” SMTP Server, IP Based ACL’s also prevent what you are talking about here without the need for authentication. Also that’s what DNS TXT based Protocols like you said earlier prevent, SPF, DKIM and DMARC which use Public / Private Keypairs at the recipient server to verify the origination IP / Reverse DNS of the server relaying the email.
Clients that don’t enforce encryption (STARTTLS or TLS) risk data interception, exposing sensitive information like login credentials are open to so called Man-in-the-Middle (MITM) Attacks
While this does pose a problem with exposing credentials over the internet, it’s not a problem if you have your mail server internal to your own network in a controlled environment before your own internal relay sanitizes and then sends it out in the wild with encryption and standard certificates.
Clients using non-standard ports or port 25 for outgoing mail without proper security can open up vulnerabilities and allow spam or other attacks.
This is no different to any other port used with SMTP, the reason 25 isnt really used anymore and was blocked by ISP’s was because this was prior to SPF, DKIM and DMARC being implemented. ISP’s would block it due to malware on end user computers that would spew out mail on port 25, so before the new Verification methods existed they would just block the port on known Dynamic IP Services
Without client-side authentication, tracking who sent emails is difficult, which complicates abuse detection.
I find this a bit odd, while you can authenticate as for example do-not-reply@abc and send an email from johndoe@abc the email server will still relay it as the user is authenticated. Authentication is just a mechanism to allow Dynamic IP based clients ability to relay without requiring a static known IP.
Compromised clients can send phishing or malware-laden emails, turning them into vehicles for spreading infections. Attackers can exploit unsecured SMTP clients to send spoofed or phishing emails, harming domain reputation and increasing the risk of blacklisting.
This is more of a EDR (Endpoint Detection and Response) problem than an email client setting, and as above this is why ISP’s block 25 on known dynamic IP Ranges. Then unless somehow someone writes a dll that manager loads and can spew emails from itself I dont see this as an issue as Manger is not an email relay server. (Client capabilities cant even be implemented correct, what hope would it have being an email server /tounge in cheek/)
@bdallen can you show some screenshot and show what you are suggesting specifically that should change?
SMTP settings in Manager have been evolving for people to avoid common traps but there were always issues and many outside of my control. So as a fallback, Manager now supports sending emails through HTTP protocol too. That seems to have resolved SMTP issues by simply avoiding SMTP altogether.
That being said, I’m open to implement more flexibility to SMTP settings since now if it’s overwhelming for anyone, I’ll just tell them to use HTTP protocol instead.