DEV Community: Mohammed AlShannaq

Understanding cPanel SMTP Restrictions: Security, External SMTP, and the Trade-Offs

Mohammed AlShannaq — Thu, 09 Jul 2026 19:31:52 +0000

A cPanel setting called:

Restrict outgoing SMTP to root, exim, and mailman (FKA SMTP Tweak)

looks simple.

You either enable it or disable it.

In practice, however, the decision can affect application compatibility, email abuse controls, troubleshooting, and the way hosted applications connect to external email services such as Microsoft 365, Gmail or any other External SMTP.

I am not arguing in this article that the setting should always be enabled or always be disabled.

The aim is simpler:

explain what the setting actually does;
show a legitimate application scenario that can fail because of it;
explain why the failure can be confusing;
present the security argument for enabling it;
present the compatibility argument for disabling it;
and provide a practical troubleshooting method.

The correct decision depends on the hosting environment, the operator's security model, and the needs of hosted applications.

What does the setting do?

According to cPanel's official documentation, SMTP Restrictions can configure the server so that only:

the mail transport agent (MTA);
Mailman;
and the root user

can connect to remote SMTP servers.

Other users and services are denied the ability to bypass the local mail server and send mail directly through remote SMTP systems.

cPanel describes this bypass behaviour as something commonly used by spammers.

Official documentation:

https://docs.cpanel.net/whm/security-center/smtp-restrictions/

In simplified form, with the restriction enabled, an application running under a normal hosting user may not be allowed to connect directly to a remote SMTP endpoint on a restricted SMTP path.

The intended security model is roughly:

Hosted application
       |
       | SMTP connection
       v
Local Exim server
       |
       v
Remote destination

rather than:

Hosted application
       |
       | direct SMTP connection
       v
External SMTP server

That distinction is the centre of the whole discussion.

The legitimate application case

Consider a PHP application that uses PHPMailer:

$mail->isSMTP();
$mail->Host = 'smtp.office365.com';
$mail->SMTPAuth = true;
$mail->Port = 587;
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;

There is nothing inherently suspicious about this configuration.

The application may belong to a company whose email service is hosted on Microsoft 365. The developer may intentionally want the application to submit mail through Microsoft rather than through the hosting server's local Exim service.

The expected path is:

PHP application
      |
      | STARTTLS + SMTP AUTH
      v
smtp.office365.com:587
      |
      v
Microsoft 365
      |
      v
Recipient

This pattern is common in modern applications.

Similar designs can exist with:

PHPMailer;
Laravel mail;
Symfony Mailer;
WordPress SMTP plugins;
Nodemailer;
Google Workspace;
transactional email providers;
and other authenticated SMTP services.

So the important distinction is this:

Direct external SMTP is not automatically malicious. It can be a deliberate application architecture.

The surprising failure mode

When administrators think about a blocked outbound connection, they often expect:

Connection timed out

or:

Connection refused

But SMTP restrictions can produce a much more confusing symptom.

An application may attempt to connect to:

smtp.office365.com:587

and then fail with an error similar to:

Peer certificate CN=local-server.example.com
did not match expected CN=smtp.office365.com

At first sight, this looks like:

a Microsoft 365 problem;
a STARTTLS problem;
a broken certificate chain;
a DNS problem;
a firewall problem;
a WAF problem;
or an application library bug.

But another possibility is that the connection is not reaching the expected external SMTP endpoint.

Instead, the SMTP connection may be handled by the local mail service.

The effective path can become:

Application
    |
    | tries smtp.office365.com:587
    v
Local SMTP restriction behaviour
    |
    v
Local Exim service
    |
    v
Local server certificate

The application expects the identity of smtp.office365.com, but receives the identity of the local server.

The TLS hostname check then fails correctly.

A controlled troubleshooting method

The following method can help distinguish:

provider-level network blocking;
a general server connectivity problem;
and user-level SMTP restriction behaviour.

Do not send any email during these tests.

