> The links under "Training" on http://www.postfix.org/docs.html
> are either dead links or are not in the United States (my current work/home
> location)
>
> The problems with the available documentation:
> * There seems to be no consensus about how to configure servers and services
> Example: Certificates - How do you proceed without using "Let's Encrypt" ?
Technically there is no difference between certificates issued by Let's Encrpyt
or any other certification authority (CA).
It's just how you obtain them, often you will be sent an email to e.g.
webmaster@yourdomain to verify you have control
over the domainname or in case of extended verification certificates you need
to send additional legal documents.
> Do you concatenate the server certificate, key, and CA cert chain
> (and in what order) or do you leave them separate ?
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.mailserver.com/privkey.pem
- this holds your private key
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.mailserver.com/fullchain.pem
- this contains the public keys in the following order:
- the public key of your certificate
- the intermediate certificate of the CA (if available)
- the CA's root certificate
smtpd_tls_CAfile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
- this is used when postfix needs to verify connections to other hosts
- it is not affiliated with your Let's Encrypt certificate
- this file is pre-installed on RHEL and contains the certificates of most
public CAs (certification authorities)
> * Key information pieces are missing
> Example: None of the tutorials tell you to enable/start "saslauthd"
As you mentioned dovecot, you don't need saslauthd. Dovecot can create a socket
for sasl authentication.
/etc/dovecot/conf.d/10-master.conf:
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
mode = 0666
}
postfix main.cf:
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
- private/auth is relative to /var/spool/postfix
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_authenticated_header=yes
> There are just too many options we require that are not covered in detail or
> in the combination we need.
>
> What we need:
> * Running on RHEL 8
> * Opportunistic TLS (StartTLS) in place
for incoming connections:
smtpd_tls_security_level = may
for outgoing connections:
smtp_tls_security_level = may
> * DKIM keys, DMARC records, and SPF records in place
This is outside of postfix.
For DKIM there is e.g. opendkim.org but as you mention spamassassin you should
consider rspamd,
which can sign mails as well.
DMARC / SPF are resource records to be defined in your nameserver (dns).
> * Postfix, Amavis, Spam Assassin, Clam-AV on an internal MTA server and a DMZ
> MTA server (relays)
While amavis and spamassassin do work well, processing a message may take a few
seconds due to dns/blacklist queries.
You can start several amavis processes in parallel but if you need high
throughput you should consider rspamd.
You also should implement this as smtpd_proxy_filter so that you can reject
spam rightaway.
With a content_filter, messages are scanned after queuing, which means you
would have to deliver spammails locally
or inform the sender the mail did not reach the intended recipient (bounce
mail).
As spam senders are often faked this would get your server blacklisted in no
time as a backscatter source.
> * Dovecot, Roundcube, PostfixAdmin running on an MDA server behind the relays.
IIRC postfixadmin uses MySQL as a backend which works with dovecot and postfix.
MySQL is a good way to share configuration/credentials between different
servers.
Roundcube uses IMAP (even with tls), it could be run on its own server/virtual
machine for security purposes.
Best regards
Gerald
