SMTP Restrictions breaks email
Hi all,
According to the logs, starting on the 21st of July some of our websites (those on WHM/cPanel servers) started failing to send SMTP authenticated emails.
After some testing we narrowed it down to WHM/cPanel. After disabling SMTP Restrictions, it started working again.
Our email servers are protected and require authenticated sending and our email server has the IP of the cPanel server whitelisted.
However, the following happens:
However, if trying from another (non-cPanel) server it authenticated successfully:
So we proceeded to disabling cPanel SMTP restrictions. This is the output from the same cPanel Server:
I didn't think SMTP restrictions meant "being unable to send secured authenticated emails from your cPanel server". I have been giving much thought into replacing cPanel with Virtualmin in the last months as we replaced two customer web servers and it's working very well, this issues look like suggesting that would indeed be the correct thing to do.
[domain@web0 ~]$ openssl s_client -connect mail.domain.io:587 -starttls smtp
CONNECTED(00000003)
depth=3 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Certification Authority"
verify return:1
depth=0 CN = web0.domain.io
verify return:1
---
Certificate chain
0 s:/CN=web0.domain.io
i:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
1 s:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=web0.domain.io
issuer=/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5307 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: EC0C4041E9418F3861FF89C4AAE19A515324FCDFB9D418C772EC8B6611FD710E
Session-ID-ctx:
Master-Key: 83E32603B2565D891205C11420333B0CE220D5AE8589EB6E1744FC6E3EA37C0DA79C31323E54C93BE545E28375916A2F
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1596021539
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 HELP
EHLO horus.local
250-web0.domain.io Hello horus.local [1.1.1.1]
250-SIZE 157286400
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELP
AUTH LOGIN
334 VXNlcm5hbWU6
c3lzdGc2MuaW8=
334 UGFzc3dvcmQ6
M2pGMnNmUDJxluVw==
535 Incorrect authentication data
However, if trying from another (non-cPanel) server it authenticated successfully:
235 2.7.0 Authentication successful
So we proceeded to disabling cPanel SMTP restrictions. This is the output from the same cPanel Server:
[domain@web0 ~]$ openssl s_client -connect mail.domain.io:587 -starttls smtp
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mail.domain.io
verify return:1
---
Certificate chain
0 s:/CN=mail.domain.io
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=mail.domain.io
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3963 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 11810AF38245ED55D0FE31028F770879E627F32246DDC340C26ECF80513B68FB
Session-ID-ctx:
Master-Key: DE0F0BF75519275C3C99CA6E5D97C4CA1FE83407B87B4F0DBDA2E2BDC79A7AC9A61BC13A9F3030A5775B119AFADD708E
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - ba fd 57 3d bc 01 9e 0c-f2 87 d8 50 1d e3 8f 1f ..W=.......P....
0010 - ef 3d 3f d5 f1 b9 20 72-52 8f ba e4 d2 e7 80 95 .=?... rR.......
0020 - 0e 80 5e 7c 1b ed ce cb-fc 07 cf 47 1b cb 95 09 ..^|.......G....
0030 - 4d 77 2d 2e b7 cc 88 5c-6f f8 a3 58 f2 b5 5f e3 Mw-....\o..X.._.
0040 - 73 58 01 fb c7 94 26 13-97 bf 2b 0f e6 92 44 28 sX....&...+...D(
0050 - f8 2d 6a d9 9a aa 11 d0-f7 70 ad 76 ff 1d 6d ee .-j......p.v..m.
0060 - e8 6b 11 56 01 44 2f 6b-e6 a8 dd 45 78 62 34 bb .k.V.D/k...Exb4.
0070 - de 36 73 b8 8b 23 e6 7e-13 5c 4b 46 a9 0b 03 23 .6s..#.~.\KF...#
0080 - 79 a2 e1 a3 d8 5b 1a 06-ab 95 f9 db 98 f7 1b 24 y....[.........$
0090 - 43 fd 78 2b 42 b4 25 5a-30 9d 06 16 00 d1 12 af C.x+B.%Z0.......
Start Time: 1596021836
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 CHUNKING
EHLO horus.local
250-mail.domain.io
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
AUTH LOGIN
334 VXNlcm5hbWU6
c3lzdGc2MuaW8=
334 UGFzc3dvcmQ6
M2pGMnNmUDJxluVw==
235 2.7.0 Authentication successful
I didn't think SMTP restrictions meant "being unable to send secured authenticated emails from your cPanel server". I have been giving much thought into replacing cPanel with Virtualmin in the last months as we replaced two customer web servers and it's working very well, this issues look like suggesting that would indeed be the correct thing to do.
-
I think there may be some confusion here as to what the purpose of SMTP restrictions in WHM>>Security Center>>SMTP Restrictions is [QUOTE=https://docs.cpanel.net/whm/security-center/smtp-restrictions/]This interface allows you to configure your server so that only the mail transport agent (MTA), Mailman mailing list software, and the root user can connect to remote SMTP servers. This will deny other users and services the ability to bypass your mail server to directly send mail, which is common practice for spammers.
This controls which users are able to connect to remote SMTP servers, by restricting this to the root, mailman and MTA users. This means with SMTP restrictions on with or without authentication a user that is not root, mailman or the MTA will not be able to connect to a remote server to send mail. When you attempt to connect directly usingtelnet
oropenssl s_client
in this manner to a remote mailserver, with SMTP restrictions enabled you will indeed be blocked. This setting does not manage your users sending authenticated emails from the server via a secured or unsecured channel. By default, all users need to authenticate to send mail. The only exception to this is when you enable the following (which is disabled by default) [QUOTE] Allow users to relay mail if they use an IP address through which someone has validated an IMAP or POP3 login within the last hour (Pop-before-SMTP) Provides the IMAP/POP before SMTP authentication method. You must enable RecentAuthedMailIpTracker in the Service Manager for this functionality to work. However, we recommend that you do not enable this option, and you should instead use SMTP authentication on modern systems.0 -
Hi there sorry for the late reply. Allow users to relay mail if they use an IP address through which someone has validated an IMAP or POP3 login within the last hour (Pop-before-SMTP) Provides the IMAP/POP before SMTP authentication method. You must enable RecentAuthedMailIpTracker in the Service Manager for this functionality to work. However, we recommend that you do not enable this option, and you should instead use SMTP authentication on modern systems.
So if on the same ip/user there's an app checking for email to that given server, connection will be allowed? With SMTP Restrictions enabled?0 -
SMTP restrictions aren't related to this at all, completely different thing. 0 -
SMTP restrictions aren't related to this at all, completely different thing.
If your proposed solution and SMTP Restrictions are completely different things, how will your suggested approach help me, given that is disabling SMTP Restrictions that solves the issue?0 -
I'm trying to understand what is still not being understood here. - SMTP restrictions control who is able to connect to remote servers to send mail.
- I did not propose any solution to you, I simply explained what the service does as it is clear there is a misunderstanding.
- You note in your initial response that your servers require authentication, all cPanel servers by default require authentication, the exception being if you use the setting I mentioned.
- SMTP restrictions will keep ANYONE who is not the MTA, ROOT, or MAILMAN from being able to connect to remote servers. If you need your users to be able to connect to remote servers then don't use SMTP restrictions but do not get it confused with authentication as ALL users must authenticate to send mail.
0 -
I'm trying to understand what is still not being understood here.
- SMTP restrictions control who is able to connect to remote servers to send mail.
- I did not propose any solution to you, I simply explained what the service does as it is clear there is a misunderstanding.
- You note in your initial response that your servers require authentication, all cPanel servers by default require authentication, the exception being if you use the setting I mentioned.
- SMTP restrictions will keep ANYONE who is not the MTA, ROOT, or MAILMAN from being able to connect to remote servers. If you need your users to be able to connect to remote servers then don't use SMTP restrictions but do not get it confused with authentication as ALL users must authenticate to send mail.
Do you know if there is a feature request to add users to an allow list for this? So it would be possible for select users to connect to remote servers having smtp restrictions enabled? Thank you.0
Please sign in to leave a comment.
Comments
8 comments