docs: add cPanel section; drop the outbound-filtering page
Adds a cPanel hosting section so cPanel customers have a correct destination — previously this KB was WHP-only, so cPanel-specific articles had nowhere to redirect to: - cpanel/nameservers (WHMCS 5, 24k views) - cpanel/free-ssl-certificate (WHMCS 8, 18k views) - cpanel/fix-a-403-error (WHMCS 6, 20k views) - cpanel/wordpress-email-from-your-domain (WHMCS 7, 25k views) Rewritten rather than copied where the originals were wrong or thin: - WordPress SMTP told customers to use port 25 unencrypted; now 587/TLS with 465 as the implicit-TLS alternative. - The 403 article now says explicitly that loosening permissions to 777 makes suEXEC refuse harder, since that's the instinctive wrong fix. - AutoSSL gained the actual failure modes (CAA records, .htaccess redirects intercepting validation, domain not added to the account). Also removes email/outbound-spam-filtering, added in the previous commit. Outbound filtering via Baruwa has been disabled and Baruwa is being retired, so the page describes a feature we no longer offer. It needs rewriting around the Proxmox migration before it can ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
AnHonestHost Dev
co-authored by
Claude Opus 5
Claude Opus 5
parent
ee6b6af107
commit
425f364f48
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: Why is my site getting a 403 error?
|
||||
description: A 403 Forbidden on cPanel hosting is almost always file permissions or file ownership. Here's how to check and fix both.
|
||||
sidebar:
|
||||
order: 3
|
||||
---
|
||||
|
||||
import { Steps, Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
A **403 Forbidden** means the web server found your file but refused to serve it. On our cPanel servers that's nearly always one of two things: permissions that are wrong, or files owned by the wrong user.
|
||||
|
||||
We run **suEXEC**, which makes your site's code run as *your* account rather than a shared web-server user. That's a security benefit — one account can't read another's files — but it does mean the server is strict about ownership and permissions.
|
||||
|
||||
## The correct values
|
||||
|
||||
| Item | Permissions |
|
||||
| --- | --- |
|
||||
| Folders | `755` |
|
||||
| Files | `644` |
|
||||
|
||||
Anything **more permissive** (a folder at `777`, a file at `666`) is refused by suEXEC. This surprises people, because loosening permissions is the instinctive fix for a permissions error — here it makes things worse, and it's a genuine security risk.
|
||||
|
||||
## Fixing it in cPanel
|
||||
|
||||
The File Manager handles this without needing a terminal:
|
||||
|
||||
<Steps>
|
||||
|
||||
1. Sign in to cPanel and open **File Manager**.
|
||||
|
||||
2. Navigate to the site's folder. For your primary domain that's normally `public_html`.
|
||||
|
||||
3. Select the folder or file, then click **Permissions** in the toolbar.
|
||||
|
||||
4. Set folders to `755` and files to `644`. To apply to everything beneath a folder at once, tick the **recurse into subdirectories** option and choose whether it applies to files or folders — you'll need one pass for each, since they take different values.
|
||||
|
||||
</Steps>
|
||||
|
||||
## When ownership is the problem
|
||||
|
||||
Permissions are only half of it. Files also have to be owned by your account.
|
||||
|
||||
- **Uploaded over FTP or SFTP?** Ownership is almost certainly fine — the files were created as you.
|
||||
- **Pulled the site down over SSH** with `git clone`, `wget`, `curl`, or unpacked an archive as another user? Ownership may be wrong, and no amount of `chmod` will fix that. The files need `chown` back to your account.
|
||||
|
||||
If you suspect ownership, [open a ticket](https://secure.anhonesthost.com/submitticket.php) — it's a one-command fix from our side and safer than guessing.
|
||||
|
||||
<Aside type="caution">
|
||||
Be careful with recursive commands over SSH. A `chmod -R 777` or a `chown` aimed at the wrong path can break your whole account, and in the case of `777` will leave the site returning 403 anyway. If you aren't confident, ask us.
|
||||
</Aside>
|
||||
|
||||
## If permissions and ownership are both correct
|
||||
|
||||
Other causes of a 403:
|
||||
|
||||
- **No index file.** A folder with no `index.html` or `index.php`, on a server with directory listing disabled, returns 403.
|
||||
- **An `.htaccess` rule** denying access — either one you added, or one a security plugin wrote.
|
||||
- **A security plugin or firewall** blocking your IP after failed logins. Try from a different network or your phone on mobile data; if that works, it's an IP block.
|
||||
|
||||
## Related
|
||||
|
||||
- [Get your free SSL certificate](/cpanel/free-ssl-certificate/)
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Get your free SSL certificate
|
||||
description: Every cPanel account includes free Let's Encrypt certificates through AutoSSL. Here's what has to be in place and what to do if one doesn't issue.
|
||||
sidebar:
|
||||
order: 2
|
||||
---
|
||||
|
||||
import { Steps, Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
Your cPanel hosting includes free SSL certificates from **Let's Encrypt**, issued automatically by cPanel's AutoSSL service. There's nothing to buy and nothing to install by hand.
|
||||
|
||||
## What has to be true first
|
||||
|
||||
AutoSSL can only issue a certificate once both of these are in place:
|
||||
|
||||
<Steps>
|
||||
|
||||
1. **The domain is added to your cPanel account** — as the primary domain, an addon domain, or a subdomain.
|
||||
|
||||
2. **DNS points at our server.** Let's Encrypt validates a certificate by fetching a file from wherever the domain currently resolves. If it still points at your old host, validation fails and no certificate is issued.
|
||||
|
||||
</Steps>
|
||||
|
||||
Check where a domain currently resolves at [whatsmydns.net](https://www.whatsmydns.net/).
|
||||
|
||||
## When it issues
|
||||
|
||||
AutoSSL runs on a schedule — **once every 24 hours**. So after adding a domain and pointing DNS at us, a certificate normally appears within a day without you doing anything.
|
||||
|
||||
Renewals are automatic too. Let's Encrypt certificates are valid for 90 days and AutoSSL renews them well before expiry, so a working site stays working.
|
||||
|
||||
<Aside type="tip">
|
||||
Need it sooner than the next daily run? Confirm DNS is pointing at us, then [open a ticket](https://secure.anhonesthost.com/submitticket.php) — we can trigger AutoSSL by hand and usually have the certificate in place shortly after.
|
||||
</Aside>
|
||||
|
||||
## If a certificate doesn't appear
|
||||
|
||||
Work through these in order — the first two cover most cases:
|
||||
|
||||
- **DNS isn't pointing here yet.** The most common cause by far. Verify at whatsmydns.net that the domain resolves to our server's IP.
|
||||
- **It hasn't been 24 hours.** Give the scheduled run a chance before assuming something is broken.
|
||||
- **The domain isn't actually in your account.** Check cPanel → **Domains**. A domain you own but haven't added is invisible to AutoSSL.
|
||||
- **A redirect is intercepting validation.** Forced redirects — especially domain-wide ones in `.htaccess` — can stop Let's Encrypt from reaching the validation file.
|
||||
- **CAA records are blocking issuance.** If your DNS has a CAA record naming a different certificate authority, Let's Encrypt is refused. It must permit `letsencrypt.org`.
|
||||
|
||||
## Making your site actually use it
|
||||
|
||||
An issued certificate doesn't automatically mean visitors get HTTPS. Once it's in place, make sure your site loads over `https://` and redirects visitors from `http://`. In WordPress, that's usually setting both the **WordPress Address** and **Site Address** to the `https://` version under **Settings → General**.
|
||||
|
||||
## Related
|
||||
|
||||
- [What are my nameservers?](/cpanel/nameservers/)
|
||||
- [Why is my site getting a 403 error?](/cpanel/fix-a-403-error/)
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: What are my nameservers?
|
||||
description: The nameservers to set at your registrar so your domain points at your cPanel hosting with us.
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
Nameservers tell the internet which company is in charge of your domain's DNS. To use your hosting with us, set these at whichever registrar your domain is registered with.
|
||||
|
||||
## Shared and reseller hosting (cPanel01)
|
||||
|
||||
```text
|
||||
ns1.cpanel01.cloud-hosting.io
|
||||
ns2.cpanel01.cloud-hosting.io
|
||||
```
|
||||
|
||||
Both shared and reseller accounts on cPanel01 use the same pair.
|
||||
|
||||
<Aside type="note">
|
||||
**On WHP instead?** WHP servers each have their own nameservers, so there's no single pair to publish here. Yours are shown in WHP on the **Dashboard** page under **Server Information** — see [Add a domain](/whp/how-to/add-a-domain/).
|
||||
</Aside>
|
||||
|
||||
## Setting them
|
||||
|
||||
Nameservers are changed at your **registrar** (whoever you bought the domain from), not in cPanel. Look for a section called *Nameservers*, *DNS*, or *Domain settings*, choose the "custom nameservers" option, and enter both values above.
|
||||
|
||||
If your domain is registered with us, tell us the change you need and we'll make it for you.
|
||||
|
||||
## How long does it take?
|
||||
|
||||
Nameserver changes propagate across the internet gradually — usually within a few hours, occasionally up to 48. You can watch progress at [whatsmydns.net](https://www.whatsmydns.net/).
|
||||
|
||||
During that window some visitors reach the new server while others still reach the old one. That's expected, and it's why we recommend leaving your old hosting active until propagation finishes.
|
||||
|
||||
<Aside type="caution">
|
||||
Changing nameservers moves **all** of your DNS to us — website, email, and anything else. If your email is hosted somewhere other than your website, tell us before you switch so we can recreate those mail records here first. Otherwise mail delivery stops when the change takes effect.
|
||||
</Aside>
|
||||
|
||||
## Related
|
||||
|
||||
- [Flush your DNS cache](/domains/flush-your-dns-cache/) — if you still see the old site after propagation.
|
||||
- [Transferring a domain to us](/domains/transferring-a-domain-to-us/)
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Send WordPress email from your own domain
|
||||
description: Stop WordPress sending as user@server and send from an address on your domain instead, using an SMTP plugin and a real mailbox.
|
||||
sidebar:
|
||||
order: 4
|
||||
---
|
||||
|
||||
import { Steps, Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
If your WordPress site sends mail — contact forms, order confirmations, password resets — you may notice it arrives from something like `user@host.server-host.tld` rather than your own domain.
|
||||
|
||||
That's deliberate. PHP's built-in mail function is configured to send as the account that owns the site, which makes it much harder for a compromised script to forge mail as someone else. The side effect is unbranded — and often poorly delivered — email.
|
||||
|
||||
The fix is to send through a real mailbox on your domain using SMTP.
|
||||
|
||||
<Aside type="tip">
|
||||
This also improves **deliverability**. Mail sent through an authenticated mailbox on your domain passes SPF and DKIM checks; mail sent by PHP as `user@server` frequently doesn't, and lands in spam.
|
||||
</Aside>
|
||||
|
||||
## Step 1 — Create a mailbox to send from
|
||||
|
||||
<Steps>
|
||||
|
||||
1. In cPanel, open **Email Accounts** under the **Email** section.
|
||||
|
||||
2. Create an account for the site to send as — `noreply@yourdomain.com` is the usual choice.
|
||||
|
||||
3. Use the **password generator** and copy the password somewhere temporarily — you'll need it in a moment, and you won't be shown it again.
|
||||
|
||||
4. Set a **mailbox quota**. People reply to `noreply` addresses regardless of the name, and without a quota those replies accumulate against your hosting space indefinitely.
|
||||
|
||||
</Steps>
|
||||
|
||||
## Step 2 — Install an SMTP plugin
|
||||
|
||||
WordPress needs a plugin to route mail through SMTP instead of PHP. Any of the well-maintained ones work:
|
||||
|
||||
- [WP Mail SMTP](https://wordpress.org/plugins/wp-mail-smtp/)
|
||||
- [Easy WP SMTP](https://wordpress.org/plugins/easy-wp-smtp/)
|
||||
- [Post SMTP](https://wordpress.org/plugins/post-smtp/)
|
||||
|
||||
## Step 3 — Configure it
|
||||
|
||||
In the plugin's settings, choose the **Other SMTP** / custom option and enter:
|
||||
|
||||
| Setting | Value |
|
||||
| --- | --- |
|
||||
| **SMTP host** | Your server's hostname (for example `cpanel01.cloud-hosting.io`) |
|
||||
| **Encryption** | TLS |
|
||||
| **Port** | `587` |
|
||||
| **Authentication** | On |
|
||||
| **Username** | The **full** email address — `noreply@yourdomain.com`, not `noreply` |
|
||||
| **Password** | The password you generated |
|
||||
| **From address** | The same mailbox address |
|
||||
|
||||
<Aside type="caution">
|
||||
Use port **587 with TLS**, or **465 with SSL** if your plugin prefers implicit TLS. Don't use port **25** without encryption — it sends your mailbox password across the network in the clear, and many networks block it outright.
|
||||
</Aside>
|
||||
|
||||
Two details that account for most failures: the username has to be the **whole** address, and the **From** address must match the mailbox you authenticated as. A mismatch gets rejected or treated as spoofing.
|
||||
|
||||
## Step 4 — Send a test
|
||||
|
||||
Every one of these plugins has a test-email feature. Use it before assuming it works, and send to an address at a different provider (Gmail, Outlook) rather than another mailbox on your own domain — that exercises the path real recipients take.
|
||||
|
||||
## Related
|
||||
|
||||
- [What are my nameservers?](/cpanel/nameservers/)
|
||||
- **On WHP?** See [Create an email account](/whp/how-to/create-an-email-account/) — the mailbox part differs, the plugin setup is the same.
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: Why we filter outbound email
|
||||
description: We scan mail leaving our servers, not just mail arriving. Here's why, and what to do if a legitimate message gets held.
|
||||
sidebar:
|
||||
order: 1
|
||||
---
|
||||
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
import Support from '~/content/partials/support-link.mdx';
|
||||
|
||||
Most hosts filter the mail arriving at your inbox. We also filter the mail **leaving** our servers — which occasionally surprises people, so here's the reasoning.
|
||||
|
||||
## Why outbound filtering exists
|
||||
|
||||
Large mail providers — Gmail, Outlook / Hotmail, Yahoo and others — judge mail by the **server it came from**, not by who wrote it. If spam leaves our servers, we're recorded as the sender, and our server's address can land on a blocklist.
|
||||
|
||||
That matters even when the spam isn't ours to begin with. A forwarder is the classic case: someone sends spam to an address on our server that forwards to a Gmail account. We didn't originate it, but as far as Gmail is concerned, we handed it over — so it counts against us.
|
||||
|
||||
Once a server is blocklisted, the consequences land on everyone hosted there. Most lists delist within a few days, but some take **up to a year**, and repeated or severe listings can attract longer penalties or a refusal to delist at all. During that time, mail from every customer on the server is at risk of being rejected or sent to spam.
|
||||
|
||||
Outbound filtering is how we keep that from happening. It's not a common feature among hosting providers, and we think it should be.
|
||||
|
||||
## When legitimate mail gets caught
|
||||
|
||||
No filter is perfect. Marketing and bulk mail is the most likely to be held, since it shares many characteristics with the mail the filter is built to stop.
|
||||
|
||||
If a message you sent didn't arrive, [open a ticket](https://secure.anhonesthost.com/submitticket.php) with:
|
||||
|
||||
- the **subject line** of the message;
|
||||
- the **from** address;
|
||||
- the **destination** address;
|
||||
- roughly **when** you sent it.
|
||||
|
||||
That's enough for us to find it in the logs, release it if it's legitimate, and tune the filter so similar messages pass in future.
|
||||
|
||||
<Aside type="tip">
|
||||
Sending genuine bulk or marketing email? Tell us before you start. We can make sure your sending domain is set up so it isn't mistaken for spam — and we'll go over the authentication records and consent rules that keep it landing in inboxes.
|
||||
</Aside>
|
||||
|
||||
## Helping your mail get delivered
|
||||
|
||||
Filtering aside, most delivery problems come down to authentication. Mail from your domain should have **SPF** and **DKIM** records in DNS so receiving servers can verify it really came from you.
|
||||
|
||||
If your domain uses our nameservers, we add an SPF record automatically when you add the domain, and your DKIM records are listed in WHP under **Email → Email Domains (DNS)**. If your DNS lives elsewhere, you'll need to copy those records to your DNS provider yourself — see [Create an email account](/whp/how-to/create-an-email-account/).
|
||||
|
||||
## Related
|
||||
|
||||
- [Create an email account](/whp/how-to/create-an-email-account/)
|
||||
- [Manage DNS records](/whp/how-to/manage-dns-records/)
|
||||
|
||||
## Still stuck?
|
||||
|
||||
<Support />
|
||||
@@ -33,10 +33,10 @@ const PRODUCT_META: Record<string, { title: string; blurb: string; firstSection:
|
||||
blurb: 'Transfer a domain to us, point it at your hosting, and sort out DNS problems.',
|
||||
firstSection: 'transferring-a-domain-to-us',
|
||||
},
|
||||
email: {
|
||||
title: 'Email',
|
||||
blurb: 'How our mail filtering works and what to do when a message does not arrive.',
|
||||
firstSection: 'outbound-spam-filtering',
|
||||
cpanel: {
|
||||
title: 'cPanel hosting',
|
||||
blurb: 'Nameservers, SSL certificates, permissions, and email for our cPanel shared and reseller plans.',
|
||||
firstSection: 'nameservers',
|
||||
},
|
||||
support: {
|
||||
title: 'Support',
|
||||
|
||||
Reference in New Issue
Block a user