On Sat, Jan 22, 2022 at 09:58:58PM -0500, Alex wrote:
> I have a postfix-3.5.10 server on fedora35 and would like to
> experiment with relaying outbound mail from my Microsoft 365 test
> server through my postfix server to the recipient's final destination
> using certificates as a way to authenticate the sending Microsoft 365
> server. Is this possible?
Yes, of course.
> I would like to set up a digital certificate that's used as a way to
> authenticate the Microsoft 365 client server connecting to the postfix
> server in order for it to be able to relay mail to mail servers on the
> Internet. I recall reading about that many years ago, but I haven't
> been able to find anything that isn't related to using Microsoft 365
> as the relay, or that is using SASL to relay mail TO Microsoft 365,
> not FROM it.
Most of your effort will be on the Microsoft 365 side, configuring the
client side with the right private key and public certificate (or SASL
password) and connect to the *submission* (port 587 or 465) of your
Postfix server, rather than port 25.
The Postfix side is simple:
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_tls_fingerprint_digest = sha256
mua_relay_restrictions =
permit_sasl_authenticated,
check_ccert_access ${indexed}relay_certs
reject
relay_certs:
# LHS generated via:
#
# $ openssl x509 -in cert.pem -pubkey -noout |
# openssl pkey -pubin -outform DER |
# openssl dgst -sha256 -c -hex
#
# When rolling over the client key, publish table entries for the
# old and new digests, then configure the client to use the new key,
# and then after you're sure the old key is no longer in use, drop
# the entry for the old digest.
#
e3:b0:c4:42:98:fc:1c:14:9a:fb:f4:c8:99:6f:b9:24:27:ae:41:e4:64:9b:93:4c:a4:95:99:1b:78:52:b8:55
permit
master.cf:
# port 587
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_ask_ccert=yes
-o smtpd_tls_CAfile=
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_relay_restrictions=$mua_relay_restrictions
-o smtpd_recipient_restrictions=
-o milter_macro_daemon_name=ORIGINATING
# port 465 wrapper mode
submissions inet n - n - - smtpd
-o syslog_name=postfix/submissions
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_ask_ccert=yes
-o smtpd_tls_CAfile=
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=$mua_relay_restrictions
-o milter_macro_daemon_name=ORIGINATING
If you want DKIM signing, configure appropriate milters, if not already
done on the Microsoft end.
This configuration sends an empty list of trusted CA Distinguished Names
to the client, expecting it to unconditionally use the preconfigured
keypair. Trust is by public key fingerprint and cares not for any CAs.
If the client needs a CA name hint to elicit the certificate (typically
Java clients tend to want this, otherwise probably not needed) then
configure a "CAfile" with just the one CA certificate. Only its
Distinguished Name will be used. So you can use an expired certificate,
or one with a key that nobody knows, ... the rest of the cert content
is ignored.
DN="/C=AU/O=Acme Widgets Ltd./CN=..."
openssl req -x509 -newkey rsa:2048 -keyout /dev/null -days 30 -subj "$DN"
where "DN" is the verbatim issuer name of the client cert, it could be
as simple as "/CN=somehost.example" ...
If you don't end up using SASL, set "smtpd_sasl_auth_enable=no" in the
above examples.
--
Viktor.
