Mail server testing

dovecot.md

Testing Dovecot server deployment

1. dovecot -n prints out all non-default (manually configured) values from across the Dovecot configuration.
2. systemctl enable --now dovecot to enable and start the Dovecot service. This might give errors, debug as needed.
3. Use doveadm reload to update the changes in configuration. If it doesn't help, try systemctl restart dovecot.
4. doveadm user performs a lookup across Dovecot's user databases.
5. doveadm auth tests authentication for a user.
6. Start up Thunderbird, try to log into the service as one of the users.
7. Try sending an email preferably to another company mail address.
8. Try receiving an email from another company mail address.

Copy all mails from the old mail server to the new one

• doveadm sync = dsync, used for a smart synchronization. (See: man 1 dsync).
• For a one-way sync, doveadm backup is possible. This truncates the destination! (Also see: man 1 dsync, surprisingly).
• Another alternative is using dsync -1 for one-way, merging synchronisation. To merge remote to local, use the -R flag. this holds true for all doveadm sync|backup calls.
• The process has to be multi-step when the volume of stored emails is really large. Perform several synces back-to back and one after swapping out the mail server.

Troubleshooting (and yes, it's mostly SELinux)

The log files have been set in the configuration, but Dovecot can't access them.

Set the correct Linux ownership and permissions:

# chown -R vmail:dovecot /var/log/dovecot/
# chmod -R 660 /var/log/dovecot/

(useful info about setting permissions: Managing File Permissions on Red Hat Access)

Set the correct SELinux context for the log files. CentOS/RHEL/Fedora/Rocky have these permissions correctly set by default, but they might not have been correctly applied. Simply:

# restorecon -RvF /var/log/dovecot

Dovecot can't create mailbox directories.

You have correctly configured the mail_home and mail_location settings, either in the configuration files or in the userdb. Verify the mail location has the correct permissions:

# chown -R vmail:vmail /var/vmail
# chmod -R u+rw,go= /var/vmail

This step is needed, but it won't be enough just yet. There is a known issue related to Dovecot not being able to access the mail directory location on SELinux systems.

First, add a new SELinux file context for the /var/vmail directory and apply it.

# semanage fcontext -a -t mail_home_rw_t '/var/vmail(/.*)?'
# restorecon -RFv /var/vmail

Then run systemctl edit dovecot and add the two following lines to the file that opens:

[Service]
ReadWritePaths=/var/vmail

More helpful troubleshooting commands

Instead of:

# cat /var/log/audit/audit.log | grep "AVC"

... one can use:

# ausearch -m AVC

... or the full command:

# ausearch -m AVC -ts recent | audit2why

To view recent SELinux denials in a very human-readable way, use:

# sealert -l '*'

I can't stress out enough how important this command is! Use it. It'll even give you recommendations on how to fix the particular denials thanks to the setroubleshoot-server that it's part of.

(useful info on managing SELinux policies: Writing a Custom SELinux Policy on Red Hat Access)

postfix.md

Testing Postfix server deployment

1. postconf -n [-f] prints out all non-default (manually configured) values from main.cf. postconf -M [-f] prints out contents from master.cf. Use these to validate the configuration before start.
2. postfix check - Warn about bad directory/file ownership or permissions and create missing directories. (See: man 1 postfix).
3. systemctl enable --now postfix to enable and start the Postfix service. This might give errors, debug as needed.
4. Use systemctl status postfix and journalctl -xe to check the logs and error messages.
5. Use postfix status to verify the Postfix mail server is running.
6. Use postfix reload to reload changes while the server is running. See man 1 postfix for more details.
7. Make sure any mail command is installed. Usually this comes with the mailx or s-nail MUAs. To see available MUAs that provide this command, use dnf provides mail.
8. Test sending a mail from the machine that runs the Postfix server using the mail command (See: how-to-mail.md) to an email you control.
9. Try replying to that email and verify the returned mail. (Still see: how-to-mail.md, also check the logs (see below)).
10. Enable SpamAssassin: systemctl enable --now spamassassin. Check the status with systemctl status spamassassin.
11. Test the SpamAssassin installation by sending a GTUBE test string to the server. Check the SpamAssassin log files to see if the message was filtered properly or use Thunderbird if you already have it set up.

Troubleshooting

Check the log files

• tac -n /var/log/maillog | less
• journalctl -r -u postfix
• journalctl -xe