Ik kreeg een mail zoals deze Afpersingsmail: Bedreiging voor uw veiligheid! ***@*********.nl is gecompromitteerd. - Fraudehelpdesk.

De tekst leest kwa stijl of de auteur niet echt Nederlands kent en deels hulp heeft gehad van een automatische vertaling of van meerdere mensen die stukjes vertaald hebben.

Het volgen van het bitcoin adres in het mailtje (deels gemaskeerd bij fraudehelpdesk) levert een interresant beeld op: dit levert blijkbaar wel wat op. Als ik de bitcoin rekening opzoek op Bitcoin Address 1PRUG1TrBWKLpvMJYfYXhZVSDagSySqXuz zie ik diverse bijschrijvingen in de afgelopen twee dagen en een afschrijving. De eerste drie bijschrijvingen lijken erg op betalingen in de buurt van de genoemde 35 euro. Maar als ik diep in de transacties duik zonder enige voorkennis van bitcoin zie ik allemaal verwarrende dingen.

Opvallend is wel dat dezelfde wallet dus op meer plekken genoemd is. Daarmee is het traceren van degene die betaald heeft onmogelijk, waardoor het verhaal in de afpersingsmail ook compleet ongeldig is.

Or in short: Perl considered harmful

I want applications to use and prefer IPv6 whenever possible, so I have a /etc/resolv.conf with IPv6 addresses of the nameserver(s) listed first. But I noticed queries from the spamassassin processes still coming in over the legacy IP protocol. Even when listing them in order in /etc/spamassassin/local.cf spamassassin prefers IPv4. And I want it to prefer IPv6 without leaving out IPv4. I like the redundancy but I want to change the preference. Also: I only want to maintain the list of nameservers in /etc/resolv.conf and not in other locations.

I wrote a simple test program to understand what the perl Net::DNS::Resolver is doing. With a standard test program like:

#!/usr/bin/perl -wT

use strict;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();

print join ' ', $resolver->nameservers();

print "\n";

The IPv4 addresses will be listed first, independent of the order in /etc/resolv.conf. Only after changing to:

#!/usr/bin/perl -wT

use strict;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();
$resolver->prefer_v6(1);

print join ' ', $resolver->nameservers();

print "\n";

I will see the IPv6 resolver listed first. But now to convince spamassassin to do the same. Browsing the Net::DNS::Resolver shows the RES_OPTIONS="inet6" option but does not document it. This option confuses spamassassin when starting:

export RES_OPTIONS="inet6"

root@gosper:/etc/default# service spamassassin restart
Restarting SpamAssassin Mail Filter Daemon: Bad arg length for NetAddr::IP::Util::mask4to6, length is 128, should be 32 at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP/Lite.pm line 647.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8.
BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.24/NetAddr/IP.pm line 8.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Util.pm line 70.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin/Conf.pm line 85.
Compilation failed in require at /usr/share/perl5/Mail/SpamAssassin.pm line 71.
BEGIN failed--compilation aborted at /usr/share/perl5/Mail/SpamAssassin.pm line 71.
Compilation failed in require at /usr/sbin/spamd line 240.
BEGIN failed--compilation aborted at /usr/sbin/spamd line 240.

So that was a bad idea and is not the answer. Looking at the resolv.conf manpage shows that the option indeed does different things which explains why that was wrong.

  inet6  Sets RES_USE_INET6 in _res.options.  This has the
		 effect of trying an AAAA query before an A query inside
		 the gethostbyname(3) function, and of mapping IPv4
		 responses in IPv6 "tunneled form" if no AAAA records
		 are found but an A record set exists.  Since glibc
		 2.25, this option is deprecated; applications should
		 use getaddrinfo(3), rather than gethostbyname(3).

So if I want perl programs to do what I want, I have to change every one of them to set $resolver->prefer_v6(1);. There is no sane default or a global "get into the 21st century" flag.

Changing /usr/share/perl5/Mail/SpamAssassin/DnsResolver.pm to include $res->prefer_v6(1); does help, but will need to be redone when updating spamassassin.

On 25 december 2004 there was a special deal giving me the .info names camp-wireless.info and campwireless.info for free for the first year. Since that moment I kept the names registered and redirected all web traffic to the right version: https://www.camp-wireless.org/. So the deal worked from a 'selling domain names' perspective: Christmas is a bad moment to review the need for domain names, so the easy solution is to renew it. My decision to stop with these names was made in January 2018.

Traffic to the .info versions is very minimal. With the cost of the domain registration I decided to stop doing that and devised an exit strategy which would result in a domain name that attracts no traffic and is not linked to my other webprojects. On the next renewal date the domain will expire. I have done this before in a different context: when we ended the students personal webspace at www.students.cs.uu.nl.

The solution is to start returing HTTP state 410 Gone for search engines while at the same time returning a somewhat user-friendly error page.

Relevant bit of apache 2.4 configuration:

<VirtualHost *:80>
    ServerName www.camp-wireless.info
    ServerAlias www.campwireless.info
    ServerAlias camp-wireless.info
    ServerAlias campwireless.info

	DocumentRoot /home/httpd/campwireless-expire/html

    <Directory "/home/httpd/campwireless-expire/html">
        Require all granted
    </Directory>

    RewriteEngine On
    RedirectMatch 410 ^/(?!gone.html|robots.txt)
    ErrorDocument 410 /gone.html
</VirtualHost>

The gone page is simple: It has an explanation for human visitors and a meta refresh tag to redirect the browser eventually. But to a search engine the status 410 on almost any url will give a clear flag the page is gone and should be flushed from the cache.

Today I had a day off to arrange some stuff and found some time for amateur radio. I decided to put the longwire antenna outside and use the tuner to get on different bands than the standard 10/20/40.

So I was active at a strange time (during a working day) on a band I haven't been active on in months. Soon I saw signals from C5YK who is in The Gambia. After several tries I made the contact and had a new country in the log.

I also tried a lot of times to contact a station from Rodrigues Island but they never heard me.

The old rsi problem was acting up again, just like I had RSI in 1999.

One of the things I now did was add a left-side mouse on the linux desktop at home. I have used a left-side mouse for a number of years on a linux desktop and used the instructions from the xmodmap manpage:

       Many  pointers are designed such that the first button is pressed using
       the index finger of the right hand.  People who  are  left-handed  fre‐
       quently  find  that  it is more comfortable to reverse the button codes
       that get generated so that the primary  button  is  pressed  using  the
       index  finger  of  the  left  hand.   This  could be done on a 3 button
       pointer as follows:
       %  xmodmap -e "pointer = 3 2 1"

But I now have two USB mice, one with a forward/backward button and a clearly right-handed design and one simple one on the left. And it is possible to selectively swap mouse buttons on only one input device with xinput.

The list of all inputs:

koos@thompson:~$ xinput list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech USB-PS/2 Optical Mouse           id=9    [slave  pointer  (2)]
⎜   ↳ Logitech Optical USB Mouse                id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Power Button                              id=7    [slave  keyboard (3)]
    ↳ Burr-Brown from TI               USB Audio CODEC  id=8    [slave  keyboard (3)]
    ↳ VIA Technologies Inc. USB Audio Device    id=11   [slave  keyboard (3)]
    ↳ daskeyboard                               id=12   [slave  keyboard (3)]
    ↳ daskeyboard                               id=13   [slave  keyboard (3)]
    ↳ Dell WMI hotkeys                          id=14   [slave  keyboard (3)]

Setting the button order happens with xinput set-button-map which needs an ID. Solution in .xsession:

xinput set-button-map $(xinput list --id-only "Logitech Optical USB Mouse") 3 2 1

Oh, and in that other operating system I use (Windows) one of the problems is the user can't set mouse button order per device. And technical specifications of left-handed mice do not list whether the buttons are swapped in hardware.

This weekend I had some time and energy to power up the amateur radio set and trying to get interesting contacts. All in FT8 digital mode as the local interference levels are high. I do my voice contacts at the radio club or out in the field.

This Saturday I managed to make a contact with 5T2AI on Mauritania, a new country in amateur radio for me. At first the other station did not receive me but using the power amplifier helped to make the contact.

I also did a lot of attempts to get a contact with the current radio expedition to Rodriguez Islands but failed.

I noticed certain commands taking a while to start, including a simple ls. At last I got annoyed enough to diagnose the whole situation and found out the problem is the combination of symbolic links in the listed directory pointing to filesystems behind automounter, one mounted filesystem coming from a NAS with sleeping disk and ls --color doing a stat() on the target of a symbolic link to find the type of the target file to be able to select a colour.

My solution: find the source of the alias and disable it.

Remember the twitter #! hashbang urls? I'd rather not. Those URLs were active from 2010 to 2012 and have been eliminated. But I got reminded today as it seems they are now silently failing. I checked the archive of my own website to fix all those links.

I try to keep all old URLs working. Unless the content completely goes away.

I bought the iRiver ifp-795 in May 2005 to listen to podcasts, mostly while cycling to and from work.

But I need to find time to download new episodes on the laptop and copy them in the right order to the storage of the mp3 player. There is an another device which can do all this and can play the mp3 files too: my android smartphone.

So I looked for an Android podcast player which can deal with podcast feeds not in its own directory. After reading an overview article and browsing the play store I found RadioPublic and managed to add my favourite podcasts.

Adding a feed it didn't know was a bit harder than expected. I want to listen to The ICQ Amateur / Ham Radio Podcast but it wasn't listed. So I tried to add the RSS feed myself by typing the URL which failed. Adding it only worked out after I opened the RSS feed in my browser on android and copied and pasted the url to the 'search' field.

The application has a nice playlist and I can order the downloaded episodes in such a way that I don't get several episodes from the same show in a row.

Ok, I found one downside: it seems impossible to add an mp3 downloaded via the browser to the RadioPublic playlist.