The goal is only to inspect connectivity, SMTP banners, and TLS identity.

Test 1: connect as root

Run:

openssl s_client \
  -starttls smtp \
  -connect smtp.office365.com:587 \
  -servername smtp.office365.com \
  -crlf

If the connection reaches Microsoft, the output should show a certificate chain and SMTP service associated with Microsoft rather than the local hosting server.

This proves that the server itself has a route to the external SMTP service.

However, this test alone is not enough.

A restriction may treat root differently from normal hosting users.

Test 2: connect as the hosting user

Run the same test under the relevant Linux or cPanel user:

sudo -u exampleuser openssl s_client \
  -starttls smtp \
  -connect smtp.office365.com:587 \
  -servername smtp.office365.com \
  -crlf

Now compare the result.

A useful diagnostic pattern is:

As root:
→ Microsoft certificate

As hosting user:
→ local server certificate

That strongly suggests that the behaviour depends on the user context rather than on general network reachability.

Test 3: test from PHP under the same user

A minimal PHP script can test the actual application context without authentication and without sending a message:

<?php

declare(strict_types=1);

$host = 'smtp.office365.com';
$port = 587;
$timeout = 10;

$errno = 0;
$errstr = '';

$socket = stream_socket_client(
    "tcp://{$host}:{$port}",
    $errno,
    $errstr,
    $timeout,
    STREAM_CLIENT_CONNECT
);

if ($socket === false) {
    fwrite(STDERR, "TCP connection failed\n");
    fwrite(STDERR, "Error {$errno}: {$errstr}\n");
    exit(1);
}

stream_set_timeout($socket, $timeout);

echo "TCP connection established\n";

$banner = fgets($socket);

if ($banner === false) {
    fwrite(STDERR, "Connected, but no SMTP banner was received\n");
    fclose($socket);
    exit(1);
}

echo "SMTP banner:\n";
echo trim($banner) . PHP_EOL;

fwrite($socket, "EHLO test.local\r\n");

echo "\nEHLO response:\n";

while (($line = fgets($socket)) !== false) {
    echo trim($line) . PHP_EOL;

    if (preg_match('/^250\s/', $line) === 1) {
        break;
    }
}

fwrite($socket, "QUIT\r\n");
fclose($socket);

echo "\nConnection closed without authentication or sending email\n";

Run it under the hosting user:

sudo -u exampleuser php /tmp/test-smtp-587.php

No SMTP authentication is performed.

No MAIL FROM command is sent.

No RCPT TO command is sent.

No message body is transmitted.

The script only:

opens a TCP connection;
reads the SMTP banner;
sends EHLO;
reads the capabilities;
sends QUIT.

If the application asks for smtp.office365.com:587 but receives a banner from the local Exim server, the behaviour becomes much easier to understand.

The value of an A/B test

Where operationally safe and authorised, an administrator can compare behaviour before and after changing the SMTP Restrictions setting.

A simplified result may look like this:

Restrictions ON
→ hosting-user PHP process
→ local Exim banner

Then:

Restrictions OFF
→ same hosting-user PHP process
→ Microsoft 365 SMTP banner

This is much stronger evidence than guessing from an application error message.

The important point is not that every cPanel server will behave identically.

The important point is that testing should be done:

from the same server;
under the same user;
using the same destination;
and ideally from the same application runtime.

The argument for keeping SMTP Restrictions enabled

There is a strong and legitimate security argument for enabling the feature.

1. Centralised control

If applications cannot bypass the local MTA on the restricted SMTP paths, the hosting operator has a more centralised mail architecture.

Mail that passes through Exim can be subject to local controls such as:

logging;
queue inspection;
delivery reporting;
local policy;
rate limits;
and abuse investigation.

2. Reduced ability to bypass the local MTA

A compromised script may otherwise attempt to connect to an external SMTP system.

With the restriction enabled, the operator reduces the ability of ordinary user processes to bypass the local mail server on the restricted paths.

This is the core rationale described by cPanel.

