Archiv

Archiv für den Monat September 2013

Faced with a growing number of mailboxes to fetch messages from, I devised a little script to help me easily manage lots of accounts with getmail. It was inspired by this post from Charles Cazabon, the developer of getmail.

The advantage of this solution is that you need to create, name and manage getmail’s rcfiles for different mailboxes in one place only, without modfying other scripts, crontabs or whatever.

First off, this is the folder structure I created. It may remind you of the old /etc/rc.d/ folder structures that were common for system start scripts before we had upstart and all this modern whoop-de-do:

.getmailsets
├── set-all
│   ├── rc.blog
│   ├── rc.freemail
│   ├── rc.provider
│   ├── rc.uni
│   └── rc.work
├── set-often
│   ├── rc.provider -> ../set-all/rc.provider
│   ├── rc.uni -> ../set-all/rc.uni
│   └── rc.work -> ../set-all/rc.work
├── set-rare
│   ├── rc.freemail -> ../set-all/rc.freemail
│   └── rc.blog -> ../set-all/rc.blog
└── set-important
    ├── rc.uni -> ../set-all/rc.uni
    └── rc.work -> ../set-all/rc.work

.getmail/ -> .getmailsets/set-all/

All the getmail-typical rcfiles live in the .getmailsets/set-all/ folder. Others sets are defined by folders with a corresponding name and contain links to the actual rcfiles in the „all“ set.

And this is the script that puts it to use. I call it checkmail:

#!/bin/bash

RCARGS=""
RCPATH=/home/myself/.getmailsets/set-$1
shift  # deletes argument $1 and shifts the others forward

cd $RCPATH
for F in rc.*; do
  RCARGS="$RCARGS --rcfile $F"  # prepares the --rcfile args for getmail
done

exec getmail $@ --getmaildir $RCPATH $RCARGS  # $@ contains all (remaining)
                                              # arguments to the script.

You use checkmail by calling it with the set name as the first argument, and any arguments you want to pass on to getmail, like in these examples:

$ checkmail all -q
$ checkmail important -v
$ checkmail rare -q -d

And these calls, of course, are what you want to place in your scripts, shortcuts and whatnot. You can then manage the set contents or rename the rcfiles in your .getmailsets without changing any of the scripts. How about, for example, a button on your desktop that runs:

$ ssh mailserver "checkmail important -v"

The script is also ideal, of course, for your crontabs. Here’s an example of my configuration:

*/5  0-3,9-23  * * * checkmail often -q
  0      8-23  * * * checkmail rare -q

As a bonus, I symlinked $HOME/.getmail/ to my .getmailsets/set-all/. This allows me to call getmail for one single mailbox without additional arguments, like in a basic setup:

$ getmail -r rc.work
$ getmail -vr rc.uni

Known problem and solution: There is a problem with this setup when it comes to old mail in your mailboxes. If you always delete all mail on the remote servers, as set by delete = True in your rcfile, this will not affect you and you don’t need to read on. If you don’t, here is the thing:

As you may have noticed, getmail creates files with names like oldmail-[server]-[port]-[username] in the same folder as the rcfiles. They contain a list of mails on the server that getmail has already downloaded. Now, because we have symlinks to the same rcfiles in different folders, there will be different oldmail files in the different folders, which will contradict each other and will lead to mails being downloaded multiple times in certain situations.

To prevent this from happening, always run checkmail all after adding a new rcfile and hardlink (symlinks don’t appear to do the trick) the new oldmail file to all set-folders you also linked the rcfile in. This way, getmail will always use the same oldmail file, no matter what set the rcfile is called from.

Nach einem Bericht des Hamburger Abendblatts soll es in der Hamburger Innenstadt bald „Internet für alle und überall“ geben. Zahlreiche Medien kopieren die Geschichte unkritisch, die SPD feiert die Ankündigung kräftig ab, und sich selbst gleich mit.

Warum das Angebot aus Kundensicht alles andere als frei und universell verfügbar ist, wird bei der Elbmelancholie ausführlich beschrieben: Es geht um Telekom-Hotspots, die nur eine Stunde kostenlos genutzt werden können, und dann nur mit Zwangsregistrierung, und (dank Störerhaftung) Pauschalüberwachung der Nutzer.

Um sich in diesem zweifelhaften Glanz doch noch irgendwie zu sonnen, jubelt der SPD-Netzpolitiker Hansjörg Schmidt auf seiner Homepage, dass man „einen sehr großen Erfolg vermelden“ könne. Vorgezeigt wird statt echter Veränderungen (die nur auf Bundesebene möglich sind) immer wieder eine Bundesratsinitiative der Hamburger SPD.

Diese Initiative der SPD wurde bereits direkt nach ihrer Vorstellung vor etwas über einem Jahr von Fachleuten kritisiert, unter anderem von der Piratenpartei Hamburg und der und der Digitalen Gesellschaft. Sie stellten klar, dass die SPD-Initiative nur kommerziellen Anbietern hilft und ihnen Zensur- und Erfassungstechnik vorschreibt, um sich von der Haftung bei Urheberrechtsverstößen freizukaufen. Privatleute mit offenen WLANs und Initiativen wie Freifunk, die bewusst auf das Identifizieren ihrer Nutzer und das Sperren von Inhalten verzichten, sollen weiterhin schutzlos der Abmahnmafia ausgesetzt bleiben. Inzwischen ist die Initiative gescheitert.

Fassen wir zusammen:

  • Die SPD bringt eine erfolglose Bundesratsinitiative ein, die kommerzielle Anbieter mit Erfassungs- und Filtertechnik von der Haftung befreit, Privatnutzern und Freifunk-Initiativen aber kein Stück weiterhilft.
  • Die Drosselkom kündigt an, kostenpflichtige Hotspots mit Zwangsregistrierung in Hamburg zu installieren.
  • SPD-Netzpolitiker sprechen von einem „sehr großen Erfolg“. Hä?

In seinem Blog weist Hansjörg Schmidt übrigens als Verteidigung gegen die o.g. Kritik darauf hin, dass der Freifunk Hamburg zu einer Expertenanhörung in der Bürgerschaft eingeladen war. War er auch: von der Linksfraktion. (Nachtrag: Das ist nicht richtig – Hansjörg Schmidt hat als Ausschussvorsitzender die Sachverständigen eingeladen.)