Let’s do Postfix again but slowly and properly this time – Part 4: Virtual domains

To revisit what I said in the first post in our Postfix series, a virtual setup is one in which email accounts are independent of system accounts. We therefore have to tell Postfix what accounts we have on any given domain, where to put email for an account etc. unlike local delivery where users are given by the system and delivery is by default to a file in /var/mail. In order to create this kind of setup we will have to jettison most of the settings we have worked on so far. On the plus side it will still feel very familiar as settings are often in parallel. And you’ll understand how to properly distinguish between the two kinds of setup.

From the outside there will be no discernible difference. Our Postfix server will accept mail for users on legitimate domains and reject mail for all other destination.


Let’s do Postfix again but slowly and properly this time – Part 3: Opening up to the outside

I promised that in this third part of the series we would finally get to make our SMTP server accessible from the outside, gettting a bit closer to something that actually  resembles a real mail server. I am going to make good on that promise.

There are three aspects to this change. First, we will need to set up our router so that our SMTP server can communicate with the outside world. Secondly, we will need to create a listing for our SMTP server so that other SMTP servers know where to look when they have email for our domain (the MX host setting). Finally we will of course have to adjust our Postfix configuration.


Let’s do Postfix again but slowly and properly this time – Part 2: Address manipulation

In the last post in my Postfix series we went through the basics of configuring Postfix to accept mail. This second part will be a somewhat short addendum in which we cover a few extra settings related to how Postfix finds the right user to deliver mail to. Then in the third post we will finally move on to receiving real mail (as opposed to telnet fakery).

Postfix has an impressive amount of settings that can manipulate where email ends up. I’m only going to cover two and then quickly list some of the others.


Let’s do Postfix again but slowly and properly this time – Part 1: A simple local mail receiving server

About a year ago I wrote a scathing comment about Ars Technica’s too-slow guide to self-hosted email. I wanted it now-now-now and not over the course of four weeks. Well, I guess it’s time to eat humble pie because my setup didn’t survive transfer to the new machine. Seeing as I hadn’t acquired any deep understanding of the setup apart from a purely abstract grasp of email fundamentals I didn’t have any way to fix it.

In short, I’m going to go in the complete opposite direction and take it slow this time. We are going to setup an MTA that will accept email and that we can use to send email. Only when we thoroughly understand that will we move on to Dovecot and the like. We are going to take it step-by-step, making sure that we understand what we’re doing and why we’re doing it and sometimes even what we’re not doing.

In the course of this first piece in a series, we will get some sort of email up and running – and get that warm feeling that we have accomplished something –  but consider it more of a proof-of-concept or a learning experience than anything like the final thing.


Playing fast(cgi) and loose

Problem: On all my non-https enabled WordPress sites, the links to CSS and images were always https which meant they failed, rendering as pure html. Assumption: It’s either a WordPress or an nginx issue. Solution: Turns it it was neither but a bad fastcgi parameter. Lesson: Kids, don’t copy-paste fastcgi parameters.

My amazing aluminium lunchbox: Using a NUC5i3 as HTPC, web server, cloud server and living room gaming PC

I never did buy that Intel NUC D34010WYKH, the home server upgrade that I recognised some two months back was a completely frivolous investment. I didn’t buy it because I bought the new 2015 Broadwell-based model instead. All told I spent 5000 DKR (~€670/$750) on the thing plus components and accessories. So let’s get to the point: Is it just as ridiculous and frivolous a waste of hard-earned cash as I said it would be? Yes, it is. Do I regret it? No, I don’t. Not one bit.


Why I desperately require and really don’t need an Intel NUC D34010WYKH

This is my tech lust. I desire this consumer object like non-technical people crave the most recent iphone model. I have perfectly serviceable server hardware but it leaves me cold. I want something that I can get excited about. This is an Intel NUC D34010WYKH and it’s small, fast, power efficient, expandable and sexy. Throwing away old hardware and putting this in its stead will surely make my (digital) life complete.