@gotwf I'm not sure it's been weeks ago I wrote this. 😄
Maybe I did not find this or something didn't work for me. I can't tell you...
Well... like most things.... it depends....
I confess to deploying a Null Client set up for my forums. I thought I'd expand upon this a bit for interested parties not already possessing subject matter expertise but comfortable with the command line and willing to roll up their sleeves. Follows is meant to be a thumbnail sketch to get the DIY inclined pointed in the proper directions rather than exhaustive step by step copy pasta.
Firstly, let's take a look at some reasons why/when this use case may be a fit:
I've mentioned this can get complex in a hurry. Let's see if we give it a little K.I.S.S.
Let's get our biggest hurdle out of the way.
Null clients do not receive incoming mail. Setting up SMTP relays, IMAP server, virus/malware scanner, etc. ups the ante considerably. We've already got enough on our plates, at least for now, embarking upon this Null Client journey so lets save ourselves some grief and off load those duties to a reputable third party service such as Proton Mail.
As always, there's more than one way to do it:
Null client delivers email directly to one of the servers listed in recipient domains MX records.
Null client forwards email to a dedicated SMTP relay host, e.g. the folks handling your incoming mail (you may need to coordinate with them to configure some knobs, e.g. which hosts they will relay email from). Advantages to using a relay host include: 1) Undeliverable mail does not get stuck on your NodeBB server, and 2) Our null client is now initiating outgong SMTP connections with only the relayhost(s) rather than the big bad Internet at large.
Postfix needs to know about your relay host to get this working. Add the following line to your null client's main.cf
relayhost = your-relay-host.domain.tld
You may also choose to specify relayhost via alternate parameters, such as IP address. I recommend sticking with hostnames as IP addresses may change from time to time.
DNS presents yet another challenge and can have a high price for mistakes. So you're best off offloading this to a third party. Good news is your email provider likely bundles this with their service. Your domain registrar surely does. Consider leveraging that. Submit a request to have forward and SPF records added for your NodeBB instance's hostname.
Note: I've used traditional Bind zone file syntax in the examples below. Using this syntax in help desk requests helps avoid confusion. Your provider may well offer a web based UI.
You want records that look similar to the following (mind the trailing periods on fully qualified host names):
null-host-name.your-domain.tld. IN A XXX.YYY.WWW.ZZZ
The purpose of an SPF record is to provide a list of servers authorized to send email from your domain and must therefore necessarily include your third party provder's servers as well as your null client(s).
your-domain.tld. IN TXT "v=spf1 ip4:primary-ip, ip4:secondary-ip, ip4:null-host-ip -all"
Your mailbox provider likely handles configuration of MX records seamlessly but for the sake of completeness....
RFC's dictate primary and secondary mail exchangers. Get these from your mailbox host.
@ IN MX 50 primary-mx.domain.tld. @ IN MX 80 secondary-mx.domain.tld.
Your cloud provider is authoritative for reverse records for IP space assigned to them. Set up a PTR record for your NodeBB host using your providers management ui or submit a request ticket for them to create such for you.
XXX.YYY.WWW.ZZZ.in-addr.arpa. IN PTR null-host-name.your-domain.tld.
I manage my own DNS servers. DKIM is a royal pita for even seasoned adminstrators and imho an accident waiting to happen. Hence, unless you have a passion for learning about this stuff, I recommend letting your email/IMAP provider handle DNS for you, as it is lots easier to have them add an A or CNAME record as necessary for web servers and such than for you to configure and maintain DKIM. Else avoid DKIM entirely.
Other systems expect the existence of a valid postmaster address for communication of issues such as bounced mail, etc. Create "[email protected]", either as a dedicated mailbox or a forward to an existing mailbox, e.g. [email protected] if you prefer not having to check multiple mailboxes. Test this. Don't sweep postmaster mail under the rug lest it come back to haunt you at the most inopportune of times.
We need to ensure our newly minted Null Client is not blacklisted. MX Toolbox offers a meta blacklist check. Barracuda Networks will most likely do so before you've sent even a single email and requires jumping thru their hoops to become delisted. And jump ye' shall because their stuff is in wide spread use, particularly corporate side. It behooves you to check these blacklists from time to time, particularly with a newly minted server.
Put it together and what have we got?
While this method adds complexity it's not too difficult to get set up once you understand some underlying concepts, moving pieces involved and what you're targeting. It also serves as a stepping stone to building out your own email infrastructure should you decide this stuff is all just too much fun.