It happened: Now that I am an uploading DD for a few months I finally made my first upload of a package – mind you, not of apt, but of a package I declared my intend to "steal" from another person a few weeks ago on deity@ and later also in a bugreport (#835128).

The result is that apt-transport-tor which used to be maintained by Tim Retout as a modified copy of apt code is now maintained by the APT team (with him and me as uploaders) using the apt code directly via a few symlinks.

That brings along a bunch of changes which I mentioned in the list/bug as well, but for completeness:

• tor+https options consistently fall back to tor -> https -> http
• tor+http options consistently fall back to tor -> http
• socks5h isn't forced. It is just the default (and the only one which will work with (tor+)http at the moment; any with tor+https)
• a tor-proxy having apt-transport-tor as username & no password (default) will automatically pick a password based on the target host to get you in a new circuit for each host.
• the User-Agent isn't forced to an all-tor-users-have-the-same value. Especially with tor+http being our normal http I think its better to "hide" between other http users than saying straight that you are a tor user (even if the IP gives it away that you are).
• tor+https doesn't allow redirection to tor+http. We have this for a while for https -> http already (-tor "broke" it). I think if a user went as far as configuring a https source it should stay an https source or fail.
• http/https can be disabled to avoid accidentally adding such sources
• http will not try to connect to .onion domains (RFC7687) and the error hints at using tor+http
• the methods run as _apt instead of root (like the rest of the apt methods)

I had tried a few times to get people to provide feedback, but there wasn't much. I guess this is good as it means nobody has any complains about it. We will see if that will change now that it is on its way to archive, buildds, mirrors and users: Brace for impact in any case!

I sign all my mails with GPG for a few years now. Beside the huge hypothetical boner and the moral highground this provides it is also nice to get some minor benefits like a ham bonus on Debian mailinglists (even if we all know how that is implemented).

It is hard to belief sometimes, but I don't sent mails to Debian only through. Sometimes I get questions what that strange attachment is nobody can open. Its okay through, I don't blame them.

What I can't tolerate through is mails from me ending up in Spam because I don't sent mails from one of the big (free) mail providers (and to a bunch of people all at once). There are a bunch of options available to make my mails look a bit more legit even for those mailservers which don't understand gpg in the form of SPF, DKIM and DMARC. The bonus they provide isn't huge (if not non-existent) and there are problems and shortcoming involved I don't have to deal with with gpg signing but the things you do to avoid having to hear a "lets all just use a facebook/whatsapp/whatever group for communication"…

[note that I have added most of this to kalnischkies.de, but the setup was initially setup for and tested on an other domain – I will just say example.org here to not have you confused by blogpost vs. reality]

SPF

Easy to do if you have just one place you sent mails from – which in my case is true as I sent mails by letting msmtp connect to the SMTP of my hoster, which for rough emergencies also has a webfrontend so all I had to do is add a TXT record in DNS: "v=spf1 mx -all".

And as I have subdomains (for mailinglists mainly) which sent mails, too, add for all these subdomains "v=spf1 mx:example.org -all" as well. Additionally, if you have subdomains which do not sent mails, you can say that they all should fail spf unconditionally: "v=spf1 -all" (You can set this also for subdomains you don't have, but spammers use anyhow).

DKIM

Is a bit harder. My hosts SMTP doesn't support it (they are equally dubious of its usefulness as I am), but don't fear: I can add a DKIM signature locally before passing it on the hosts SMTP! Arch user 2ion has documented his setup and mine is rather similar, just that I installed python3-dkim, took dkimsign.py from git (changing interpreter to python3) and adapted my already existent sendmail wrapper [= a forgot to attach attachement detection script] to use that python script.

Of course, I had to generate some private keys for this exercise. I used "opendkim-genkey -b 2048 -d example.org -s mail" for that (the default keylength is 1024 – the spec seems to suggest that implementations are required to support up to 2048, so if I have to do it, lets do it big). The "-s mail" part is freely choosable by the way for keyrollovers and stuff. Beside the private key that command also generates a textfile which contains what has to be added as another TXT record in DNS.

DMARC

That's easy again: Yet another TXT record in DNS: "v=DMARC1; p=none". I think I will eventually use more stricter settings and might even explore the report facilities but for now that seems to work okayish.

Testing

Sending mails to a Google Mail account (as they make use of those features and add results to mail headers) can tell you if its working. Mail-Tester is also a nice service to test your setup (even through it targets mostly at newsletter creators) which tests various details, presents it friendly and even gives some tips (if it works that is, sometimes it seems to have problems).

Summary

A bit of busy work and I see how that could be oh so much more complex if I would have a different setup, but in the one I have it seems to have a very slight net-benefit, even if I would like to not need it in the first place…

On the upside, it gives me another bunch of ham bonuspoints on Debian mailinglists, which means I can probably spam quite a bit now… 😉

I just hope I also get enough bonus points on setups I was setting this up for…