I want to set up a relay server with a static ip on the web, which is supposed to accept mails for multiple domains and also send out mails for those domains. Unfortunatly my experience with postfix is less than limited, so I have some generic questions on architecture.

Also, since I was unable to find a "state if the art, following current recommendations" guideline for setting up a mail server, I'm more then happy to add mechanism or configuration details based on recommendations (BSI, NIST, M3aawg etc.) and link them as a reference.

What I have in mind

The relay host(s) are going to be called (relay host list)

• a.mx.my-company.com


• b.mx.my-company.com

and they are going to get each a SSL certificate via Let's encrypt, issued to their respective hostname, for STARTTLS on port 25.

In addition I have a list of domains , which the server should accept mails for (accepted domain list)

• onedomain.com


• onedomain.net


• otherdomain.com

Another list of sender hosts exists, which connect to the relays to send out mail and get connected from the relays to recieve mails (sender host list)

• a.mail.intern.onedomain.com


• b.mail.intern.onedomain.com


• a.mail.intern.otherdomain.com


• mail.holdingcompany.com

There are some users (hostname_sender + "_up") defined, which should get rights to send in the name of the domains (accepted domain relay users)

• user: a.mail.intern.onedomain.com_up; grant: onedomain.com, onedomain.net


• user: b.mail.intern.onedomain.com_up; grant: onedomain.com, onedomain.net


• user: a.mail.intern.otherdomain.com_up; grant: otherdomain.com


• user: mail.holdingcompany.com_up; grant: onedomain.com, onedomain.net, otherdomain.com

And for the other way around a list of users (hostname_sender + "_down") is defined, which enables the relay host(s) to connect back to the sender hosts (delivery user list)

• user: a.mail.intern.onedomain.com_down
  


• user: b.mail.intern.onedomain.com_down
  


• user: a.mail.intern.otherdomain.com_down
  


• user: mail.holdingcompany.com_down
  

Allowing connections on port 25

For extern servers

A normal mail server like yahoo or gmail may want to deliver messages via my relays. The server then should check the basic stuff, like static ip, not on blacklist and if the target domain is in my accepted domain list. This connection may or may not use STARTTLS.

I think about ignoring SPF, as this is not a reliable design. On the other hand I would like to utilize DKIM, to hard bounce any mails that come from a domain which has DKIM configured but the incoming mail doesn't match the signature. Furthermore I would guess it might be a good idea to send a copy of a failed mail to the postmaster, with the error description, just in case some user complains, he doesn't get a mail he's expecting.

For trusted/internal servers/users

A mail server inside some network may connect via port 25, fail any checks (being on a blacklist, having dynamic ip etc.) but must enable STARTTLS and then auth itself via accepted domain relay users. From that point on the connection can be used to send out mails in the name of any domain the user is allowed to. Only relay hosts are supposed to connect via this, not the end users themselfs. This server is also not supposed to add any DKIM information, as it's just a publically "trusted" mail server with a static ip and not on a blacklist.

Delivering mails to the responsible sender host from a relay host

Inside the configuration of my relay host I will find a list (domain forward list)

• onedomain.com, onedomain.net -> a.mail.intern.onedomain.com, b.mail.intern.onedomain.com[, mail.holdingcompany.com]


• otherdomain.com -> a.mail.intern.otherdomain.com[, mail.holdingcompany.com]

Request for comments

I'm trying to establish a good and state of the art standard for myself in setting up email servers. I thought of thsi architecture to give me the most flexebility and the ability to provide mailservers on dynamic IPs. This could potentially reach all the way up to the point that the "on site postfix" availible trough the firewall of the site on a non-standard port will only accept TLS connections with permit_tls_clientcerts.

If a incomming mail for userA@onedomain.com is relayed, it should in my config take the route via any host from my domain forward list for that given domain. The servers themselfs could be on two seperate locations and only each connected via a 16/1MBit line, with different mailboxes on the according IMAP servers. Whilst this would work, due to the internal servers being able to directly exchange mails witch each other, I would like to know if there is a way to go:

• a.mail.intern.onedomain.com -> responese: user exists, but I'm not in charge


• b.mail.intern.onedomain.com -> responese: thank you

Or:

• a.mail.intern.onedomain.com -> responese: user exists, but I'm not in charge


• b.mail.intern.onedomain.com -> responese: user exists, but I'm not in charge


• mail.holdingcompany.com -> responese: user exists, but I'm not in charge


• Notify postmaster, valid address, but no one responsible

Or:

• a.mail.intern.onedomain.com -> responese: unknown user

Or:

• a.mail.intern.onedomain.com -> responese: user exists, but I'm not in charge


• b.mail.intern.onedomain.com -> timeout


• mail.holdingcompany.com -> responese: user exists, but I'm not in charge


• notify postmaster after some retries on b.mail.intern.onedomain.com

What I'm struggeling with

Basically if it is possible to have a setup like this with postfix and how to test the proper functioning of forward, deny and auth mechanisms.

What I was searching for is something like in iptables, where I can have a ruleset something like this

• match "external non blacklisted server" -j external_trustworthy


• match "internal authed with TLS" -j internal_authed


• -j REJECT

And testing this behaviour, so I won't by accident enforce the blacklist policy to the internal_authed, or even worse, grant the external_trustworthy to send mails in the name of my accepted domains.
Besides that I really would wish for Letsencrypt to issue domain based S/MIME certificates, which again would be able to issue and revoke client S/MIME certificates, for a hassle free mail encryption. That's another topic, but still, it requires a solid base, to be able to communicate with "high security" and "not so well" configured SMTP servers around the world.