Project

General

Profile

Task #2256

Setup a smarthost to relay service and automatic system emails

Added by Guilhem Moulin 6 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Category:
Mail system
Target version:
Team - Q4/2017
Start date:
Due date:
% Done:

0%

Estimated time:
Tags:
URL:

Description

All our boxes need to be able to send out email (such as system mails to hostmaster@tdf). Currently each smtp(8) client establishes TCP/25 connections directly to the remote MTAs. That doesn't scale well, because for each new host we need to take the public part of the generated DKIM key and add a TXT record to the zone. Moreover amavis and clamav are rather greedy in terms of resources, and having an instance of both on each of our hosts seems unnecessary.

This issue is about deploying a (possibly more?) smarthost to relay outgoing email from all our boxes, except

- documentfoundation.org (TDF's mail server, private mailing lists)
- vm192.documentfoundation.org (redmine instance)
- vm194.documentfoundation.org (public mailing lists)
- intranet.documentfoundation.org
- monitoring.documentfoundation.org

Other boxes would use said smarthost as a relayhost, and delegate DKIM signing & virus detection to it. To secure links to the smarthost, each smtp(8) would use a client certificate and public keys should be pinned on both ends, as per the following snippets:

vmXYZ.tdf:/etc/postfix/main.cf
smtp_tls_security_level = may
smtp_tls_cert_file      = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtp_tls_key_file       = /etc/ssl/private/ssl-cert-snakeoil.key
smtp_tls_policy_maps    = hash:$config_directory/tls_policy
smtp_tls_fingerprint_digest = sha256
vmXYZ.tdf:/etc/postfix/main.cf
[smarthost.tdf]:25 fingerprint ciphers=high protocols=!SSLv2:!SSLv3:!TLSv1:!TLSv1.1
  match=$$SHA-256 disgest of the smptd(8)'s SPKI$$
smarthost.tdf:/etc/postfix/main.cf
relay_clientcerts            = hash:$config_directory/relay_clientcerts
smtpd_client_restrictions    = permit_mynetworks, permit_tls_clientcerts
smtpd_relay_restrictions     = …, permit_tls_clientcerts, …
smtpd_recipient_restrictions = …, permit_tls_clientcerts, …
smtpd_tls_ask_ccert          = yes
smarthost.tdf:/etc/postfix/relay_clientcerts
$$SHA-256 disgest of the smtp(8)'s SPKI$$ vmXYZ.tdf
$$SHA-256 disgest of the smtp(8)'s SPKI$$ vmUVW.tdf
…

The SPF policy for vmXYZ.tdf would be

vmXYZ IN TXT "v=spf1 a:smarthost.tdf ?all"

(we could even pre-fill the zone like we do for A records)

The smarthost would also act an MX for nullmailers clients (with either a DISCARD rule for all valid senders, or alias them to hostmaster). This is because some MTAs phone back to verify that the envelope sender address exists. However machines that need to be able to receive email would keep an INADDR_ANY-listening smtpd, and use themselves as MX.

History

#1 Updated by Florian Effenberger 5 months ago

  • Target version changed from Q2/2017 to Q3/2017

For the boxes to be excluded, you can check our DNSWL record, as these send individually
The above list looks rather well, but not entirely sure if there isn't one host missing

#2 Updated by Guilhem Moulin 5 months ago

#3 Updated by Florian Effenberger 3 months ago

Taken from an older discussion, what we also should factor in is lowering internal mail filtering, e.g. from a VM to mail.tdf and other way round. You wrote:

I usually use a different policy bank for that (making amavis listen on
another socket), and add a check_client_access line to the main.cf's
smtpd_recipient_restrictions with a CIDR table:

main.cf:
smtpd_recipient_restrictions =
check_client_access cidr:$config_directory/filter-mynetworks.cidr

/etc/postfix/filter-mynetworks.cidr:
192.168.1.1/24 FILTER amavisfeed:[127.0.0.1]:10042

#4 Updated by Florian Effenberger 3 months ago

And some more of your comments on that:

IMHO the proper way to do that is to deploy a private interface on all
the machines and use a cidr map in the postscreen_access_list (so
internal clients completely bypass postscreen and immediately connect to
the smtpd). I argued for that a couple of infra calls ago, but at the
moment not all VMs have a configured private interface.

For now we could whitelist 89.238.68.0/25 and 2a00:1828:a012::/48, but
for the hosts outside manitu we would have to manually mine the public
IPs (since the mail config of mail.tdf is not deployed by salt).

#5 Updated by Guilhem Moulin 3 months ago

Florian Effenberger wrote:

And some more of your comments on that:

IMHO the proper way to do that is to deploy a private interface on all
the machines and use a cidr map in the postscreen_access_list (so
internal clients completely bypass postscreen and immediately connect to
the smtpd). I argued for that a couple of infra calls ago, but at the
moment not all VMs have a configured private interface.

For now we could whitelist 89.238.68.0/25 and 2a00:1828:a012::/48, but
for the hosts outside manitu we would have to manually mine the public
IPs (since the mail config of mail.tdf is not deployed by salt).

Thanks for the reminder :-) In fact we could avoid that by having using a dedicated smtpd(8) for our internal mail traffic have it listen on a port other than 25 (for instance TCP/587 or TCP/2525). postscreen is only useful on public interfaces; unlike the public one, the private smtpd(8) instance mandates STARTTLS, requests a client cert, and only allows authenticated traffic from known smtp(8) clients.

That being said, using a dedicated subnet from the private IP space avoids the need for encrypted tunnels. But we're already copying public key material for ssh, and it's pretty much the same for self-signed X.509 keypairs.

#6 Updated by Florian Effenberger 3 months ago

Smarthost should also deal with

  • pollux
  • antares

being unable to send mails due to missing FQDN (these are in intranet).

#7 Updated by Florian Effenberger 3 months ago

  • Blocks deleted (Task #2119: undeliverable e-mails)

#8 Updated by Florian Effenberger 3 months ago

  • Target version changed from Q3/2017 to Q4/2017

I'd like to prioritize the SSO topic (unless there's a compelling reason the smarthost is needed right now) for Q3, so re-assigning to Q4

#9 Updated by Guilhem Moulin 3 months ago

We also need to be careful not to use our upstream recursive servers to query DNSBL/DNSWL due to rate limiting. A solution would be to use one (or more) local caching resolver(s), and either query the root DNS servers directly, or spoof NS records for these zones pointing to their respective authoritative servers.

Pointing unbound(8) to the root DNS servers can be done with root-hints: "/etc/unbound/root.hints" (with a cron job to refresh that list regularly).

Also available in: Atom PDF