Last week, I blogged about my efforts to fight mailman subscription spam. Enabling
SUBSCRIBE_FORM_SECRET as described there indeed helped to drastically reduce
the amount of subscription spam from more than 1000 to less than 10 mails sent
per day, but some attackers still got through. My guess is that those machines
were just so slow that they managed to wait the required five seconds before
submitting the form.
So, clearly I had to level up my game. I decided to pull through on my plan to write a simple CAPTCHA for mailman (that doesn’t expose your users to Google). This post describes how to configure and install that CAPTCHA.
I recently noticed that both of the Mailman setups that I am running are being abused for subscription spam: Bots would automatically attempt to subscribe foreign email addresses to public mailing lists, resulting in a subscription notification being sent to that address. I am still extremely saddened by the fact that this is a thing—whoever sends this spam has no direct benefit and no way of selling anything (they don’t control the content of the message); the only effect is to annoy the owner of that email address, the victim. That seems to be enough for some. :(
Oh, and my servers’ reputation goes down because people mark these emails as spam. So, more than enough reasons to try and stop this.
I finally have a setup that I am happy with for syncing contacts between my phone and my laptop. Most would probably consider that a solved problem, but I have an extra requirement that rules out most existing solutions:
The data of my contacts must not be exposed in clear text to any machine I do not physically control.
I’m not happy about my own personal data being shared with third parties, and consequently, I will not share the personal data others entrust to me with third parties. This obviously rules out all of these “free” cloud services out there that Apple, Google and others offer—services that are paid with data, and in the case of contact sync frequently paid with the data of others. (This leaves me wonder whether under the GDPR, it is even legal for someone else to consent to my contact data being shared with a cloud provider. I certainly never consented and still my data sits in multiple synced address books. But that’s a discussion for another day.) Moreover, this also rules out putting them e.g. into an ownCloud or Nextcloud hosted on ralfj.de, because that is a VPS that I do not have any physical control over.
I think all HTTP communication on the internet should be encrypted – and thanks to Let’s Encrypt, we are now much closer to this goal than we were two years ago. However, when I set up Let’s Encrypt on my server (which is more than a year ago by now), I was not very happy with the official client: The client manages multiple certificates with different sets of domains per certificate, but I found it entirely unclear which commands would replace existing certificates or create a new one. Moreover, I have some special needs: I’ve set up DNSSEC with TLSA records containing hashes of my certificates, so replacing a certificate has to also update DNS and deal with the fact that DNS entries get cached. Lucky enough, Let’s Encrypt is based on open standards, so I was not forced to use their client!
To make a long story short, I decided to write my own Let’s Encrypt client, which I describe in this post.