3. Easier investigation when mail uses Exim

When mail passes through the local MTA, the operator may have better evidence in:

Exim logs;
queue data;
delivery reports;
and local sending statistics.

A 2022 cPanel Community discussion presents exactly this concern. A moderator points back to cPanel's security rationale, while another community participant argues that keeping all outgoing mail through Exim makes spam activity easier to notice and trace.

Community discussion:

https://support.cpanel.net/hc/en-us/community/posts/19161442634903-Restrict-outgoing-SMTP-why-is-bad-to-allow

These are valid operational concerns.

The argument for disabling SMTP Restrictions

There is also a legitimate compatibility and application-design argument for disabling the feature.

1. Modern applications often use external email services

A hosted application may intentionally use:

smtp.office365.com

rather than:

localhost

The organisation may have already chosen Microsoft 365, Google Workspace, or another provider for its email architecture.

Forcing the application through the hosting server's local Exim service may not match the intended design.

2. Legitimate application SMTP can fail

The restriction can interfere with applications that expect a direct external SMTP submission path.

The resulting problem may be especially confusing when the application receives the local server's TLS certificate instead of the external provider's certificate.

3. The setting is not an absolute ban on every possible external SMTP design

A 2025 cPanel Community discussion examined PHPMailer using SMTP2Go on port 2525.

Participants discussed that SMTP Restrictions affect standard SMTP ports such as 25, 465, and 587, while a custom port such as 2525 may continue to work if allowed by the firewall.

A cPanel moderator noted that a custom port may mean the SMTP Restrictions do not apply in that case.

Community discussion:

https://support.cpanel.net/hc/en-us/community/posts/34506598182295-SMTP-Restrictions-and-External-SMTP-providers

This is an important nuance.

It suggests that the setting should not be described as a complete boundary against every possible external SMTP connection.

4. cPanel officially documents disabling the feature for scripts that need to bypass Exim

This is one of the most important points in the discussion.

A cPanel support article updated on 22 May 2026 states that SMTP Restrictions help reduce outbound spam by forcing SMTP connections through local Exim.

It then explains that if a script needs to bypass Exim when sending messages, the feature may need to be disabled.

Official cPanel support article:

https://support.cpanel.net/hc/en-us/articles/1500009931961-How-to-disable-SMTP-Restrictions

This does not mean cPanel recommends disabling the setting everywhere.

It does show that bypassing Exim can be a recognised operational requirement rather than an inherently invalid configuration.

Does disabling the setting break Exim logging?

This question deserves a direct answer.

Disabling SMTP Restrictions does not, by itself, mean that Exim stops logging mail that actually passes through Exim.

Consider two paths.

Path A: the application still uses local Exim

Application
    |
    v
Local Exim
    |
    v
Remote recipient

This mail still passes through the local MTA.

The normal Exim logging, queueing, and reporting model continues to apply to that mail.

Path B: the application intentionally uses an external SMTP provider

Application
    |
    v
smtp.office365.com
    |
    v
Microsoft 365
    |
    v
Recipient

This mail does not pass through local Exim.

Therefore, it is not expected to appear in local Exim logs.

That is not the same as "Exim logging has stopped working".

It means the application selected another SMTP provider.

The operational question is therefore:

Does the hosting operator require visibility and control over all application SMTP traffic, or only over mail that uses the operator's own mail infrastructure?

Different hosting providers may answer that question differently.

Direct-to-MX delivery and authenticated submission are not the same thing

A useful security discussion should distinguish different SMTP patterns.

Direct-to-MX delivery

Compromised process
      |
      v
Recipient MX on port 25

In this case, the hosting server's IP may be the direct SMTP source seen by the recipient's mail infrastructure.

This can create a clear IP reputation risk.

Authenticated SMTP submission

Application
      |
      v
External provider on port 587
      |
      | SMTP AUTH
      v
Provider infrastructure
      |
      v
Recipient

Here, the hosting server is the source of the submission connection, but the external provider normally performs final delivery.

