Redo most of the blog in Hugo

Missing posts will have to be added later

11 files changed, 1926 insertions, 0 deletions

diff --git a/content/posts/2016/2016-10-01-on-pastebin.md b/content/posts/2016/2016-10-01-on-pastebin.md
new file mode 100644
index 0000000..cb54542
--- /dev/null
+++ b/content/posts/2016/2016-10-01-on-pastebin.md
@@ -0,0 +1,80 @@
+---
+date: 2016-10-01
+title: On Pastebin
+tags:
+- Pastebin
+- Security
+- Cloudflare
+- Privacy
+---
+
+Pastebin offers itself as a gratis paste service. Although it is probably the
+most well known option out there, it is certainly not the best.
+
+## The security issue
+Pastebin has a couple of issues that harm the visitor's security. This on
+itself should be considered such a bad practice that no-one should consider
+their service at all.
+
+### Cloudflare
+Cloudflare is a [MITM][mitm]. It completely breaks the secure chain of TLS on
+the web, and should not be used. Any service still using Cloudflare should be
+shunned.  There is [another article][cloudflare] on this site which has more
+information on this specific issue. In addition, Cloudflare can be considered a
+privacy issue for the same reasons, as is detailed below.
+
+### Advertisements
+Another issue with regards to security on pastebin are the advertisements.
+While it can be argued that "they need to make money somehow", using ads always
+seems like the worst possible solution. Especially given the way they're
+serving it. The past couple years have shown that advertisements on the web are
+easily abused to serve malware to good netizens who decided to not block all
+ads.
+
+A rant on the state of ads might be appropriate, but this article is
+specifically about Pastebin, so I will just keep it at "third party
+advertisements are a security risk, avoid sites who use them"
+
+## The privacy issue
+Apart from their security issues, Pastebin also offers some privacy issues. As
+stated above, they make use of Cloudflare. This means that whenever you visit
+them, Cloudflare takes note of this. They may even decide that you need to
+perform some additional tasks in order to be allowed to the resource. This
+doesn't happen to most users, but if you're using any anonymization practices,
+this will happen almost every time you visit a site behind Cloudflare.
+
+In addition to telling Cloudflare, you will also tell another third party,
+Google, in case this "additional step" is required. This is done via the new
+reCaptcha system which will inform Google of almost every detail of your
+browser and the behaviour used to solve the puzzle. Incredibly useful for
+fingerprinting you accross multiple locations.
+
+### Then there is Tor
+But, if you're using an anonymization proxy such as Tor, even if you do not
+care about the Cloudflare issue, and you solve the "security check" presented
+to you, Pastebin still refuses to offer you their service. If they are going to
+refuse you service, they should tell you up front, not after you have already
+informed two other harmful parties of your attempt of accessing the resource.
+
+Actually, they should not. They should simply not require you to give up your
+privacy and serve you the content you were looking for. Blocking resources to a
+certain group of users is simply censorship, and should not be the status quo
+on the free internet.
+
+## Alternatives
+Luckily, there are plenty of alternatives that do not treat their users with
+such disrespect. I ask anyone who is still using Pastebin to stop doing this,
+and use any of the alternatives.
+
+* [0bin.net](https://0bin.net/)
+* [cry.nu][crynu] (works like termbin: `nc cry.nu 9999 < file`)
+* [ix.io][ix]
+- [p.tyil.nl][tyilnl] (works like termbin: `nc p.tyil.nl 9999 < file`)
+
+[cloudflare]: /articles/on-cloudflare/
+[crynu]: https://cry.nu
+[hastebin]: http://hastebin.com
+[ix]: http://ix.io/
+[mitm]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
+[termbin]: http://termbin.com
+[tyilnl]: /
diff --git a/content/posts/2016/2016-10-01-on-systemd.md b/content/posts/2016/2016-10-01-on-systemd.md
new file mode 100644
index 0000000..9bd46d8
--- /dev/null
+++ b/content/posts/2016/2016-10-01-on-systemd.md
@@ -0,0 +1,286 @@
+---
+date: 2016-10-01
+title: On Systemd
+tags:
+- Systemd
+- Security
+- GNU+Linux
+---
+
+Systemd once presented itself as being the next generation init system for
+GNU+Linux. When the project started it seemed to be headed in a good direction.
+Unfortunately, it quickly became clear that systemd's goal was not only to
+bring you a quick, new init system.  It planned to do so much more.  This was
+part of the plan, since init systems were generally considered to be in a bad
+state overall it was quickly accepted by most mainstream GNU+Linux
+distributions.  What was at first only an init system became so much more:
+systemd-logind was made to manage tty's, systemd-resolvd was added to act as a
+caching DNS server.  Even networking was added with systemd-networkd to manage
+network interfaces.
+
+**DISCLAIMER**: Systemd is a fast moving project, this may result in
+information here to becoming outdated. If you find any information that is no
+longer correct, please contact me. You can find my contact details [on my
+homepage][tyil].
+
+## Technical issues
+### Security
+From experience, we have seen that systemd's creator, Lennart Poettering, will
+try to assimilate any functionality he can find and add it into systemd.  This
+causes systemd to have a large surface area of attack, adding to and magnifying
+security attack vectors. An init system should be exactly the opposite. To
+compound this issue, we have bugs like [the user-level DoS][systemd-dos],
+which seem to indicate that the software is hardly tested or written by
+programmers who don't use best practices.
+
+### POSIX
+POSIX compliance. Systemd developers seem to detest it. Their common argument
+against retaining POSIX compliance is that "systemd must break POSIX compliance
+in order to further the development of GNU+Linux userland utilities". While
+this may be true in some sense, it is a very bad idea to ignore POSIX
+altogether.
+
+POSIX is one of the reasons that most applications running on GNU+Linux and
+other Unix like systems are very portable. It's a standard that most OS's and
+distro's try to meet, making it easy to port software.
+
+[natermeer on Reddit][reddit-natermeer] said
+> POSIX has almost no relevance anymore.
+>
+> [...]
+>
+> If you care about portability you care about it running on OS X and Windows
+> as well as your favorite \*nix system. POSIX gains you nothing here. A lot
+> of the APIs from many of these systems will resemble POSIX closely, but if
+> you don't take system-specific differences into account you are not going
+> to accomplish much.
+
+> I really doubt that any Init system from any Unix system uses only POSIX
+> interfaces, except maybe NetBSD. All of them are going to use scripts and
+> services that are going to be running commands that use kernel-specific
+> features at some point. Maybe a init will compile and can be executed on
+> pure POSIX api, but that is a FAR FAR cry from actually having a booted and
+> running system.
+
+Which was replied to by [aidanjt][reddit-aidanjt]
+> Wrong, both OS X and Windows have POSIX support, although Window's is emulated,
+> OS X certainly is not, it's fully POSIX compliant. and b) POSIX doesn't have to
+> work identically everywhere, it only has to be more or less the same in most
+> places and downstream can easily patch around OS-specific quirks. Even
+> GNU/Linux and a bunch of the BSDs are merely regarded as 'mostly' POSIX
+> compliant, after all. But if you ignore POSIX entirely, there's ZERO hope of
+> portability.
+>
+> Actually sysvinit is very portable, init.c only has 1 single Linux header which
+> has been #ifdef'ed, to handle the three-finger-salute. You see, init really
+> isn't that complicated a programme, you tell the kernel to load it after it's
+> done it's thing, init starts, and loads distro scripts which starts userspace
+> programmes to carry on booting. No special voodoo magic is really required.
+> POSIX is to thank for that. POSIX doesn't need to be the only library eva, it
+> only needs to handle most of the things you can't do without, without having to
+> directly poke at kernel-specific interfaces.
+>
+> This is why with POSIX, we can take a piece of software written for a PPC AIX
+> mainframe, and make it work on x86 Linux without a complete rewrite, usually
+> with only trivial changes.
+
+### Dependencies and unportability
+Another common issue with systemd is that applications have started to
+needlessly depend on it, forcing systemd onto users that do not wish to use
+systemd for obvious reasons outlined here, reasons outside of this article, or
+simply being unable to use it. Because systemd complies to no cross-platform
+standard and uses many features only available in recent Linux version, it's
+either very hard or impossible to implement systemd in some circumstances.
+
+The list of features it requires is no small one either, as you can see in the
+list [posted by ohset][reddit-ohet]:
+
+- `/dev/char`
+- `/dev/disk/by-label`
+- `/dev/disk/by-uuid`
+- `/dev/random`
+- `/dev/rtc`
+- `/dev/tty0`
+- `/proc/$PID/cgroup`
+- `/proc/${PID}/cmdline`
+- `/proc/${PID}/comm`
+- `/proc/${PID}/fd`
+- `/proc/${PID}/root`
+- `/proc/${PID}/stat`
+- `/proc/cmdline`
+- `/sys/class/dmi/id`
+- `/sys/class/tty/console/active`
+- `BTRFS_IOC_DEFRAG`
+- `CLONE_xxx`
+- `F_SETPIPE_SZ`
+- `IP_TRANSPORT`
+- `KDSKBMODE`
+- `O_CLOEXEC`
+- `PR_CAPBSET_DROP`
+- `PR_GET_SECUREBITS`
+- `PR_SET_NAME`
+- `PR_SET_PDEATHSIG`
+- `RLIMIT_RTPRIO`
+- `RLIMIT_RTTIME`
+- `SCHED_RESET_ON_FORK`
+- `SOCK_CLOEXEC`
+- `TIOCLINUX`
+- `TIOCNXCL`
+- `TIOCVHANGUP`
+- `VT_ACTIVATE`
+- `\033[3J`
+- `audit`
+- `autofs4`
+- `capabilities`
+- `cgroups`
+- `fanotify`
+- `inotify`
+- `ionice`
+- `namespaces`
+- `oom score adjust`
+- `openat()` and friends
+- `selinux`
+- `settimeofday()` and its semantics
+- `udev`
+- `waitid()`
+- numerous GNU APIs like `asprintf`
+
+This made [Gnome][gnome] unavailable for a long time to BSD users and GNU+Linux
+users who wanted to remain with a sane and proven system. Utilities like
+[Gummiboot][gummiboot] are now being absorbed by systemd too. It is only a
+matter of time before you can no longer use this utility without a systemd init
+behind it. There are too many examples of software to list, which are being
+assimilated or made unavailable by lazy or bad developers who choose to depend
+on systemd for whatever reason.
+
+### Speed
+The main selling point many systemd users hail all the time, is speed. They
+place an unusual high amount of value on being a couple seconds faster on boot.
+Systemd gains this speed gain by using parallelization, and many think this is
+unique to systemd. Luckily for those who want to stick to a more sane system,
+this is false. Other init systems, such as [OpenRC][openrc], used by
+[Funtoo][funtoo], and [runit][runit], used by [Voidlinux][voidlinux] both
+support parallel startup of services.  Both these systems use small and
+effective shell scripts for this, and support startup dependencies and the
+like. Systemd brings nothing new to the init world, it just advertises these
+features more agressively.
+
+### Modularity
+The UNIX principle, *make an application perform one task very well*, seems to
+be very unpopular among systemd developers. This principle is one of the
+reasons why UNIX based systems have gotten so popular. Yet, the systemd
+developers seem to despise this principle, and even try to argue that systemd
+actually is modular because **it compiles down to multiple binaries**. This
+shows a lack of understanding, which would make most users uneasy when they
+consider that these people are working on one of the most critical pieces of
+their OS.
+
+The technical problem this brings is that it is very hard to use systemd with
+existing tools. `journald` for instance doesn't just output plain text you can
+easily filter through, save or apply to a pager. I decides for you how to
+represent this information, even if this might be an ineffective way to go
+about it.
+
+### Binary logs
+Hailed by systemd users and developers as a more efficient, fast and secure way
+to store your logs, it is yet another middle finger to the UNIX principles,
+which state that documents intended for the user should be human readable.
+Binary logs are exactly not that. This forces you to use the tools bundled with
+systemd, instead of your preferred solution. This means you need a system with
+systemd in order to read your logs, which you generally need the most when the
+system that generated it crashed. Thanks to systemd, these logs are now useless
+unless you have another systemd available for it.
+
+These logs are also very fragile. It is a common "issue" to have corrupted logs
+when using systemd. Corrupted is here within quotes because the systemd
+developers do not recognize this as a bug. Instead, you should just rotate your
+logs and hope it does not happen again.
+
+The usual counter to this issue is that you *can* tell systemd to use another
+logger. However, this does not stop `journald` from processing them first or
+just not having `journald` at all. As systemd is not modular, you will always
+have all the pieces installed. It should also be noted that this is a
+*workaround*, not a fix to the underlying problem.
+
+## Political issues
+### Aggressively forced upon users
+A point that has made many systemd opponents very wary of this huge piece of
+software is the way it was introduced. Unlike most free software packages,
+systemd was forced into the lives of many users by getting hard dependencies on
+them, or simply absorbing a critical piece of software by the use of political
+power. The two most prominent pieces of software where this has happened are
+[Gnome][gnome] and [`udev`][udev].
+
+The Gnome developers made a hard dependency on systemd. This in effect made
+every gnome user suddenly require systemd. As a result, FreeBSD had to actually
+drop Gnome for a while, as systemd does not run outside of GNU+Linux.
+
+The other, `udev`, was a critical piece of software to manage devices in
+GNU+Linux. Sadly, some political power was shown by Red Hat and `udev` got
+absorbed into systemd. Luckily, the Gentoo guys saw this issue and tried to
+resolve it. As the systemd developers dislike anything that's not systemd
+itself, they stubbornly refused the patches from the Gentoo folks which would
+keep `udev` a single component (and thus usable without systemd). In the end,
+the Gentoo developers forked `udev` into [`eudev`][eudev].
+
+### Unwillingness to cooperate
+Whenever someone from outside the systemd fangroups steps up to actually
+improve systemd in whatever way, the systemd devs seem to be rather
+uncooperative. It is not uncommon for developers from other projects to make a
+change in order for their projects (and usually others) to improve. This
+removes a lot of the cost for the systemd maintainers to deal with all the
+issues created they are creating.
+
+There are some references to the systemd developers being against changes that
+might make systemd less of a problem, but these changes are usually denied with
+petty excuses.
+
+- https://lists.freedesktop.org/archives/systemd-devel/2012-June/005466.html
+- https://lists.freedesktop.org/archives/systemd-devel/2012-June/005507.html
+
+## How to avoid it
+### Choosing a better OS or distribution
+Nowadays, the only way to avoid it without too much trouble, is by simply
+choosing a better OS or distro that does not depend on systemd at all. There
+are a few choices for this:
+
+- \*BSD ([FreeBSD][freebsd], [OpenBSD][openbsd], and others)
+- [Devuan][devuan]
+- [Funtoo][funtoo]
+- [Voidlinux][voidlinux]
+
+It is a shame that it renders a very large chunk of the GNU+Linux world
+unavailable when choosing a distro, but they have chosen laziness over a
+working system. The only way to tell them at this point that they have made a
+wrong decision, is to simply stop using these distros.
+
+### More links
+
+- [Broken by design: systemd][broken-systemd]
+- [Without systemd][without-systemd]
+- [systemd is the best example of Suck][suckless-systemd]
+- [Thoughts on the systemd root exploit][agwa-systemd-root-exploit] (In response to [CVE-2016-10156][cve-2016-10156])
+- ["systemd: Please, No, Not Like This"](https://fromthecodefront.blogspot.nl/2017/10/systemd-no.html)
+
+[agwa-systemd-root-exploit]: https://www.agwa.name/blog/post/thoughts_on_the_systemd_root_exploit
+[broken-systemd]: http://ewontfix.com/14/
+[cve-2016-10156]: http://www.openwall.com/lists/oss-security/2017/01/24/4
+[devuan]: https://devuan.org/
+[eudev]: https://wiki.gentoo.org/wiki/Eudev
+[freebsd]: https://www.freebsd.org/
+[funtoo]: http://www.funtoo.org/Welcome
+[gentoo]: https://gentoo.org
+[gnome]: http://www.gnome.org/
+[gummiboot]: https://en.wikipedia.org/wiki/Gummiboot_(software)
+[openbsd]: https://www.openbsd.org/
+[openrc]: https://en.wikipedia.org/wiki/OpenRC
+[reddit-aidanjt]: https://www.reddit.com/r/linux/comments/132gle/eli5_the_systemd_vs_initupstart_controversy/c72saay
+[reddit-natermeer]: https://www.reddit.com/r/linux/comments/132gle/eli5_the_systemd_vs_initupstart_controversy/c70hrsq
+[reddit-ohet]: https://www.reddit.com/r/linux/comments/132gle/eli5_the_systemd_vs_initupstart_controversy/c70cao2
+[runit]: http://smarden.org/runit/
+[suckless-systemd]: http://suckless.org/sucks/systemd
+[systemd-dos]: https://github.com/systemd/systemd/blob/b8fafaf4a1cffd02389d61ed92ca7acb1b8c739c/src/core/manager.c#L1666
+[tyil]: http://tyil.work
+[udev]: https://wiki.gentoo.org/wiki/Eudev
+[voidlinux]: http://www.voidlinux.eu/
+[without-systemd]: http://without-systemd.org/wiki/index.php/Main_Page
diff --git a/content/posts/2016/2016-10-25-setup-a-vpn-with-cjdns.md b/content/posts/2016/2016-10-25-setup-a-vpn-with-cjdns.md
new file mode 100644
index 0000000..52d9237
--- /dev/null
+++ b/content/posts/2016/2016-10-25-setup-a-vpn-with-cjdns.md
@@ -0,0 +1,212 @@
+---
+date: 2016-10-25
+title: Setup a VPN with cjdns
+tags:
+- Tutorial
+- VPN
+- cjdns
+- GNU+Linux
+- FreeBSD
+---
+
+In this tutorial I will outline a simple setup for a [VPN][vpn] using
+[`cjdns`][cjdns]. Cjdns will allow you to setup a secure mesh vpn which uses
+IPv6 internally.
+
+## Requirements
+For this tutorial, I have used two client machines, both running Funtoo. A
+FreeBSD 11 server is used as a global connection point.
+
+You are ofcourse able to use any other OS or distro supported by cjdns, but you
+may have to update some steps to work on your environment in that case.
+
+## Installation of the server
+### Dependencies
+Before you can begin, we need some dependencies. There's only two of those, and
+they are available via `pkg` to make it even easier. Install them as follows:
+
+```
+pkg install gmake node
+```
+
+### Compiling
+Next up is getting the cjdns sources and compile these, as cjdns is not
+available as a prebuilt package:
+
+```
+mkdir -p ~/.local/src
+cd $_
+git clone https://github.com/cjdelisle/cjdns.git cjdns
+cd $_
+./do
+```
+
+To make the compiled binary available system-wide so we can use it with a
+system service, copy it to `/usr/local/bin` and rehash to make it available as
+a direct command:
+
+```
+cp cjdroute /usr/local/bin/.
+hash -r
+```
+
+### Configuring
+Cjdns provides a flag to generate the initial configuration. This will provide
+you with some sane defaults where only a couple of small changes are needed to
+make it work properly. Generate these defaults with `--genconf`:
+
+```
+(umask 177 && cjdroute --genconf > /usr/local/etc/cjdroute.conf)
+```
+
+The umask will make all following commands write files using `600` permissions.
+This makes sure the config file is not readable by people who shouldn't be able
+to read it. Be sure to check wether the owner of the file is `root`!
+
+Now you can start actually configuring the node to allow incoming connections.
+You have to find the `authorizedPasswords` array in the `cjdroute.conf` file
+and remove the contents of it. Then you can add your own machines in it. This
+guide follows the assumption of two clients, so the config for two clients will
+be shown here. You can add more clients if you wish, ofcourse.
+
+```json
+"authorizedPasswords":
+[
+    {"password": "aeQu6pa4Vuecai3iebah7ogeiShaeDaepha6Mae1yooThoF0oa0Eetha9oox", "user": "client_1"},
+    {"password": "aiweequuthohkahx4tahLohPiezee9OhweiShoNeephe0iekai2jo9Toorah", "user": "client_2"},
+]
+```
+
+If you need to generate a password, you can make use of the tool `pwgen`,
+available at your local package manager. You can then generate new passwords by
+running `pwgen 60 -1`. Change the `60` around if you want passwords of a
+different size.
+
+### Adding a startup service
+rcinit has deceptively easy scripts to make applications available as services.
+This in turn allows you to enable a service at startup. This way you can make
+sure cjdns starts whenever the server boots. You can copy the following
+contents directly into `/usr/local/etc/rc.d/cjdroute`:
+
+```sh
+#!/bin/sh
+
+# PROVIDE: cjdroute
+# KEYWORD: shutdown
+
+#
+# Add the following lines to /etc/rc.conf to enable cjdroute:
+#
+#cjdroute_enable="YES"
+
+. /etc/rc.subr
+
+name="cjdroute"
+rcvar="cjdroute_enable"
+
+load_rc_config $name
+
+: ${cjdroute_config:=/usr/local/etc/cjdroute.conf}
+
+command="/usr/local/bin/cjdroute"
+command_args=" < ${cjdroute_config}"
+
+run_rc_command "$1"
+```
+
+Afterwards, you must enable the service in `/etc/rc.conf.local` like follows:
+
+```
+echo 'cjdroute_enable="YES"' >> /etc/rc.conf.local
+```
+
+## Installation of the clients
+### Dependencies
+The dependencies are still on `gmake` and `node`, so simply install those on
+your clients. This guide assumes using Funtoo for the clients, so installation
+would go as follows:
+
+```
+emerge gmake nodejs
+```
+
+### Compiling
+Compilation is the same as for the server, so check back there for more
+information if you have already forgotten.
+
+### Configuring
+Generating the base configuration is again done using `cjdroute --genconf`,
+just like on the server. On Funtoo, config files generally reside in `/etc`
+instead of `/usr/local/etc`, so you should set the filepath you write the
+configuration to accordingly:
+
+```
+cjdroute --genconf > /etc/cjdroute.conf
+```
+
+Setting up the connections differs as well, as the clients are going to make an
+outbound connection to the server, which is configured to accept inbound
+connections.
+
+You should still clean the `authorizedPasswords` array, as it comes with a
+default entry that is uncommented.
+
+Now you can setup outbound connections on the clients. You set these up in the
+`connectTo` block of `cjdroute.conf`. For this example, the IP 192.168.1.1 is
+used to denote the server IP. Unsurprisingly, you should change this to your
+server's actual IP. You can find the `publicKey` value at the top of your
+server's `cjdroute.conf` file.
+
+On client 1, put the following in your `cjdroute.conf`:
+
+```json
+"connectTo":
+{
+	"192.168.1.1:9416":
+	{
+		"login": "client_1",
+		"password": "aeQu6pa4Vuecai3iebah7ogeiShaeDaepha6Mae1yooThoF0oa0Eetha9oox",
+		"publicKey": "thisIsJustForAnExampleDoNotUseThisInYourConfFile_1.k"
+	}
+}
+```
+
+On client 2:
+
+```json
+"connectTo":
+{
+	"192.168.1.1:9416":
+	{
+		"login": "client_2",
+		"password": "aiweequuthohkahx4tahLohPiezee9OhweiShoNeephe0iekai2jo9Toorah",
+		"publicKey": "thisIsJustForAnExampleDoNotUseThisInYourConfFile_1.k"
+	}
+}
+```
+
+That is all for configuring the nodes.
+
+### Adding a startup service
+You probably want cjdroute to run at system startup so you can immediatly use
+your VPN. For openrc based systems, such as Funtoo, cjdns comes with a ready to
+use service script. To make this available to your system, copy it over to the
+right directory:
+
+```
+cp ~/.local/src/cjdns/contrib/openrc/cjdns /etc/init.d/cjdroute
+```
+
+Now add the service to system startup and start the service:
+
+```
+rc-update add cjdroute default
+rc-service cjdroute start
+```
+
+That should be sufficient to get cjdns up and running for an encrypted VPN. You
+can find the IPs of each of your systems at the top of your `cjdroute.conf`
+files, in the `ipv6` attribute.
+
+[cjdns]: https://github.com/cjdelisle/cjdns
+[vpn]: https://en.wikipedia.org/wiki/Virtual_private_network
diff --git a/content/posts/2016/2016-10-25-setup-nginx-with-lets-encrypt-ssl.md b/content/posts/2016/2016-10-25-setup-nginx-with-lets-encrypt-ssl.md
new file mode 100644
index 0000000..8c7caa0
--- /dev/null
+++ b/content/posts/2016/2016-10-25-setup-nginx-with-lets-encrypt-ssl.md
@@ -0,0 +1,229 @@
+---
+date: 2016-10-25
+title: Setup nginx with Let's Encrypt SSL
+tags:
+- Tutorial
+- LetsEncrypt
+- Nginx
+- SSL
+- Encryption
+---
+
+This is a small tutorial to setup nginx with Let's Encrypt on a FreeBSD server
+to host a static site.
+
+## Install required software
+First you have to install all the packages we need in order to get this server
+going:
+
+```sh
+pkg install nginx py27-certbot
+```
+
+## Configure nginx
+Next is nginx. To make life easier, you should configure nginx to read all
+configuration files from another directory. This allows you to store all your sites in
+separate configurations in a separate directory. Such a setup is a regular site on
+nginx installations on GNU+Linux distributions, but not default on FreeBSD.
+
+Open up `/usr/local/etc/nginx/nginx.conf` and make the contents of the `http`
+block look a as follows:
+
+```nginx
+http {
+    include       mime.types;
+    default_type  application/octet-stream;
+
+    sendfile     on;
+    #tcp_nopush  on;
+
+    keepalive_timeout  65;
+
+    # default paths
+    index index.html;
+
+    # disable gzip - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773332
+    gzip  off;
+
+    # default ssl settings
+    ssl_session_cache          shared:SSL:1m;
+    ssl_session_timeout        5m;
+    ssl_ciphers                HIGH:!aNULL:!MD5:!AES128:!CAMELLIA128;
+    ssl_protocols              TLSv1.2;
+    ssl_prefer_server_ciphers  on;
+    ssl_dhparam                /usr/local/etc/ssl/dhparam.pem;
+
+    # default logs
+    error_log  /var/log/nginx/error.log;
+    access_log /var/log/nginx/acces.log;
+
+    # default server
+    server {
+        listen       80;
+        server_name  localhost;
+
+        location / {
+            root   /usr/local/www/nginx;
+            index  index.html index.htm;
+        }
+
+        error_page  404              /404.html;
+        error_page  500 502 503 504  /50x.html;
+
+        location = /50x.html {
+            root   /usr/local/www/nginx-dist;
+        }
+    }
+
+    # include site-specific configs
+    include sites/*.conf;
+}
+```
+
+This sets default ssl settings for all server blocks that enable ssl. Note that
+these are settings I use, and are in no way guaranteed to be perfect. I did some
+minor research on these settings to get an acceptable rating on
+[SSL Labs][ssllabs]. However, security is not standing still, and there is a
+decent chance that my settings will become outdated. If you have better settings
+that result in a safer setup, please [contact me][contact].
+
+### Setup HTTP
+Due to the way `certbot` works, you need a functioning web server. Since there
+is no usable cert yet, this means hosting a HTTP version first. The tutorial
+assumes a static HTML website to be hosted, so the configuration is pretty
+easy.
+
+Put the following in `/usr/local/etc/nginx/sites/domain.conf`:
+
+```nginx
+# static HTTP
+server {
+    # listeners
+    listen 80;
+    server_name domain.tld www.domain.tld;
+
+    # site path
+    root /srv/www/domain/_site;
+
+    # / handler
+    location / {
+        try_files $uri $uri/ =404;
+    }
+
+    # logs
+    error_log  /var/log/nginx/error.log;
+    access_log /var/log/nginx/access.log;
+}
+```
+
+If your site's sources do not reside in `/srv/www/domain/_site`, change the
+path accordingly. This guide will continue using this path for all examples, so
+be sure to modify this where needed. In the same vein, the domain `domain.tld`
+will be used. Modify this to your own domain.
+
+### Start nginx
+Nginx is now configured to host a single site over HTTP. Now is the time to enable
+the nginx service. Execute the following:
+
+```sh
+echo 'nginx_enable="YES"' >> /etc/rc.conf.local
+```
+
+This will enable nginx as a system service. On reboots, it will be started
+automatically. You can also start it up without rebooting by running the
+following:
+
+```sh
+service nginx start
+```
+
+## Configure Let's Encrypt
+Nginx is now running as your web server on port 80. Now you can request Let's
+Encrypt certificates using `certbot`. You can do so as follows:
+
+```sh
+certbot certonly --webroot -w /srv/www/domain/_site -d domain.tld -d www.domain.tld
+```
+
+In case you want to add any sub domains, simply add more `-d sub.domain.tld`
+arguments at the end. If the DNS entries for the domains resolve properly, and
+no unexpected errors occur on the Let's Encrypt side, you should see a message
+congratulating you with your new certs.
+
+If your domains do not resolve correctly, `certbot` will complain about this.
+You will have to resolve your DNS issues before attempting again.
+
+If `certbot` complains about an unexpected error on their side, wait a couple
+minutes and retry the command. It should work, eventually.
+
+Once `certbot` has ran without errors, the required files should be available
+in `/usr/local/etc/letsencrypt/live/domain.tld`.
+
+## Configure nginx with SSL
+The certificate has been issued and base nginx is running. Now is the time to
+re-configure your site on nginx to host the HTTPS version of your site instead.
+Open up `/usr/local/etc/nginx/sites/domain.conf` again, and make the contents
+look like the following:
+
+```nginx
+# redirect HTTPS
+server {
+    # listeners
+    listen 80;
+    server_name domain.tld *.domain.tld;
+
+    # redirects
+    return 301 https://$host$request_uri;
+}
+
+# static HTTPS
+server {
+    # listeners
+    listen  443 ssl;
+    server_name  domain.tld www.domain.tld;
+
+    # site path
+    root  /srv/www/domain/_site;
+
+    # / handler
+    location / {
+            try_files $uri $uri/ =404;
+    }
+
+    # enable HSTS
+    add_header  Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
+
+    # keys
+    ssl_certificate      /usr/local/etc/letsencrypt/live/domain.tld/fullchain.pem;
+    ssl_certificate_key  /usr/local/etc/letsencrypt/live/domain.tld/privkey.pem;
+}
+```
+
+Do not forget to update all the paths to match your setup!
+
+As a final step, you should generate the dhparam file. This is to avoid the
+issues as described on [Weak DH][weakdh].
+
+```sh
+openssl gendh -out /usr/local/etc/ssl/dhparam.pem 4096
+```
+
+Be aware that this step can take a **very** long time. On the test machine I
+used to test this tutorial, with 1 core and 1 GB ram, it took nearly 1 hour to
+generate this file.
+
+### Reload nginx
+The final step is to reload the nginx configuration so it hosts the SSL version
+of your site, and redirects the HTTP version to the HTTPS version. To do this,
+simply run
+
+```sh
+service nginx reload
+```
+
+That should be all to get your site working with HTTP redirecting to HTTPS, and
+HTTPS running using a gratis Let's Encrypt certificate.
+
+[contact]: https://www.tyil.work/
+[ssllabs]: https://www.ssllabs.com/ssltest/analyze.html?d=tyil.work&latest
+[weakdh]: https://weakdh.org/
diff --git a/content/posts/2016/2016-10-31-freebsd-mailserver-part-1-preparations.md b/content/posts/2016/2016-10-31-freebsd-mailserver-part-1-preparations.md
new file mode 100644
index 0000000..9fc04e7
--- /dev/null
+++ b/content/posts/2016/2016-10-31-freebsd-mailserver-part-1-preparations.md
@@ -0,0 +1,140 @@
+---
+date: 2016-10-31 07:57:50
+title: "FreeBSD email server - Part 1: Preparations"
+tags:
+- Tutorial
+- FreeBSD
+- Email
+---
+
+This tutorial is devised into multiple chapters to make it more manageable, and
+to be able to better explain why certain parts are needed.
+
+The tutorial is created out of experience setting up my own email server. I have
+read through quite a lot of documentation so you do not have to. Nonetheless, I
+would recommend doing so. Email business is a tricky one, with a lot of moving
+parts that have to fit into each other. Knowing how exactly each part works will
+greatly help understanding why they are needed in a proper email server.
+Besides that, it will make your life a lot more enjoyable if you want to tweak
+some things after this tutorial.
+
+To kick off, some preparations should be done before you start on setting up
+your own email server.
+
+## DNS setup
+Some DNS setup is required for mail. Most importantly, the MX records of a
+domain. Be sure you have a domain available, otherwise, get one. There are
+plenty of registrars and the price is pretty low for most domains. If you want
+to look hip, get a `.email` TLD for your email server.
+
+For the DNS records themselves, make sure you have an `A` record pointing to
+the server IP you're going to use.  If you have an IPv6 address, set up an
+`AAAA` record as well. Mail uses the `MX` DNS records. Make one with the value
+`10 @`. If you have multiple servers, you can make MX records for these as
+well, but replace the `10` with a higher value each time (`20`, `30`, etc).
+These will be used as fallback, in case the server with pointed to by the `10`
+record is unavailable.
+
+## PostgreSQL
+Next up you will have to install and configure [PostgreSQL][postgres]. Although
+using a database is not required, this tutorial will make use of one. Using a
+database makes administration easier and allows you to add a pretty basic web
+interface for this task.
+
+### Installation
+Since the tutorial uses FreeBSD 11, you can install PostgreSQL easily by running
+
+```
+pkg install postgresql96-server
+```
+
+### Starting up
+In order to start Postfix, you should enable the system service for it. This
+way, `service` can be used to easily manage it. In addition, it will start
+automatically on boot.
+
+```
+echo 'postgresql_enable="YES"' >> /etc/rc.conf.local
+service postgresql start
+```
+
+### Database initialization
+Since PostgreSQL is a little different than the more popular [MySQL][mysql], I
+will guide you through setting up the database as well. To begin, switch user
+to `postgres`, which is the default administrative user for PostgreSQL. Then
+simply open up the PostgreSQL CLI.
+
+```
+su postgres
+psql
+```
+
+Once you are logged in to PostgreSQL, create a new user which will hold
+ownership of the database and make a database for this user.
+
+```sql
+CREATE USER postfix WITH PASSWORD 'incredibly-secret!';
+CREATE DATABASE mail WITH OWNER postfix;
+```
+
+Once this is done, create the tables which will hold some of our configuration
+data.
+
+#### domains
+```sql
+CREATE TABLE domains (
+    name VARCHAR(255) NOT NULL,
+    PRIMARY KEY (name)
+);
+```
+
+#### users
+```sql
+CREATE TABLE users (
+    local VARCHAR(64) NOT NULL,
+    domain VARCHAR(255) NOT NULL,
+    password VARCHAR(128) NOT NULL,
+    PRIMARY KEY (local, domain),
+    FOREIGN KEY (domain) REFERENCES domains(name) ON DELETE CASCADE
+);
+```
+
+#### aliases
+```sql
+CREATE TABLE aliases (
+    domain VARCHAR(255),
+    origin VARCHAR(256),
+    destination VARCHAR(256),
+    PRIMARY KEY (origin, destination),
+    FOREIGN KEY (domain) REFERENCES domains(name) ON DELETE CASCADE
+);
+```
+
+## Let's Encrypt
+### Installation
+Installing the [Let's Encrypt][letsencrypt] client is just as straightforward
+as the PostgreSQL database, using `pkg`.
+
+```
+pkg install py27-certbot
+```
+
+### Getting a certificate
+Requesting a certificate requires your DNS entries to properly resolve. If they
+do not resolve yet, Let's Encrypt will bother you with errors. If they do
+resolve correctly, use `certbot` to get your certificate.
+
+```
+certbot certonly --standalone -d domain.tld
+```
+
+## Conclusion
+This should be everything required to get started on setting up your own email
+server. Continue to [part 2][part-2] of this series to start setting up
+Postfix.
+
+[freebsd]: https://www.freebsd.org/
+[letsencrypt]: https://letsencrypt.org/
+[mysql]: https://www.mysql.com/
+[part-2]: /post/2016/10/31/freebsd-mailserver-part-2-mailing-with-postfix/
+[postgres]: https://www.postgresql.org/
diff --git a/content/posts/2016/2016-10-31-freebsd-mailserver-part-2-mailing-with-postfix.md b/content/posts/2016/2016-10-31-freebsd-mailserver-part-2-mailing-with-postfix.md
new file mode 100644
index 0000000..58d822f
--- /dev/null
+++ b/content/posts/2016/2016-10-31-freebsd-mailserver-part-2-mailing-with-postfix.md
@@ -0,0 +1,316 @@
+---
+date: 2016-10-31
+title: "FreeBSD email server - Part 2: Mailing with Postfix"
+tags:
+- Tutorial
+- FreeBSD
+- Email
+- Postfix
+---
+
+Welcome to the second part of my FreeBSD email server series. In this series, I
+will guide you through setting up your own email service. Be sure to done the
+preparations from [part 1][part-1] of this series.
+
+This part will guide you through setting up email service on your machine using
+[Postfix][postfix]. Basic installation is pretty straightforward, but there is
+a lot to configure. If you are not sure what some configuration options do,
+please read up on them. There is a lot to do wrong with a mail server, and
+doing things wrong will likely get you on a blacklist which will make other
+servers stop processing the mail you are trying to send out.
+
+Setting up Postfix is one of the harder parts of configuring a mail server. If
+you have questions after reading the full guide, please find me on IRC. You can
+find details on how to do so on [my homepage][home].
+
+## Installing Postfix
+Installation procedures on FreeBSD are pretty straightforward. Unlike `certbot`
+from the previous part, we will need to compile Postfix from source in order to
+use PostgreSQL as a database back-end. Thanks to FreeBSD's
+[ports][freebsd-ports], this is not difficult either. If this is your first
+port to compile, you probably need to get the ports tree first. You can
+download and extract this using the following command.
+
+{% highlight sh %}
+portsnap fetch extract
+{% endhighlight %}
+
+Once that has finished running, go into the directory containing the build
+instructions for Postfix, and start the installation process.
+
+{% highlight sh %}
+cd /usr/ports/mail/postfix
+make configure install
+{% endhighlight %}
+
+This will open a pop up with a number of options you can enable or disable. The
+enabled defaults are fine, but you will have to enable the `PGSQL` option. This
+will allow you to use the configuration tables created in part 1.
+
+## Enabling Postfix
+Enable the Postfix service for rcinit. This allows you to use `service postfix
+start` once configuration is done, and will auto start the service on system
+boot. In addition, the default mailer on FreeBSD, [sendmail][sendmail] should
+be disabled so nothing is in Postfix's way when trying to deal with processing
+email traffic.
+
+{% highlight sh %}
+# disable the default sendmail system
+echo 'daily_clean_hoststat_enable="NO"' >> /etc/periodic.conf.local
+echo 'daily_status_mail_rejects_enable="NO"' >> /etc/periodic.conf.local
+echo 'daily_status_include_submit_mailq="NO"' >> /etc/periodic.conf.local
+echo 'daily_submit_queuerun="NO"' >> /etc/periodic.conf.local
+echo 'sendmail_enable="NONE"' >> /etc/rc.conf.local
+
+# enable postfix
+echo 'postfix_enable="YES"' >> /etc/rc.conf.local
+{% endhighlight %}
+
+## Configuring Postfix
+There is a ton to configure for Postfix. This configuration happens in two
+files, `main.cf` and `master.cf`. Additionally, as some data is in the
+PostgreSQL database, three files with information on how to query for this
+information are needed. All of these files are in `/usr/local/etc/postfix`.
+
+The guide has a comment line for most blocks. It is advised that **if** you
+decide to just copy and paste the contents, you copy that along so you have
+some sort of indication of what is where. This could help you out if you ever
+need to change anything later on.
+
+### main.cf
+#### Compatibility
+The configuration file starts off by setting the compatibility level. If
+postfix updates the configuration scheme and deprecates certain options, you
+will be notified of this in the logs.
+
+{% highlight ini %}
+# compatibility
+compatibility_level = 2
+{% endhighlight %}
+
+#### Directory paths
+These options indicate where Postfix will look and keep certain files required
+for correct operation.
+
+{% highlight ini %}
+# directory paths
+queue_directory = /var/spool/postfix
+command_directory = /usr/local/sbin
+daemon_directory = /usr/local/libexec/postfix
+data_directory = /var/db/postfix
+{% endhighlight %}
+
+#### Domain configuration
+The domain configuration instruct the server of the domain(s) it should serve
+for. Use your FQDN without sub domains for `mydomain`. You can use a sub domain
+for `myhostname`, but you are not required to. The most common setting is
+using a `mail` sub domain for all mail related activities, which would
+result in something like this.
+
+{% highlight ini %}
+# domain configuration
+myhostname = mail.domain.tld
+mydomain = domain.tld
+myorigin = $mydomain
+{% endhighlight %}
+
+#### Listening directives
+All internet devices it should listen on, and all domains this server should
+consider itself the endpoint for, should be listed here. The defaults in the
+example block are good enough, as we put some of our data in the PostgreSQL
+database instead.
+
+{% highlight ini %}
+# listening directives
+inet_interfaces = all
+mydestination = $myhostname, localhost.$mydomain, localhost
+{% endhighlight %}
+
+#### Reject unknown recipients
+How to deal with messages sent to an email address whose domain points to your
+server's address, but have no actual mailbox. A code of `550` means to inform
+the remote server that delivery is not possible and will not be possible. This
+should stop the remote server from trying it again.
+
+{% highlight ini %}
+# reject unknown recipients
+unknown_local_recipient_reject_code = 550
+{% endhighlight %}
+
+#### Trust
+{% highlight ini %}
+# trust
+mynetworks_style = host
+{% endhighlight %}
+
+#### Address extensions
+This block is optional. It allows you to use email address extensions. These
+are addresses with an additional character in them that will drop the email in
+the non extended address' mailbox, but allows you to quickly filter on them as
+the sent-to address contains the extension.
+
+{% highlight ini %}
+# address extensions
+recipient_delimiter = +
+{% endhighlight %}
+
+#### Virtual domain directives
+This part is where things get important. Virtual domains allow you to handle
+mail for a large number of domains that are different from the actual server's
+domain. This is where the database configuration comes in to play. It is
+important to note the `static:125` values. The `125` should map to the `UID` of
+the `postfix` user account on your system.
+
+{% highlight ini %}
+# virtual domain directives
+virtual_mailbox_base = /srv/mail
+virtual_mailbox_domains = pgsql:/usr/local/etc/postfix/pgsql-virtual-domains.cf
+virtual_mailbox_maps = pgsql:/usr/local/etc/postfix/pgsql-virtual-users.cf
+virtual_alias_maps = pgsql:/usr/local/etc/postfix/pgsql-virtual-aliases.cf
+virtual_uid_maps = static:125
+virtual_gid_maps = static:125
+virtual_transport = lmtp:unix:private/dovecot-lmtp
+{% endhighlight %}
+
+#### TLS setup
+The TLS setup configures your server to use secure connections. The keys used
+here have been generated in the previous part of this series.
+
+{% highlight ini %}
+# TLS setup
+smtpd_tls_cert_file = /usr/local/etc/letsencrypt/live/domain.tld/fullchain.pem
+smtpd_tls_key_file = /usr/local/etc/letsencrypt/live/domain.tld/privkey.pem
+smtpd_use_tls = yes
+smtpd_tls_auth_only = yes
+{% endhighlight %}
+
+#### SASL setup
+SASL deals with the authentication of the users to your email server.
+
+{% highlight ini %}
+# SASL setup
+smtpd_sasl_type = dovecot
+smtpd_sasl_path = private/auth
+smtpd_sasl_auth_enable = yes
+smtpd_recipient_restrictions =
+    permit_sasl_authenticated,
+    permit_mynetworks,
+    reject_unauth_destination
+smtpd_relay_restrictions =
+    permit_sasl_authenticated,
+    permit_mynetworks,
+    reject_unauth_destination
+{% endhighlight %}
+
+#### Debugging
+The debugging options are generally useful in case things break. If you have
+little traffic, you could leave them on forever in case you want to debug
+something later on. Once your server is working as intended, you should turn
+these options off. The postfix logs get pretty big in a short amount of time.
+
+{% highlight ini %}
+# debugging
+debug_peer_level = 2
+debugger_command =
+    PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/binary
+    ddd $daemon_directory/$process_name $process_id & sleep 5
+{% endhighlight %}
+
+#### Installation time defaults
+These options should not be touched, but are very important to have for your
+server.
+
+{% highlight ini %}
+# install-time defaults
+sendmail_path = /usr/local/sbin/sendmail
+newaliases_path = /usr/local/bin/newaliases
+mailq_path = /usr/local/bin/mailq
+setgid_group = maildrop
+html_directory = /usr/local/share/doc/postfix
+manpage_directory = /usr/local/man
+sample_directory = /usr/local/etc/postfix
+readme_directory = /usr/local/share/doc/postfix
+inet_protocols = ipv4
+meta_directory = /usr/local/libexec/postfix
+shlib_directory = /usr/local/lib/postfix
+{% endhighlight %}
+
+### master.cf
+For the `master.cf` file, you can use the following configuration block.
+
+{% highlight cfg %}
+submission    inet  n       -       n       -       -       smtpd
+  -o syslog_name=postfix/submission
+  -o smtpd_tls_security_level=encrypt
+  -o smtpd_sasl_auth_enable=yes
+  -o smtpd_reject_unlisted_recipient=no
+  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
+  -o milter_macro_daemon_name=ORIGINATING
+pickup        unix  n       -       n       60      1       pickup
+cleanup       unix  n       -       n       -       0       cleanup
+qmgr          unix  n       -       n       300     1       qmgr
+tlsmgr        unix  -       -       n       1000?   1       tlsmgr
+rewrite       unix  -       -       n       -       -       trivial-rewrite
+bounce        unix  -       -       n       -       0       bounce
+defer         unix  -       -       n       -       0       bounce
+trace         unix  -       -       n       -       0       bounce
+verify        unix  -       -       n       -       1       verify
+flush         unix  n       -       n       1000?   0       flush
+proxymap      unix  -       -       n       -       -       proxymap
+proxywrite    unix  -       -       n       -       1       proxymap
+smtp          unix  -       -       n       -       -       smtp
+relay         unix  -       -       n       -       -       smtp
+showq         unix  n       -       n       -       -       showq
+error         unix  -       -       n       -       -       error
+retry         unix  -       -       n       -       -       error
+discard       unix  -       -       n       -       -       discard
+local         unix  -       n       n       -       -       local
+virtual       unix  -       n       n       -       -       virtual
+lmtp          unix  -       -       n       -       -       lmtp
+anvil         unix  -       -       n       -       1       anvil
+scache        unix  -       -       n       -       1       scache
+{% endhighlight %}
+
+### SQL query files
+The following three configuration files deal with the SQL query files to make
+Postfix able of getting some of its configuration from a database. You
+obviously have to change the first 4 directives to match your database
+authentication credentials.
+
+#### pgsql-virtual-domains.cf
+{% highlight ini %}
+user = postgres
+password = incredibly-secret!
+hosts = 127.1
+dbname = mail
+query = SELECT 1 FROM domains WHERE name='%s';
+{% endhighlight %}
+
+#### pgsql-virtual-users.cf
+{% highlight ini %}
+user = postgres
+password = incredibly-secret!
+hosts = 127.1
+dbname = mail
+query = SELECT 1 FROM users WHERE local='%u' AND domain='%d';
+{% endhighlight %}
+
+#### pgsql-virtual-aliases.cf
+{% highlight ini %}
+user = postfix
+password = nope
+hosts = 127.1
+dbname = mail
+query = SELECT destination FROM aliases WHERE origin='%s';
+{% endhighlight %}
+
+## Conclusion
+This should be enough Postfix configuration, for now. Next part involves
+Dovecot, which will enable IMAP. It will also provide the SASL mechanism
+defined in this part.
+
+[freebsd-ports]: https://www.freebsd.org/ports/
+[home]: /
+[part-1]: /post/2016/10/31/freebsd-mailserver-part-1-preparations/
+[postfix]: http://www.postfix.org/
+[sendmail]: http://www.sendmail.com/sm/open_source/
diff --git a/content/posts/2016/2016-10-31-freebsd-mailserver-part-3-dovecot-imap-sasl.md b/content/posts/2016/2016-10-31-freebsd-mailserver-part-3-dovecot-imap-sasl.md
new file mode 100644
index 0000000..0938a5e
--- /dev/null
+++ b/content/posts/2016/2016-10-31-freebsd-mailserver-part-3-dovecot-imap-sasl.md
@@ -0,0 +1,228 @@
+---
+date: 2016-10-31 07:57:50
+title: "FreeBSD email server - Part 3: Dovecot, IMAP and SASL"
+tags:
+- Tutorial
+- FreeBSD
+- Email
+- Dovecot
+- IMAP
+- SASL
+---
+
+Welcome to the second part of my FreeBSD email server series. In this series, I
+will guide you through setting up your own email service. Be sure to read the
+previous parts before trying to continue on this part in case you have not done
+so yet.
+
+This part will guide you through setting up [Dovecot][dovecot]. This service
+will deal with the SASL authentication to your email server and making your email
+boxes accessible via IMAP. While this guide does not cover POP3 functionality,
+Dovecot can handle this as well.
+
+Just like the Postfix setup, Dovecot has quite a few configuration options to
+set before it will work as expected in this setup. If you have questions after
+reading the full guide, please find me on IRC. You can find details on how to
+do so on [my homepage][home].
+
+## Installing Dovecot
+Dovecot will also be installed from the ports tree from FreeBSD. As this guide
+assumes you are working through them in order, explanation of acquiring the
+ports tree will be omitted here.
+
+You can start the installation procedure with the following commands.
+
+```
+cd /usr/ports/mail/dovecot2
+make configure install
+```
+
+Again, like with the Postfix installation, leave the default options on and add
+the `PGSQL` option so Dovecot can use PostgreSQL as the database back-end.
+
+## Enabling Dovecot
+Enable the Dovecot service for rcinit.
+
+```
+echo 'dovecot_enable="YES"' >> /etc/rc.conf.local
+```
+
+## Configuring Dovecot
+To start of with Dovecot configuration, copy over the sample files first.
+
+```
+cp -r /usr/local/etc/dovecot/example-config/* /usr/local/etc/dovecot/.
+```
+
+Now you can start editing a number of pesky files. The file names of the
+headings all appear relative to `/usr/local/etc/dovecot`.
+
+### dovecot.conf
+Here you only have to set which protocols you want to enable. Set them as
+follows.
+
+```ini
+protocols = imap lmtp
+```
+
+### conf.d/10-master.cf
+The `master.cf` configuration file indicates which sockets Dovecot should use
+and provide and as which user its processes should be ran. Keep the defaults as
+they are, with the exception of the following two blocks.
+
+#### service imap-login
+This will enable imaps, IMAP over SSL, and disable plain IMAP.
+
+```ini
+service-imap-login {
+    inet_listener imap {
+        port = 0
+    }
+
+    inet_listener imaps {
+        port = 993
+        ssl = yes
+    }
+}
+```
+
+#### services
+This will instruct Dovecot to provide a service for authentication and `lmtp`
+the **local mail transport protocol**. This is required to deliver the email
+files into the correct email box location in the file system.
+
+```ini
+service auth {
+    unix_listener auth-userdb {
+        mode = 0600
+        user = postfix
+        group = postfix
+    }
+
+    unix_listener /var/spool/postfix/private/auth {
+        mode = 0666
+        user = postfix
+        group = postfix
+    }
+
+    user = dovecot
+}
+
+service lmtp {
+    unix_listener /var/spool/postfix/private/dovecot-lmtp {
+        mode = 0600
+        user = postfix
+        group = postfix
+    }
+}
+
+service auth-worker {
+    user = postfix
+}
+```
+
+### conf.d/10-ssl.conf
+Here you have to enable SSL and provide the correct paths to your SSL key in
+order for Dovecot to work with them.
+
+```ini
+ssl = required
+ssl_cert = < /usr/local/etc/letsencrypt/live/domain.tld/fullchain.pem
+ssl_key = < /usr/local/etc/letsencrypt/live/domain.tld/privkey.pem
+```
+
+### conf.d/10-mail.conf
+The mail.conf location instructs Dovecot which location to appoint for storing
+the email files. `%d` expands to the domain name, while `%n` expands to the
+local part of the email address.
+
+```ini
+mail_home = /srv/mail/%d/%n
+mail_location = maildir:~/Maildir
+```
+
+Make sure the location set by `mail_home` exists and is owned by `postfix`!
+
+```
+mkdir -p /srv/mail
+chown postfix:postfix /srv/mail
+```
+
+### conf.d/10-auth.conf
+This file deals with the authentication provided by Dovecot. Mostly, which
+mechanisms should be supported and what mechanism should be used to get the
+actual credentials to check against.  Make sure the following options are set
+as given
+
+```ini
+disable_plaintext_auth = yes
+auth_mechanisms = plain
+```
+
+Also, make sure `!include auth-system.conf.ext` is commented **out**. It is not
+commented out by default, so you will have to do this manually. In addition,
+you have to uncomment `!include auth-sql.conf.ext`.
+
+### conf.d/auth-sql.conf.ext
+This is the file included from `10-auth.conf`. It instructs Dovecot to use SQL as
+the driver for the password and user back-ends.
+
+```ini
+passdb {
+    driver = sql
+    args = /usr/local/etc/dovecot/dovecot-sql-conf.ext
+}
+
+userdb {
+    driver = prefetch
+}
+
+userdb {
+    driver = sql
+    args = /usr/local/etc/dovecot/dovecot-sql-conf.ext
+}
+```
+
+### dovecot-sql.conf.ext
+The final configuration file entails the queries which should be used to get the
+required information about the users. Make sure to update the `password` and possibly
+other parameters used to connect to the database. You may have to update the `125` as
+well, as this has to be identical to the `UID` of `postfix`.
+
+As a side note, if you are following this tutorial on a machine that does
+**not** support Blowfish in the default glib, which is nearly every GNU+Linux
+setup, you **can not** use `BLF-CRYPT` as the `default_pass_scheme`. You will
+have to settle for the `SHA-512` scheme instead.
+
+```ini
+driver = pgsql
+connect = host=127.1 dbname=mail user=postfix password=incredibly-secret!
+default_pass_scheme = BLF-CRYPT
+password_query = \
+    SELECT \
+        local AS user, \
+        password, \
+        '/srv/mail/%d/%n' AS userdb_home, \
+        125 AS userdb_uid, \
+        125 AS userdb_gid \
+    FROM users \
+    WHERE local='%n' AND domain='%d';
+
+user_query = \
+    SELECT \
+        '/srv/mail/%d/%n' AS home \
+        125 AS uid, \
+        125 AS gid \
+    FROM users \
+    WHERE local='%n' AND domain='%d';
+```
+
+## Conclusion
+After this part, you should be left with a functioning email server that
+provides IMAP over a secure connection. While this is great on itself, for
+actual use in the wild, you should setup some additional services. Therefore,
+in the next part, we will deal with practices that "authenticate" your emails
+as legit messages. Be sure to read up on it!
+
+[dovecot]: http://dovecot.org/
+[home]: /
diff --git a/content/posts/2016/2016-10-31-freebsd-mailserver-part-4-message-authentication.md b/content/posts/2016/2016-10-31-freebsd-mailserver-part-4-message-authentication.md
new file mode 100644
index 0000000..62a2799
--- /dev/null
+++ b/content/posts/2016/2016-10-31-freebsd-mailserver-part-4-message-authentication.md
@@ -0,0 +1,159 @@
+---
+date: 2016-10-31 20:00:38
+title: "FreeBSD email server - Part 4: Message authentication"
+tags:
+- Tutorial
+- FreeBSD
+- Email
+- DKIM
+- SPF
+---
+
+Welcome to another part in the FreeBSD email server series. This time, we are
+going to setup some mechanisms to deal with message authentication. This
+practice will make other email providers accept your email messages and deliver
+them properly in the inbox of the receiving user, instead of their spam box.
+
+We will do so using three of the most common practices: [SPF][spf],
+[DKIM][dkim] and [DMARC][dmarc].
+
+## DKIM
+### Installation
+The tools for DKIM are easily installed using `pkg`.
+
+```
+pkg install opendkim
+```
+
+### Configuration
+Write the following configuration into `/usr/local/etc/mail/opendkim.conf`.
+
+```apache
+# logging
+Syslog  yes
+
+# permissions
+UserID  postfix
+UMask   007
+
+# general settings
+AutoRestart         yes
+Background          yes
+Canonicalization    relaxed/relaxed
+DNSTimeout          5
+Mode                sv
+SignatureAlgorithm  rsa-sha256
+SubDomains          no
+X-Header            yes
+OversignHeaders     From
+
+# tables
+KeyTable      /usr/local/etc/opendkim/key.table
+SigningTable  /usr/local/etc/opendkim/signing.table
+
+# socket
+Socket  inet:8891@localhost
+
+# domains
+Domain    domain.tld.privkey
+KeyFile   /usr/local/etc/opendkim/domain.tld
+Selector  mail
+```
+
+#### Postfix
+Postfix needs to be instructed to sign the messages with a DKIM header using
+the opendkim service. You can do so by inserting the following configuration
+block somewhere around the end of `/usr/local/etc/postfix/main.cf`.
+
+```ini
+# milters
+milter_protocol = 2
+milter_default_action = reject
+smtpd_milters =
+    inet:localhost:8891
+```
+
+#### System service
+OpenDKIM runs as a system service. As such, you will have to enable this
+service in rcinit. This is a simple step, achieved with the given command.
+
+```
+echo 'milteropendkim_enable="YES"' >> /etc/rc.conf.local
+```
+
+Do not forget to actually start the service when you are done with the
+tutorial!
+
+### Creating and using keys
+In order to use DKIM, you will need to generate some keys to sign the messages
+with. You cannot use your Let's Encrypt SSL keys for this. First, create a
+directory to house your domain's keys.
+
+```
+mkdir -p /usr/local/etc/opendkim/keys/domain.tld
+chown -R postfix:wheel $_
+```
+
+Next up, generate your first key.
+
+```
+opendkim-genkey -D /usr/local/etc/opendkim/keys -b 4096 -r -s $(date +%Y%m%d) -d domain.tld
+```
+
+I tend to use the current date for the key names so I can easily sort them by
+the most recent one.
+
+Afterwards, you will have to add a line to two separate files to instruct DKIM
+to use this key for a certain domain when signing mail. These are fairly
+straightforward and can be done using a simple `echo` as well.
+
+```
+echo '*@domain.tld  domain.tld' >> /usr/local/etc/opendkim/signing.table
+echo "domain.tld  domain.tld:$(date +%Y%m%d):/usr/local/etc/opendkim/keys/domain.tld/$(date +%Y%m%d).private" \
+  >> /usr/local/etc/opendkim/key.table
+```
+
+### Adding the DNS records
+You may have already noticed that `opendkim-genkey` also creates a `.txt` file
+in addition to the private key. This text file contains the DNS record value
+you need to add for your domain's DNS. Add the record to your DNS server, and
+simply wait for it to propagate.
+
+## SPF
+SPF is simply a DNS record that shows which IPs are allowed to email for that
+domain.
+
+### Adding the DNS records
+A simple example for an SPF record is the following. It allows mail to be sent
+in the domain's name from any IP listed in the MX records.
+
+```
+v=spf1 mx -all
+```
+
+## DMARC
+DMARC is, like SPF, a DNS record. It tells how to deal with messages coming
+from the server and where to report abuse of your server. Some of the larger
+email providers send out reports to the address given in the DMARC record so
+you can figure out whether someone is spamming from your servers, for example.
+
+### Adding the DNS records
+A simple DMARC policy to get started with is to quarantine all emails that fail
+authentication. This means the emails will go into the receiving user's spam
+box. In addition, abuse reports will be sent to the address defined in the
+`rua`.
+
+```
+v=DMARC1; p=quarantine; rua=mailto:abuse@domain.tld
+```
+
+## Conclusion
+These few simple measures will make receiving servers trust the authenticity of
+the mails you send. In effect, your messages will be much less likely to be
+marked as spam.  However, you are a target of spam as well. How you can deal
+with that, will be available in the next part of this series.
+
+[dkim]: http://www.dkim.org/
+[dmarc]: http://dmarc.org/
+[spf]: https://en.wikipedia.org/wiki/Sender_Policy_Framework
+
diff --git a/content/posts/2016/2016-10-31-freebsd-mailserver-part-5-filtering-mail.md b/content/posts/2016/2016-10-31-freebsd-mailserver-part-5-filtering-mail.md
new file mode 100644
index 0000000..07f8e21
--- /dev/null
+++ b/content/posts/2016/2016-10-31-freebsd-mailserver-part-5-filtering-mail.md
@@ -0,0 +1,132 @@
+---
+date: 2016-10-31 20:02:19
+title: "FreeBSD email server - Part 5: Filtering mail"
+tags:
+- Tutorial
+- FreeBSD
+- Email
+- Postfix
+- SpamAssassin
+- Pigeonhole
+---
+
+Being able to send mail and not be flagged as spam is pretty awesome on itself.
+But you also get hit by a lot of spam. The more you give out your email address
+and domain name, the more spam you will receive over time. I welcome you to
+another part of the FreeBSD email server series. In this part, we will set up
+email filtering at the server side.
+
+We will accomplish this with a couple packages, [SpamAssassin][spamassassin]
+and [Pigeonhole][pigeonhole]. The former deals with scanning the emails to
+deduce whether it is spam or not. The latter filters messages. We will use this
+filtering to drop emails marked as spam by SpamAssassin into the Junk folder,
+instead of the inbox.
+
+## Installing the packages
+Both packages are available through FreeBSD's `pkg` utility. Install them as
+such.
+
+```
+pkg install dovecot-pigeonhole spamassassin
+```
+
+## SpamAssassin
+### Enabling the service
+Like most services, you have to enable them as well. Pigeonhole is an extension
+to Dovecot, and Dovecot will handle this one. SpamAssassin requires you to
+configure the service as well. You can enable it and set sane configuration to
+it with the following two commands.
+
+```
+echo 'spamd_enable="YES"' >> /etc/rc.conf.local
+echo 'spamd_flags="-u spamd -H /srv/mail"' >> /etc/rc.conf.local
+```
+
+### Acquiring default spam rules
+SpamAssassin has to "learn" what counts as *spam* and what counts as *ham*. To
+fetch these rules, you should execute the updates for SpamAssassin with the
+following command.
+
+```
+sa-update
+```
+
+You most likely want to run this once every while, so it is advised to setup a
+cronjob for this purpose.
+
+## Postfix
+In order to have mails checked by SpamAssassin, Postfix must be instructed to
+pass all email through to SpamAssassin, which will hand them back with a
+`X-Spam-Flag` header attached to them. This header can be used by other
+applications to treat it as spam.
+
+### master.cf
+There's not much to include to the already existing Postfix configuration to
+enable SpamAssassin to do its job. Just open `/usr/local/etc/postfix/master.cf`
+and append the block given below.
+
+```ini
+spamassassin  unix  -       n       n       -       -       pipe
+  user=spamd argv=/usr/local/bin/spamc
+  -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
+```
+
+## Pigeonhole
+Pigeonhole is an implementation of Sieve for Dovecot. It deals with filtering
+messages on the server side using a set of rules, defined in a file usually
+named `sieve`. This file is generally saved at
+`/srv/mail/domain.tld/user/sieve`. A default file to filter spam out is the
+following example.
+
+```sieve
+require [
+    "fileinto",
+    "mailbox"
+];
+
+if header :contains "X-Spam-Flag" "YES" {
+    fileinto :create "Junk";
+    stop;
+}
+```
+
+This looks for the `X-Spam-Flag` header, which is added by SpamAssassin. If it
+is set to `YES`, this indicates SpamAssassin thinks the message is spam. As
+such, sieve is instructed to filter this message into the folder `Junk`, and to
+create this folder if it does not exist yet. The `stop;` makes sieve stop
+trying to process this message further based on later rules.
+
+## Dovecot
+Dovecot needs some additional configuration to work with Pigeonhole. Modify the
+following files and add the contents described.
+
+### conf.d/20-lmtp.conf
+This will enable Pigeonhole in Dovecot.
+
+```ini
+protocol lmtp {
+  mail_plugins = $mail_plugins sieve
+}
+```
+
+### conf.d/90-plugin.conf
+This configures Pigeonhole to look for a file named `sieve` in the mailbox
+homedir, and execute that when delivering mail.
+
+```ini
+plugin {
+  sieve = /srv/mail/%d/%n/sieve
+}
+```
+
+## Conclusion
+Spam is a pain, especially if you get a lot of it. The configuration added in
+this part of the FreeBSD email server series should get rid of most of it. This
+also concludes the series. If you have any questions or suggestions, please
+contact me via any of the methods detailed on [my home page][home].
+
+Thanks for reading along, and enjoy your very own email server!
+
+[home]: /
+[pigeonhole]: http://pigeonhole.dovecot.org/
+[spamassassin]: https://spamassassin.apache.org/
diff --git a/content/posts/2016/2016-11-24-freebsd-mailserver-calendars-and-contacts.md b/content/posts/2016/2016-11-24-freebsd-mailserver-calendars-and-contacts.md
new file mode 100644
index 0000000..b39120f
--- /dev/null
+++ b/content/posts/2016/2016-11-24-freebsd-mailserver-calendars-and-contacts.md
@@ -0,0 +1,141 @@
+---
+date: 2016-11-24 08:26:09
+title: "FreeBSD email server - Part +: Calendars and contacts"
+tags:
+- Tutorial
+- FreeBSD
+- Email
+- CalDAV
+- CardDAV
+---
+
+This guide is an addition to the [FreeBSD email server series][tutorial-email].
+It is not required for your email server to operate properly, but it is often
+considered a very important feature for those who want to switch from a third
+party email provider to their own solution. It does build upon the completed
+series, so be sure to work through that before starting on this.
+
+## Install required packages
+```
+pkg install py27-radicale
+```
+
+## Configure Radicale
+### /usr/local/etc/radicale/config
+Open up the `/usr/local/etc/radicale/config` file, and update each `[block]`.
+
+#### [server]
+The server is binding to `localhost` only. This way it is not accessible on
+`:5232` from outside the server. Outside access will be provided through an
+nginx reverse proxy instead.
+
+```ini
+hosts = 127.1:5232
+daemon = True
+
+dns_lookup = True
+
+base_prefix = /
+can_skip_base_prefix = False
+
+realm = Radicale - Password required
+```
+
+#### [encoding]
+```ini
+request = utf-8
+stock = utf-8
+```
+
+#### [auth]
+```ini
+type = IMAP
+
+imap_hostname = localhost
+imap_port = 143
+imap_ssl = False
+```
+
+#### [storage]
+```ini
+type = filesystem
+filesystem_folder = /usr/local/share/radicale
+```
+
+#### [logging]
+```ini
+config = /usr/local/etc/radicale/logging
+```
+
+### /usr/local/etc/radicale/logging
+This file is fine on the defaults in FreeBSD 11. This saves you from
+configuring a little bit.
+
+## Configure Dovecot
+### Enable imap
+This option was disabled in the [IMAP server tutorial][tutorial-email],
+however, if we want to auth using the same credentials as the mailserver, this
+option is needed again. Bind it to `localhost`, so it can only be used
+internally. In `/usr/local/etc/dovecont/conf.d/10-master.conf`, enable the
+`imap` port again:
+
+```ini
+...
+service imap-login {
+    inet_listener imap {
+        address = 127.1
+        port = 143
+    }
+    ...
+}
+...
+```
+
+## Configure nginx
+To make using the service easier, you can setup [nginx][nginx] to act as a
+reverse proxy. If you followed the [webserver tutorial][tutorial-webserver],
+you already have the basics for this set up. I do recommend you check this out,
+as I will only explain how to configure a virtual host to deal with the reverse
+proxy here.
+
+### Setup a reverse proxy
+Assuming you have taken the crash-course in setting up the nginx webserver, you
+can attain a reverse proxy using the following config block. Note that this block
+only does HTTPS, as I use HTTP only to redirect to HTTPS.
+
+```nginx
+# static HTTPS
+server {
+    # listeners
+    listen       443 ssl;
+    server_name  radicale.domain.tld;
+
+    # enable HSTS
+    add_header  Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
+
+    # keys
+    ssl_certificate      /usr/local/etc/letsencrypt/live/domain.tld/fullchain.pem;
+    ssl_certificate_key  /usr/local/etc/letsencrypt/live/domain.tld/privkey.pem;
+
+    # / handler
+    location / {
+        proxy_set_header Host $host;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_pass http://127.1:5232;
+    }
+}
+```
+
+## Enable the service at startup
+```
+echo 'radicale_enable="YES"' >> /etc/rc.conf.local
+```
+
+## Start the server
+```
+service radicale start
+```
+
+[nginx]: https://www.nginx.com/
+[tutorial-email]: /post/2016/10/31/freebsd-mailserver-part-1-preparations/
+[tutorial-webserver]: /post/2016/10/25/setup-nginx-with-lets-encrypt-ssl/
diff --git a/content/posts/2016/_index.md b/content/posts/2016/_index.md
new file mode 100644
index 0000000..74b1787
--- /dev/null
+++ b/content/posts/2016/_index.md
@@ -0,0 +1,3 @@
+---
+title: 2016
+---