Fedora 25 impressions

I recently switched from Ubuntu 16.10 to Fedora 25 on my gaming computer just to give it another shot. The mindset in this distribution is slightly different from that of Ubuntu, especially in that releases come more often. For a computer mainly used for playing around, this is not a bad thing, but unfortunately it also shows where Fedora’s weaknesses are, compared to more polished operating systems, and compared to what regular users would accept from a daily driver. A very concrete example is how the operating system handles kernel updates:

Running the non-free nVidia driver – this is my gaming computer first and foremost – ¬†every kernel update seems to break the graphical user environment, at the very least requiring me to perform an additional reboot after showing me the famous white “oh no…” screen. To be fair, the non-free drivers are not part of the core operating system in Fedora, ¬†but would it really be that hard to look for this characteristic event and let it trigger an additional reboot if that’s all it takes?

Otherwise I must say Fedora does what I need it to and does it well. I’ll keep using it for a while and see how it works for me in the long run.


Postfix and subdomain mail delivery

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.

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?


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.