The provider may apply:

authentication;
tenant policy;
rate limits;
anti-abuse controls;
reputation controls;
and account suspension.

This does not make abuse impossible.

It does mean that the risk model is different from a process directly delivering spam to recipient MX servers.

External provider on a custom port

Application
      |
      v
External relay on port 2525

This is yet another model, and the 2025 cPanel Community discussion shows why port-specific behaviour matters.

Treating every form of "external SMTP" as identical can hide important technical differences.

What are the real risks of disabling the restriction?

A neutral assessment should acknowledge the risks clearly.

1. User processes can bypass local Exim

This is the central and intended effect.

An application can use another SMTP provider instead of the local MTA.

2. External SMTP traffic is not visible in Exim logs

If a message never passes through Exim, Exim cannot log its message transaction.

Investigation may require:

network telemetry;
process information;
firewall logs;
endpoint security data;
or evidence from the external provider.

3. A compromised site may use external SMTP credentials

Applications often store service credentials in configuration files or environment variables.

If a site is compromised, an attacker may try to misuse those credentials.

This is not unique to SMTP, but direct external SMTP connectivity can make such misuse possible from the compromised environment.

4. The server IP is still visible as the connection source

Even when the external provider performs final delivery, it can see the IP address that initiated the SMTP submission connection.

Abusive activity may therefore lead to:

provider-side blocking;
investigation;
or abuse complaints.

5. Local Exim limits do not control third-party SMTP traffic

If the application bypasses Exim, local Exim limits are not the enforcement point for that external SMTP transaction.

The external provider's controls become relevant instead.

What disabling the restriction does not automatically mean

It is equally important not to exaggerate.

Disabling SMTP Restrictions does not automatically mean:

Exim logging stops working;
local mail becomes untraceable;
the server becomes an open relay;
every user can send through Microsoft 365 without credentials;
every external SMTP message is delivered from the hosting server's IP;
or the server will automatically be blacklisted.

Those are separate questions.

The actual outcome depends on:

the destination SMTP service;
whether authentication is required;
whether the application uses local Exim or a third-party provider;
the provider's policies;
the firewall configuration;
and the behaviour of the hosted process.

A practical decision framework

Instead of asking:

Is SMTP Restrictions good or bad?

a better set of questions may be:

1. What type of hosting environment is this?

traditional shared hosting;
managed application hosting;
a single-tenant server;
a developer-focused platform;
or a mixed environment?

2. Do customers legitimately need external SMTP?

For example:

Microsoft 365;
Google Workspace;
external transactional mail;
application-specific mail providers.

3. Is the operator's policy to force all SMTP through local Exim?

That can be a valid policy.

But it should be an intentional architecture decision.

4. What visibility exists outside Exim?

If external SMTP is allowed, can the operator investigate unusual outbound connections through:

firewall telemetry;
process monitoring;
endpoint protection;
network monitoring;
or other security controls?

5. What happens when a legitimate application fails?

Can support staff recognise:

expected external SMTP certificate
received local server certificate

as a possible SMTP restriction symptom?

6. Has the decision been tested under a normal hosting user?

A root-level network test may not reproduce user-level restrictions.

A balanced operational approach

Some operators may reasonably choose:

SMTP Restrictions = Enabled

because they prioritise:

centralised mail control;
Exim visibility;
and reducing direct SMTP access from user processes.

Others may reasonably choose:

SMTP Restrictions = Disabled

because they prioritise:

compatibility with modern applications;
customer-managed external email services;
and direct authenticated SMTP submission.

A third group may keep restrictions enabled while using:

external relays on supported custom ports;
smarthost designs;
or other controlled architectures.

There is no useful universal answer without understanding the environment.

Final thoughts

cPanel SMTP Restrictions solve a real problem.

They can reduce the ability of ordinary user processes to bypass the local mail server, which can be valuable in shared hosting environments.

But the same control can also interfere with legitimate applications that intentionally use external SMTP providers.

The most important lesson is not "always enable it" or "always disable it".

