A way to force authentication on local email delivery
-
I do not agree. The battle is not ending because an attacker may reached local presence on the server. This can be reached even from remote, with web shells and such. The opposite - the more attackers succeed the more defense measures we need. Also, I tested it remotely by simply telnet from an Internet telnet client to port 25 on the server and then using a "from" of a local domain and a "rcpt to" to another email address of same the local domain of the "from" address, and the delivery was accepted OK and sent successfully without any need for authentication, so this bad action works also remotely. I think CP developers need to put more will and effort to solve this serious security weakness. 0 -
Let me reach out to the team and see if I can get an official answer on this one! 0 -
Thank you, much appreciated! 0 -
BTW, the process I mentioned can possibly be somewhat protected from using Greylisting, but the root cause needs to be addressed, as it bypasses strong security feature like SPF. 0 -
I also tried to send, directly from my PC, via my public Internet IP, using direct telnet to Exim's SMTP port, an email with a "from" of xxx@gmail.com to an existing email address of a local Exim domain (while Greylisting was disabled) - and it also worked, hence Iw as able to impersonate as external sender and "inject" an email delivery directly at the server level, while bypassing common email security checks. 0 -
I went ahead and switched that feature request over to "not planned" as this isn't something we intend to change. There just isn't a way to stop the mail server from accepting messages over SMTP for delivery to local mailboxes. That is a core function of how SMTP works, and why there is a need for additional protocols for mail authentication, like SPF/DKIM/DMARC, etc. I think of what you're running into is that SMTP is just a bad protocol. It really wasn't designed to be used how it is today with modern servers and a global internet. Details on securing your email can be found here: 0 -
cPRex, for some reason your links are not visible.
0 -
That happened with some of the migrated threads. Here's that link: https://docs.cpanel.net/knowledge-base/email/how-to-prevent-email-abuse/
0 -
Is the following post from 2016 evidence that it can be done?
Or would it prevent necessary administrative emails sent from root and service users?
https://serverfault.com/questions/767450/exim-force-email-auth-for-users-of-local-domains
0 -
Kenric Ashe - you're welcome to test that, but we can't guarantee it will work on a cPanel system.
0 -
I don't have enough experience to properly test whether it's an actual solution or not. My point was that if it can be done via Exim config, then maybe it's not an inherent limitation of the SMTP protocol? Maybe cPanel engineers could confirm and possibly implement that solution?
0 -
No, this has been a request for over 10 years so we aren't making changes at this point.
0 -
It matters not to me. I'm not making any feature requests. I was only responding to the assumption that it's an inherent flaw in the SMTP protocol. But now it sounds like it's simply something that cPanel doesn't want to do. I'm merely suggesting full disclosure about the reason for not doing it.
0 -
Here's the original feature thread discussing this - https://features.cpanel.net/topic/enable-smtp-authentication-on-local-delivery
0 -
This is a core feature of Exim, which is why we haven't elected to change it:
"If a local process calls Exim to send a message, the sender address that is built from the login name and qualify_domain is treated as authenticated."
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-smtp_authentication.html
0 -
And yet, someone claims to have configured a workaround. I need to get back to work. It's cPanel's choice whether to ignore the new info.
0
Please sign in to leave a comment.
Comments
17 comments