Who Is This Document For?
Well... like most things.... it depends....
If one or more of following shoes fits:
Just want to get NodeBB up and running with minimum of hassle please I refer you to the tl;dr commentary from my
NodeBB Email Options article.
Intermediate to advanced Linux user. You can likely get this on your own. May be of some value to those unfamiliar with network and server side aspects of SMTP?
Seasoned email administrator? Right. Please do not be too harsh as I'm endeavoring to bridge a gap here... SME commentary welcome.
If, on the other hand:
You're attracted to the "Ops" side of DevOps.
Like to know how things work.
Medium/advanced "beginner" to the Unix/Linux command line and eager to learn.
Have the time to invest in that learning (i.e.
big boss man or some other urgency not twisting your arm to get this done yesterday) and not afraid to RTFM.
Then.......
For Those About to Rock...
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 direction 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:
Isolation and separation of duties. Some favor an all on one approach. I favor dedicated vm's for dedicated tasks. I'd rather not have my app servers initiating connections with the Big Bad Internet. Incoming http(s), smtp, etc. requests from non local VM's is proxied.
Access to prexisting email infrastructure.
Security and stability concerns. All software has bugs. Postfix has weathered extensive scrutiny and audit. As such, I expect it is less vulnerable to things like malformed responses.
Flexibility moving forward. For e.g. you want a daemon to manage NodeBB's outgoing mail queue - and perhaps that daemon also comes in handy for other duties like emailing various reports or alerts to administrators.
Presumptions:
You have a Postfix Null Client configured as outlined in the
Postfix Standard Configuration Readme.
You have NodeBB configured to utilize such as depicted in my screenshot above.
I've mentioned this can get complex in a hurry. Let's see if we give it a little K.I.S.S.
Incoming!!
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.
Outgoing
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 rather than the 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 Cogs & Widgets
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):
Forward Record
null-host-name.your-domain.tld. IN A XXX.YYY.WWW.ZZZ
SPF Record
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"
MX Records
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.domain.tld.
@ IN MX 80 secondary.domain.tld.
Reverse Record
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.
Postmaster
Other systems expect a postmaster address to exist for communication of issues such as bounced mail. Create "postmaster@your-domain.tld", either as a dedicated mailbox or a forward to an existing mailbox, e.g. you@your-domain.tld 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.
Blacklists
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 in in wide spread use, particularly corporate side. It behooves you to check these blacklists from time to time, particularly with a newly minted server.
Bippity Boppity Boo!
Put it together and what have we got?
Robust SMTP daemon relaying outgoing NodeBB email.
Robust and reasonably secure IMAP mailboxes sans administration headaches.
No worries about third party email plugin breakage between version upgrades.
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.
Enjoy! o/