It is this:

Understand the actual traffic path before making the decision.

When troubleshooting, test:

as root;
as the hosting user;
and from the actual application runtime.

Inspect:

the SMTP banner;
the TLS certificate;
the destination;
and the user context.

And when deciding whether the restriction belongs in your environment, separate:

direct-to-MX delivery;
authenticated SMTP submission;
external relays;
local Exim traffic;
and custom-port designs.

They are not the same problem.

A simple ON/OFF switch can represent a much larger architectural trade-off.

References

cPanel & WHM Documentation — SMTP Restrictions

https://docs.cpanel.net/whm/security-center/smtp-restrictions/
cPanel Support — How to disable SMTP Restrictions

https://support.cpanel.net/hc/en-us/articles/1500009931961-How-to-disable-SMTP-Restrictions
cPanel Community — Restrict outgoing SMTP, why is bad to allow?

https://support.cpanel.net/hc/en-us/community/posts/19161442634903-Restrict-outgoing-SMTP-why-is-bad-to-allow
cPanel Community — SMTP Restrictions and External SMTP providers

https://support.cpanel.net/hc/en-us/community/posts/34506598182295-SMTP-Restrictions-and-External-SMTP-providers

This article is intended as a technical and operational analysis. It does not recommend one universal configuration for every cPanel server.

[Boost]

Mohammed AlShannaq — Thu, 13 Nov 2025 23:25:07 +0000

Run MkDocs on iPad with iSH and Browse It Locally 🎉

Mohammed AlShannaq — Sat, 04 Oct 2025 01:49:01 +0000

Have you ever thought about turning your iPad into a mini documentation server?
With iSH (a Linux shell for iOS) and MkDocs, you can not only build documentation projects right on your iPad, but also serve and browse them locally in Chrome or Safari on the same device! 🚀

Why do this?

📝 Write and preview your documentation on the go, without a laptop.
💡 Turn your iPad into a self-contained dev and docs environment.
🌍 Browse your MkDocs site locally as if it’s hosted online — but it’s all happening inside your iPad.

Step 1: Install iSH

Grab iSH Shell from the App Store. It runs Alpine Linux inside iOS — lightweight and perfect for experiments like this.

Step 2: Install Python & Build Tools

Inside iSH, update and install the required packages:

apk update
apk add python3 py3-pip build-base python3-dev libffi-dev openssl-dev
pip install --upgrade pip setuptools wheel

Step 3: Install MkDocs

pip install mkdocs mkdocs-material

Check if it works:

mkdocs —version

Step 4: Create a Project

mkdocs new mydocs
cd mydocs

Step 5: Serve the Site

Here’s the magic part — run the built-in dev server on 127.0.0.1:

mkdocs serve -a 127.0.0.1:8000

Step 6: Browse on Your iPad 🎉

Now open Chrome or Safari on your iPad and go to:

http://127.0.0.1:8000/

Boom! You’re browsing your MkDocs site that’s being served locally inside iSH. No extra devices, no external servers — just your iPad.

⚠️ Tip: Keep the iSH app running in the foreground (or in split-screen with Chrome/Safari). If iSH is fully sent to the background, iOS will freeze the process and your local MkDocs server will stop responding.

Final Thoughts

This little hack shows how powerful iSH can be. Pair it with MkDocs, and suddenly your iPad becomes a portable documentation lab. You can edit Markdown, rebuild instantly, and preview it live in your browser — all on one device.

⸻

👉 Would you try running MkDocs (or maybe even other Python-based tools) on your iPad?

Run MkDocs on iPad with iSH and Browse It Locally 🎉

Mohammed AlShannaq — Sat, 04 Oct 2025 01:29:02 +0000

How I Exported and Re-Imported a netcup Server Snapshot (raw.zst qcow2)

Mohammed AlShannaq — Thu, 25 Sep 2025 21:57:30 +0000

