Configure Exim4 as an internet mail server
Set a canonical identity, local domains, relay policy, DNS, TLS, aliases, queue monitoring, and end-to-end SMTP tests on Debian or Ubuntu.
Accept mail only for owned domains and send outbound mail directly without becoming an open relay.
- Exim4 4.98+
- Authoritative DNS and stable identity Control forward and reverse DNS, choose the canonical mail hostname and domains, and verify the host is not behind an outbound SMTP-blocking network.
hostname -f; getent ahosts $(hostname -f); dig +short -x {{publicIp}} - Recovery and queue safety Keep console access, back up active configuration, and record queue state before changing routing, authentication, filters, or mailbox delivery.
- Abuse and deliverability plan Define relay boundaries, account owners, rate limits, bounce handling, postmaster address, monitoring, and how compromised credentials will be revoked.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A production Exim implementation of “Configure Exim4 as an internet mail server” with explicit SMTP/IMAP boundaries, identity, durable state and observable delivery evidence.
- A read-only baseline, staged candidate and end-to-end canary covering DNS, TLS, authentication, recipient or route policy, queue/mailbox state and logs.
- A security and rollback procedure that avoids open relay, backscatter, plaintext credentials, world-readable keys/mail and unreviewed bulk queue actions.
- Accept mail only for owned domains and send outbound mail directly without becoming an open relay. The intended success path is visible in native status, protocol transcript, headers or mailbox evidence.
- Expected unauthorized relay, unknown-recipient, wrong-sender, invalid-authentication or wrong-certificate tests fail at the declared boundary without harming unrelated mail.
Architecture
How the parts fit together
The public MTA accepts SMTP on port 25 for domains it is authoritative for, performs recipient and policy checks before queue acceptance, and resolves remote MX records for outbound delivery. A stable PTR/A/AAAA identity, restricted relay policy, local queue and structured logs are operational dependencies. Submission and mailbox access remain separate services. The tutorial proves inbound/local/outbound paths with controlled addresses while preserving a configuration and queue baseline for rollback.
- Inventory hostname/DNS, listeners, certificates, identities, recipient/relay maps, queue/mailbox state, logs and a recoverable configuration/data baseline.
- Prepare the internet mta candidate with official Exim syntax, protected secrets and one explicit service/data boundary at a time.
- Run native configuration validation and immediate read-only checkpoint before reload or acceptance of new messages.
- Use controlled local and external canaries plus an expected-denial test, preserve message identifiers/headers, and retain the prior configuration for rollback.
Assumptions
- The public mail hostname, forward/reverse DNS ownership, supported package version and responsibility for ports 25/587/993 are known.
- A maintenance or canary window, console recovery and current protected backup of configuration, keys, identity mappings and relevant mailbox/queue data exist.
- Test sender and recipient addresses are owned by the operator; no unsolicited or third-party traffic is generated during verification.
- Secrets and private keys are delivered outside shell history and have narrowly defined service ownership and rotation plans.
Key concepts
- envelope identity
- SMTP sender and recipient used for routing, delivery status and SPF; it is distinct from visible message headers.
- open relay
- An MTA that accepts unauthorized third-party sender-to-recipient forwarding, enabling abuse and reputation damage.
- backscatter
- A later non-delivery report sent to a forged sender because an invalid recipient was accepted instead of rejected during SMTP.
- alignment
- DMARC relationship between visible From domain and authenticated SPF or DKIM domain.
- Maildir
- A mailbox format storing messages as individual files in cur/new/tmp directories with strict ownership.
Before you copy
Values used in this guide
{{domain}}Fully qualified public or internal hostname served by this configuration.
Example: example.com{{localTestAddress}}Operator-reviewed value used by this tutorial for localTestAddress; derive it from the target environment and never from untrusted request data.
Example: postmaster@example.com{{mailHost}}Operator-reviewed value used by this tutorial for mailHost; derive it from the target environment and never from untrusted request data.
Example: mail.example.com{{managementCidr}}Trusted administration network in CIDR notation.
Example: 192.0.2.0/24{{publicIp}}Operator-reviewed value used by this tutorial for publicIp; derive it from the target environment and never from untrusted request data.
Example: 192.0.2.20Security and production boundaries
- Never weaken relay/recipient checks, publish private DKIM/TLS keys, enable plaintext authentication, or expose web/IMAP administration broadly to make a test pass.
- Mail content, credentials, queues, logs and backups contain personal or confidential data; restrict, encrypt, minimize and retain them under an explicit policy.
- Use dedicated service identities and root-readable credential maps; verify logs and configuration output are redacted before sharing.
Stop before continuing if
- Stop if a test permits unauthorized relay, accepts unknown recipients for later bounce, sends credentials without verified TLS, or exposes private keys/mailbox files.
- Do not continue when hostname/PTR ownership, package/config version, recipient map, route, queue, mailbox ownership or rollback backup is ambiguous.
- Immediately quarantine the candidate when unrelated mail is rerouted, deleted, multiply delivered, signed by the wrong domain, or inaccessible after reload.
instruction
Verify hostname, forward DNS, reverse DNS, and MX
The primary hostname must resolve to the sending address, PTR should return that hostname, and each hosted domain MX must point to it.
Why this step matters
Verify hostname, forward DNS, reverse DNS, and MX is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
The primary hostname must resolve to the sending address, PTR should return that hostname, and each hosted domain MX must point to it. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Verify hostname, forward DNS, reverse DNS, and MX”. The scope must remain limited to the selected application and supported host.
Syntax explained
hostname- Invokes the principal tool or configuration operation for “Verify hostname, forward DNS, reverse DNS, and MX”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}- Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
Values stay on this page and are never sent or saved.
hostname -f; dig +short A {{mailHost}}; dig +short AAAA {{mailHost}}; dig +short -x {{publicIp}}; dig +short MX {{domain}}Forward, reverse, and MX records form the intended mail identity.
Checkpoint: Checkpoint: Verify hostname, forward DNS, reverse DNS, and MX
Continue whenForward, reverse, and MX records form the intended mail identity. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when hostname reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Verify hostname, forward DNS, reverse DNS, and MX” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v hostname 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
command
Install Exim4 and supporting tools
Install the full daemon, configuration package, CA certificates, DNS tools, and swaks from the distribution repository.
Why this step matters
Install Exim4 and supporting tools is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Install the full daemon, configuration package, CA certificates, DNS tools, and swaks from the distribution repository. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Install Exim4 and supporting tools”. The scope must remain limited to the selected application and supported host.
Syntax explained
apt- Invokes the principal tool or configuration operation for “Install Exim4 and supporting tools”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
&&- Runs the following operation only when the previous command succeeds, preventing a reload or state transition after a failed validation.
sudo apt update && sudo apt install --yes exim4-daemon-heavy exim4-config bsd-mailx swaks ca-certificates dnsutilsExim packages install and no second MTA owns port 25.
Checkpoint: Checkpoint: Install Exim4 and supporting tools
Continue whenExim packages install and no second MTA owns port 25. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when apt reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Install Exim4 and supporting tools” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v apt 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
config
Configure internet-site routing
Use dpkg-reconfigure exim4-config or update-exim4.conf.conf to set dc_eximconfig_configtype=internet, canonical hostname, local domains, listen addresses, and no smarthost.
Why this step matters
Configure internet-site routing is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Use dpkg-reconfigure exim4-config or update-exim4.conf.conf to set dc_eximconfig_configtype=internet, canonical hostname, local domains, listen addresses, and no smarthost. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Configure internet-site routing”. The scope must remain limited to the selected application and supported host.
Syntax explained
dpkg-reconfigure- Invokes the principal tool or configuration operation for “Configure internet-site routing”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
|- Passes standard output to the next read-only inspection stage; review each stage separately if the combined result is surprising.
/etc/exim4/update-exim4.conf.conf- Is the persistent configuration boundary changed by this step. Keep an attributable backup and validate the consumer before reload.
/etc/exim4/update-exim4.conf.confsudo dpkg-reconfigure exim4-config; sudo grep -E '^(dc_eximconfig_configtype|dc_other_hostnames|dc_local_interfaces|dc_readhost|dc_smarthost)' /etc/exim4/update-exim4.conf.confInternet mode, owned domains, and listener policy are explicit.
Checkpoint: Checkpoint: Configure internet-site routing
Continue whenInternet mode, owned domains, and listener policy are explicit. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when dpkg-reconfigure reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Configure internet-site routing” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v dpkg-reconfigure 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
config
Create required administrative aliases
Route postmaster, abuse, hostmaster, and root to a monitored mailbox outside any delivery loop.
Why this step matters
Create required administrative aliases is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Route postmaster, abuse, hostmaster, and root to a monitored mailbox outside any delivery loop. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Create required administrative aliases”. The scope must remain limited to the selected application and supported host.
Syntax explained
sudoedit- Invokes the principal tool or configuration operation for “Create required administrative aliases”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}- Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
/etc/aliases- Is the persistent configuration boundary changed by this step. Keep an attributable backup and validate the consumer before reload.
/etc/aliasesValues stay on this page and are never sent or saved.
sudoedit /etc/aliases; sudo newaliases; exim -bt postmaster@{{domain}}Every required alias resolves to the monitored destination.
Checkpoint: Checkpoint: Create required administrative aliases
Continue whenEvery required alias resolves to the monitored destination. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when sudoedit reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Create required administrative aliases” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v sudoedit 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
verification
Audit local domains and relay controls
Print routers, ACL-related macros, trusted networks, and route tests; do not add broad relay_from_hosts entries.
Why this step matters
Audit local domains and relay controls is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Print routers, ACL-related macros, trusted networks, and route tests; do not add broad relay_from_hosts entries. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Audit local domains and relay controls”. The scope must remain limited to the selected application and supported host.
Syntax explained
exim- Invokes the principal tool or configuration operation for “Audit local domains and relay controls”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}- Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
Values stay on this page and are never sent or saved.
sudo exim -bP primary_hostname local_domains relay_from_hosts; exim -bt user@{{domain}}; exim -bt user@example.netLocal addresses route locally and external recipients require local submission or authentication.
Checkpoint: Checkpoint: Audit local domains and relay controls
Continue whenLocal addresses route locally and external recipients require local submission or authentication. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when exim reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Audit local domains and relay controls” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v exim 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
command
Open only required SMTP and management ports
Allow inbound TCP 25 globally, keep submission/IMAP closed until configured, and restrict SSH to management sources.
Why this step matters
Open only required SMTP and management ports is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Allow inbound TCP 25 globally, keep submission/IMAP closed until configured, and restrict SSH to management sources. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Open only required SMTP and management ports”. The scope must remain limited to the selected application and supported host.
Syntax explained
ufw- Invokes the principal tool or configuration operation for “Open only required SMTP and management ports”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}- Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
Values stay on this page and are never sent or saved.
sudo ufw allow 25/tcp; sudo ufw allow from {{managementCidr}} to any port 22 proto tcp; sudo ufw --force enable; sudo ufw status numberedOnly approved mail and management services are exposed.
Checkpoint: Checkpoint: Open only required SMTP and management ports
Continue whenOnly approved mail and management services are exposed. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when ufw reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Open only required SMTP and management ports” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v ufw 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
verification
Build, validate, and restart Exim
Generate the monolithic configuration, inspect it, run routing tests, restart, and review panic/main/reject logs.
Why this step matters
Build, validate, and restart Exim is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Generate the monolithic configuration, inspect it, run routing tests, restart, and review panic/main/reject logs. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Build, validate, and restart Exim”. The scope must remain limited to the selected application and supported host.
Syntax explained
update-exim4.conf- Invokes the principal tool or configuration operation for “Build, validate, and restart Exim”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
sudo update-exim4.conf; sudo exim -bV; sudo systemctl restart exim4; systemctl is-active exim4; sudo tail -n 50 /var/log/exim4/{mainlog,rejectlog,paniclog}Exim starts without panic log entries and listens on port 25.
Checkpoint: Checkpoint: Build, validate, and restart Exim
Continue whenExim starts without panic log entries and listens on port 25. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when update-exim4.conf reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Build, validate, and restart Exim” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v update-exim4.conf 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
verification
Test inbound, outbound, and relay denial
Use swaks to deliver to a local test mailbox, submit an outbound message from an allowed local path, and prove an unauthenticated external-to-external relay is rejected.
Why this step matters
Test inbound, outbound, and relay denial is a separate checkpoint because it establishes one auditable part of accept mail only for owned domains and send outbound mail directly without becoming an open relay. Performing it independently keeps a failed prerequisite, syntax error, or compatibility mismatch from being hidden by later actions.
What to understand
Use swaks to deliver to a local test mailbox, submit an outbound message from an allowed local path, and prove an unauthenticated external-to-external relay is rejected. Read the complete command or configuration before execution, replace the documented placeholders, and compare the target host with the supported environments listed at the beginning of this tutorial.
Capture the before-state and the exact output in the change record. If this step modifies a file or service, validate the candidate with its native checker before any reload; a successful process exit alone does not prove that the application uses the intended value.
Use a representative staging or canary host first. Repeat the stated checkpoint immediately, because proceeding with ambiguous evidence makes the later end-to-end verification and rollback materially harder.
System changes
- This step may affect the files, packages, identities, services, or runtime policy named in “Test inbound, outbound, and relay denial”. The scope must remain limited to the selected application and supported host.
Syntax explained
swaks- Invokes the principal tool or configuration operation for “Test inbound, outbound, and relay denial”; confirm that it resolves to the expected packaged executable or file before using elevated privileges.
{{…}}- Marks an operator-supplied value. Replace every placeholder deliberately; do not paste untrusted text or leave braces in the production command.
Values stay on this page and are never sent or saved.
swaks --server {{mailHost}} --to {{localTestAddress}} --from sender@example.net; swaks --server {{mailHost}} --to recipient@example.net --from sender@example.orgLocal delivery succeeds; unauthenticated relay receives a 5xx denial.
Checkpoint: Checkpoint: Test inbound, outbound, and relay denial
Continue whenLocal delivery succeeds; unauthenticated relay receives a 5xx denial. Treat this concrete evidence as the minimum success signal and also confirm that unrelated services and the previous healthy path remain unchanged.
Stop whenStop before the next step when swaks reports an error, the output differs materially from the example, an unexpected package/service/path is affected, or the required before-state and rollback artifact are missing.
If this step fails
The command for “Test inbound, outbound, and relay denial” fails, produces no useful evidence, or the expected service/configuration state is absent.
Likely causeA placeholder targets the wrong environment, the installed version uses another path or unit name, permissions are insufficient, or an earlier prerequisite was not satisfied.
command -v swaks 2>/dev/null || truesystemctl --failed --no-pager 2>/dev/null || truejournalctl -p warning -n 50 --no-pager 2>/dev/null || true
ResolutionDo not improvise a privileged workaround. Re-read the environment and variable table, inspect the official source for the installed version, restore the candidate file if necessary, and repeat only this checkpoint.
Security notes
- Keep secrets out of shell history, process arguments, screenshots, logs, and tutorial placeholders. Elevate only the narrow command that requires it and preserve package signature and TLS verification.
Alternatives
- When the host layout or software version differs, use the vendor-supported equivalent in a disposable staging environment and document the mapping before touching production.
Stop conditions
- Stop if the action broadens network exposure, permissions, package sources, writable paths, or service privileges beyond the tutorial's declared architecture.
Finish line
Verification checklist
sudo ss -lntp | grep ':25'; swaks --server {{mailHost}} --quit-after EHLOExim owns port 25 and announces the canonical hostname.sudo exim -bp; sudo test ! -s /var/log/exim4/paniclogQueue contents are understood and the panic log is empty.Recovery guidance
Common problems and safe checks
A message remains queued or the remote server returns a temporary 4xx response.
Likely causeDNS/MX resolution, routing, network reachability, TLS negotiation, remote greylisting/rate limits, reputation or recipient policy prevents delivery.
exim -bp 2>/dev/null || postqueue -pdig +short MX example.netjournalctl -u exim4 -u postfix --since '-30 min' --no-pager
ResolutionInspect one message's recorded diagnostic and route first, fix the evidenced dependency, then retry only that message; do not force an undiagnosed bulk queue.
SMTP accepts a recipient, but the mailbox is absent, unreadable or never visible over IMAP.
Likely causeRecipient maps, LMTP/LDA route, virtual UID/GID, Maildir path, quota, Dovecot namespace or filesystem permissions disagree.
doveconf -ndoveadm user user@example.comdoveadm mailbox list -u user@example.com
ResolutionTrace the exact address through recipient validation, delivery socket and resolved mailbox path; correct the narrow mapping/ownership mismatch before accepting more mail.
Authentication or TLS fails despite apparently correct credentials and certificate files.
Likely causeThe listener uses another configuration, hostname/SAN does not match, chain/key permissions are wrong, authentication is attempted without TLS, or the identity backend maps another username.
openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com </dev/nullopenssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/nulljournalctl -u dovecot -u postfix -u exim4 -p warning -n 100 --no-pager
ResolutionVerify the advertised hostname, chain, listener and mapped user independently; never disable certificate verification or enable plaintext authentication to bypass the failure.
Reference
Frequently asked questions
Why is one successful test email insufficient?
It may bypass the actual external DNS, authentication, recipient, DKIM, queue retry or IMAP path. Test each boundary and preserve protocol/header evidence.
Can TLS be tested by checking that encryption is present?
No. Verify the chain and hostname and ensure authentication is unavailable before STARTTLS; encryption to an unverified endpoint is not server authentication.
Should a stuck queue be forced immediately?
No. Read one message's diagnostic and fix the dependency first. Bulk retries can amplify rate limits, duplicates or reputation damage.
Recovery
Rollback
Restore the archived Exim configuration and firewall rules while preserving queued messages.
- Stop Exim, restore /etc/exim4 and aliases from the pre-change archive, rebuild configuration, and restart.
- Restore the previous firewall policy only after confirming which MTA must receive port 25.
- Never delete the spool during rollback; inspect and preserve queued messages.
Evidence