My last project has been about securing outgoing mail from one of our systems.
We had a few basic requirements:
1) Mails to customers should not be falsely flagged as spam.
2) Performance. Several thousand mails are sent per day.
3) Reusability: Multiple systems should be able to send mail through the same solution, preferably from multiple domains.
Constraints:
1) The MTA will be placed in our DMZ to be reachable by various systems in multiple domains.
2) The MTA must reach our mail-to-fax converter.
3) The MTA must reach our main mail server cluster without going via external services.
4) Accounts used for outgoing mail should not have mail to them stored on the MTA, but instead relayed to the main mail servers.
Originally we sent our mail via our regular mail servers through a cloud based spam filter service, but our volumes caused this traffic to get throttled by the service provider, breaking the performance requirement.
Next we tried a software called SMTPBeamer, which a colleague of mine had used for a slightly different task, but which seemed promising, easy to set up and doesn’t break the bank. Unfortunately, this program doesn’t have native DKIM signing of mails, which it turns out is pretty mandatory today if one wants to avoid having a large share of sent mail bounce or get stuck in spam filters. In other words this broke our first and perhaps most important requirement.
This caused me to consider a serious mail transfer agent, namely Postfix.
Installation and initial configuration was made dead simple thanks to the excellent walkthrough provided by Christoph Haas, at ISPMail Tutorial. Thanks to his explanations, digging deeper into how Postfix works to complement with further functionality got a lot easier than I had anticipated.
So what pitfalls did we have to cross?
Subdomains
We still send a lot of faxes. They are generated by an appliance connected to our PBX: Basically it listens to mail on the format phonenumber@fax.domain.name. To begin with, I couldn’t get my head around how to make Postfix understand that I wanted mail to that subdomain to be sent to a specific IP address.
Hint: The Postfix documentation is all you need, provided you understand that it requires to be able to look up any recipient domain by DNS. An entry in the hosts file is not enough.
The relevant clue was found in a forum post where the author wrote about the command “host”, which specifically looks up the given host name using DNS rather than the hosts file. After spending hours trying different combinations of relay and transport maps and configurations, just adding the fax subdomain to the zone file for the correct subnet solved the problem immediately. I had understood the Postfix documentation for the necessary transport rules correctly from the start, but I hadn’t understood Postfix.
User accounts
After following the ISPMail Tutorial to the T, I had a perfect little mail server which could send mail using local virtual accounts for authentication, but also accepted mail to these accounts. It would be possible to work around this issue, but this was not the behavior I was looking for. By switching the domain to which these accounts belonged in the database without changing their fully qualified names, and adding their actual domain to relay_domains, along with a transport rule, I can now use the proper mail addresses for authentication, to reduce the risk of spamming while still passing on any mail from one account to another straight to our internal mail servers.
I will soon take the time to describe the solutions and configurations required in more technical detail and hopefully using a lot less prose.
All right… would you care to elaborate on that? I’m assuming that you’re talking about the DNS zone file (in BIND, most likely), am I right? But what exactly is the entry you place there? Is there an MX record or something similar that you will have to deal with?
You see, I have the following issue. I run WordPress on several domains… and subdomains. Similar to your fax scenario above, there is a discrepancy between IP addresses — because I use Cloudflare at the front of my environment — which means that Postfix will attempt to deliver some messages directly to subdomains which have IP addresses in the Cloudflare range (and which will not deliver/forward email, they just act as HTTP/HTTPS reverse proxies).
What I’ve done so far is to CNAME the subdomains to the ‘main’ domain (so that all of them are pointing to the same IP) and added MX records for the subdomain as well. My hope is that anything sent to a mailbox on the subdomain will automatically go to that very mailbox on the domain. I haven’t changed anything on Postfix, though — will Postfix ‘understand’ my setup and deliver things properly? Because, as far as I can interpret your own comment quoted above, that’s exactly what you’ve done. Am I correct?
Thanks in advance for whatever insights you wish to share 🙂
Hi, and thanks for your interest.
This was a really old post, and I have since solved my issue in another way: It’s true that Postfix will ignore the server’s hosts file and attempt to use DNS instead. Usually you do want to set up an MX record for mail enabled domains anyway. But for the kind of use case I had, I ended up using transport_maps (http://www.postfix.org/transport.5.html) where I pointed, for example fax.mydomain.com, at literally `smtp:[192.168.3.94]` where 192.168.3.94 of course is the IP address of a server that can receive email over SMTP.
The brackets “[]” are important specifically to make Postfix treat the target address as a literal address rather than trying to find the MX record for a domain with that name.
It’s not clear to me if you have one or several mail servers listening to all domains and/or subdomains, but the way I understand your post, then yes: You need a mail server that considers itself authoritative for any domain you wish to receive mail for, and you need an MX record for any such domain pointing at the authoritative mail server (or server cluster) for that domain. Otherwise, as you saw, a well-behaved MTA will attempt to deliver mail to the host defined by the domain’s A record (https://datatracker.ietf.org/doc/html/rfc5321#section-5.1).