Mail servers nowadays and vsmlist

Running an own mail server is a hard task

Back in the days I started playing around with mail servers, it was an easy and peaceful life. Either, you had a static IP address, or you used a relay host – and you were done and could send emails. This was also the time I started writing vsmlist, as I didn't want to mess around with Mailman to setup a mailing list for a handful of people.

Well, things have changed quite a bit since then. I learned that the hard way, because I set up my own "real" mail server some months ago. Mostly, because I didn't want some big company read my mails anymore, and also because I wanted to have Sieve. And that's something even the paid mail hosters don't provide – for whatever reason.

So here we go. Nowadays, you need a static IP address, a PTR record pointing to the mail domain you're sending from, the SPF policy set, DKIM signing and a DMARC policy. And despite everything being setup correctly, your IPs being not listed in any blacklist, even being listed in some whitelists, and not a single spam mail ever having been sent through your server, you're still blocked by some mail servers. Perhaps, because they never saw your server before, and thus simply claim you're a spammer. A spammer following all best practices in existance, but a spammer. Or for whatever reason. Who knows.

It has become a hard job to run an own mail server. But anyway, one should not leave the field to the monopolists and data krakens. But here, we are back at vsmlist.

vsmlist matures

The last release of vsmlist dates back to 2015. So it really needed some love concerning what a mail server needs or does nowadays. Some updates have been made, and this is what we have now:

SPF

SPF, the "Sender Policy Framework", is an email authentication method designed to detect forging sender addresses during the delivery of the email. SPF is not a problem with vsmlist. It now sets the Return-Path header to a bounce address (which is forwarded to the mailing list's admin). This makes SPF pass on a forwarded email, presumed the SPF record for the domain used for list is setup correctly.

DKIM

DKIM, "DomainKeys Identified Mail", is an email authentication method designed to detect forged sender addresses in email. DKIM is also not a problem. Classical mailing lists invalidated DKIM signatures by changing the subject (e. g. prepending "[Some List]" or such) and/or appending some information about the list (archives etc.) to the text. Vsmlist never did this. By leaving the original mail untouched, DKIM signatures stay intact. If the mail server running vsmlist does DKIM signing, another signature is added to the mail when distributing it. Both are valid.

DMARC

DMARC, "Domain-based Message Authentication, Reporting and Conformance", is an email authentication protocol to protect domains being used unauthorizedly (e. g. for spoofing). It's a disputed standard. It breaks RFC 5322 and causes a lot of problems with mailing lists.

DMARC checks if either SPF is okay, or DKIM, or both – and if all components use the same domain.

The problem is that a mail is typically sent to the mailing list, which then distributes it. So, according to the standard, the list becomes the Sender whereas the original sender stays the author, represented in From. This is an intended use-case for emails.

Example: An email from an @gmx.de account is sent through vsmlist. From is the @gmx.de address. Return-Path is set to the domain where vsmlist runs, e. g. an @some-domain.org address. The same address is used for the Sender address. SPF will pass, and also, GMX's DKIM signature will be evaluated to be correct. But still, DMARC will fail, because From differs from Return-Path. According to RFC 5322, DMARC should check the Sender header, not the From header. But it doesn't.

There's no solution to this. There are workarounds to migitate deliverability problems, but all with drawbacks (e. g. the original sender is lost, replying to the list creates a private answer and not a list answer and so on – all that sucks).

The workaround I chose for vsmlist is to wrap the original mail into a completely new one along with some notice if the DMARC policy of the original sender will cause troubles. This sucks as much as all the other workarounds, but at least, it leads to an "aligned" mail passing SPF, DKIM and also DMARC – and it preserves the original mail.

One should really think about boycotting stuff like DMARC, designed to break things and to cause trouble. But after all, most end-user have never even heard about that stuff. Anyway, vsmlist will be ready for an up-to-date use beginning with the next release :-)

gpx2svg 0.2.0 released

After quite some time, a few things changed, so let's do another release of of gpx2svg, the program to convert GPX to SVG. So what's new?

• gpx2svg now supports true-scale conversion using a WGS84 projection (see the --help output on how to use it). Big thanks to Hans Busch for contributing the respective code!
• The project is now licensed under the terms of the GPLv3 or later (and uses SPDX license identifiers).
• Let's use reasonable versioning from now on. Okay, we keep version 0 for now, but bugfix releases (x.y.*) are now easiliy distinguishable from releases adding new features (x.*.0).

Not much more to say, the code still does the one thing it was written to do ;-) Thanks again to Hans for supplying the initial patch! Have a lot of fun with gpx2svg!

Own homepage for KGeoTag

As of now, KGeoTag, the stand-alone, KDE-based photo geotagging program, has it's own homepage at https://kgeotag.kde.org/. Big thanks to the KDE project, esp. the Sysadmin Ben Cooksley, for setting this up and making it possible!

This is now the right place for information about the project and blog posts. Consequently, the two posts KGeoTag 1.0 coming soon and KGeoTag 1.0.0 out now I posted here have been moved over to their new home.

I really love to see the project evolving. May it last a long time :-)

Setting up WKD with lighttpd

Web Key Directory is an approach for simple distribution of public PGP keys. The idea is that a mail client checks for a needed key automatically and the user can simply encrypt a mail, without further interaction (no searching on a keyserver or manual downloading and importing into GnuPG).

The first site you find searching for it is GnuPG's WKD wiki page. But – just speaking of me – this page is quite confusing, and setting up WKD seems to be quite complicated. Happily, it isn't ;-)

A nice blog post describes what has to be done when you want to setup WKD. Just in case the linked blog post is removed: Providing PGP keys via WKD using the "direct" method (there's also an "advanced" method I didn't use) strips down to:

• Inside the web root of yout HTTP server, create .well-known/openpgpkey/hu/
• Touch .well-known/openpgpkey/policy
• Find out your key's WKD hash (the letter salad before the @): gpg --with-wkd-hash -k address@your-server.org
• Export the key without ASCII-armoring it to a file named like the hash: gpg --export address@your-server.org > a3tboyto3mewxb6wip98xkoepyqqxy94
• Put the file in .well-known/openpgpkey/hu/

Finally, you need to tell the HTTP server to deliver the correct MIME type for the key file(s). As usual, the article only contains configuration examples for Apache and nginx. As a lighttpd user, you're used to that ;-)

To make life a bit easier for the lighttpd users out there wanting to setup WKD, here's the snippet you need to make lighttpd deliver the correct MIME type and HTTP headers:

$HTTP["url"] =~ "^/.well-known/openpgpkey/hu/" {
    mimetype.assign = ( "" => "application/octet-stream" )
    setenv.add-response-header = ( "Access-Control-Allow-Origin" => "*" )
}

You can validate your setup to be correct using gpg-wks-client, which is shipped with GnuPG:

gpg-wks-client -v --check address@your-server.org

Now go and make the world a bit better by setting up WKD ;-)