When you run servers on netcup (VPS or root Servers), one of the features you get is the ability to take snapshots of your VM. These snapshots can be downloaded as a file and stored locally or on object storage like S3, so you always have a backup you control.

In fact, one of the neat features netcup provides is the option to export snapshots as downloadable files. For many plans, a limited number of exports are included for free, and if you need more, you can purchase additional exports as an add-on.

This gives you the ability to keep offline or external copies of your VM state without relying solely on the built-in snapshot system — especially useful if you ever optimize storage or lose the snapshots stored within netcup’s platform.

🐛 But here’s the catch:

netcup lets you download snapshots in a compressed format:

vda_snapshot.raw.zst

However, when you try to re-upload the same .raw.zst back into netcup’s Server Control Panel (SCP), it fails. Why? Because netcup does not support .zst uploads — only raw, qcow, and qcow2 formats are officially supported and accepted.

In this article explains how I hit this problem, the dead ends I faced, and the working solution to restore my server successfully from a snapshot that I have created before for the server and downloaded it locally on my pc (or store it in AWS S3)

The Problem

I downloaded my snapshot from netcup: vda_alma10readysam1.raw.zst.
I wanted to re-import it via Upload Image → Generate Upload URL. (using netcup SCP) or even upload the image from my pc.
But when I tried to use it directly, and start the server after I receive email says that image installed, the server wouldn’t boot: “no boot device found.”

Why? After couple of tries I see that it happens because .raw.zst is only useful for downloading. netcup won’t accept it as an upload format.

Step 1: Decompress the Snapshot

First, you need to decompress the .zst file into a raw image. Install zstd if it’s missing:

💡 Note: The decompressed raw file will be the same size as your original VM disk (e.g. a 250 GB VM will produce a 250 GB raw file). Make sure you have enough free space on your system before starting the decompression.

First of all make sure zstd is insalled:

# AlmaLinux / Rocky
dnf install -y zstd

# Ubuntu / Debian
apt install -y zstd

Then decompress the .raw.zst file:

unzstd vda_alma10readysam1.raw.zst -o vda_alma10readysam1.raw

Now you have a .raw file.

⚠️ Warning: The raw file size always equals the full disk size of your VM. For example, if your VM had a 250 GB disk, the exported .raw file will be 250 GB — even if you only used 5 GB of actual data.
Trying to upload that 250 GB raw file would be a huge mistake: most of it is just empty space (zeros), so you’d be wasting time, bandwidth, and money moving around data that doesn’t really exist.

That’s exactly why converting to qcow2 is the smarter approach

Step 2: Convert Raw → qcow2

To save space and make uploads feasible, convert the raw image to qcow2. Install qemu-img if not already installed:

# AlmaLinux / Rocky
dnf install -y qemu-img

# Ubuntu / Debian
apt install -y qemu-utils

Convert the raw file:

qemu-img convert -p -O qcow2 vda_alma10readysam1.raw vda_alma10readysam1.qcow2

Now check the result:

qemu-img info vda_alma10readysam1.qcow2

Example output:

image: vda_alma10readysam1.qcow2
file format: qcow2
virtual size: 256 GiB (274877906944 bytes)
disk size: 7.01 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
Child node '/file':
    filename: vda_alma10readysam1.qcow2
    protocol type: file
    file length: 7.01 GiB (7531462656 bytes)
    disk size: 7.01 GiB

💡 Notice how the virtual size is still 256 GB, but the actual file size is just 7 GB. That’s the power of qcow2.

Step 3: Upload to netcup

Log into SCP → Media → Upload Image.
Click Generate Upload URL. (enter the file name for example vda_alma10readysam1.qcow2 ) and generate Upload Url, and the portal will give you Pre-signed URL to upload the file into using curl
Use curl or aws s3 cp to upload your qcow2 file:

url --progress-bar 'https://upload.url.from.netcup...fullurlofuploadurl...' --upload-file vda_alma10readysam1.qcow2 | cat

Once uploaded, select the image and deploy it to a new server.

After this, my server booted normally again 🎉.

👉 Note: You don’t have to use the Generate Upload URL method if you don’t want to. netcup’s SCP also allows you to upload the image directly from your local machine — simply browse for the .qcow2 file and upload it through the web interface. This can be easier for smaller images, but for larger files I still recommend using the upload URL approach.

Step 4: Store Your Snapshots Safely

Instead of keeping snapshots only in netcup, you can store them externally (after you export it)

This way, you can always re-import the image later, or even run it on another virtualization platform that supports qcow2 (Proxmox, KVM, etc.).

Lessons Learned

.raw.zst is download-only. You can’t re-import it to netcup.
You must convert it to raw, qcow, or qcow2 — with qcow2 being my most efficient choice.
Always verify your qcow2 image with qemu-img info before uploading.
Storing qcow2 snapshots externally (S3, local disk, NAS) makes disaster recovery much easier.

Conclusion

What started as a frustrating “no boot device 🤯” error turned into a neat learning experience. By decompressing and converting the snapshot, I was able to restore my VM cleanly and keep smaller, portable backups for the future.

To give you a sense of the savings:

The original snapshot (.raw.zst) was 4.6 GB.
After decompression to raw, it exploded to 256 GB (matching the full disk size).
Once converted to qcow2, it shrank back down to just 7.4 GB — small enough to store and upload efficiently.

If you’re running servers on netcup, don’t just rely on downloading .raw.zst snapshots. Convert them, back them up properly, and make sure you can re-import them when needed. Your future self will thank you.

DEV Community: Mohammed AlShannaq

Understanding cPanel SMTP Restrictions: Security, External SMTP, and the Trade-Offs

What does the setting do?

The legitimate application case

The surprising failure mode

A controlled troubleshooting method

Test 1: connect as root

Test 2: connect as the hosting user

Test 3: test from PHP under the same user

The value of an A/B test

The argument for keeping SMTP Restrictions enabled

1. Centralised control

2. Reduced ability to bypass the local MTA

3. Easier investigation when mail uses Exim

The argument for disabling SMTP Restrictions

1. Modern applications often use external email services

2. Legitimate application SMTP can fail

3. The setting is not an absolute ban on every possible external SMTP design

4. cPanel officially documents disabling the feature for scripts that need to bypass Exim

Does disabling the setting break Exim logging?

Path A: the application still uses local Exim

Path B: the application intentionally uses an external SMTP provider

Direct-to-MX delivery and authenticated submission are not the same thing

Direct-to-MX delivery

Authenticated SMTP submission

External provider on a custom port

What are the real risks of disabling the restriction?

1. User processes can bypass local Exim

2. External SMTP traffic is not visible in Exim logs

3. A compromised site may use external SMTP credentials

4. The server IP is still visible as the connection source

5. Local Exim limits do not control third-party SMTP traffic

What disabling the restriction does not automatically mean

A practical decision framework

1. What type of hosting environment is this?

2. Do customers legitimately need external SMTP?

3. Is the operator's policy to force all SMTP through local Exim?

4. What visibility exists outside Exim?

5. What happens when a legitimate application fails?

6. Has the decision been tested under a normal hosting user?

A balanced operational approach

Final thoughts

References

[Boost]

Top 7 Featured DEV Posts of the Week

Jess Lee for The DEV Team ・ Nov 11

Run MkDocs on iPad with iSH and Browse It Locally 🎉

Step 1: Install iSH

Step 2: Install Python & Build Tools

Step 3: Install MkDocs

Step 4: Create a Project

Step 5: Serve the Site

Step 6: Browse on Your iPad 🎉

Final Thoughts

Run MkDocs on iPad with iSH and Browse It Locally 🎉

How I Exported and Re-Imported a netcup Server Snapshot (raw.zst qcow2)

The Problem

Step 1: Decompress the Snapshot

Step 2: Convert Raw → qcow2

Step 3: Upload to netcup

Step 4: Store Your Snapshots Safely

Lessons Learned

Conclusion