Skip to content

Personalisierte Mailadressen

Schon seit vielen Jahren verwende ich eine Subdomain zur Vergabe von personalisierten E-Mail-Adressen, die ich dann für Zwecke verwenden kann, bei denen ich meine normale E-Mail-Adresse nicht preisgeben möchte, bspw. das Abonnieren von Newslettern, an deren Seriösität ich Zweifel habe, für Webshops etc. pp. Das hat den Vorteil, daß sich über diese personalisierten E-Mail-Adressen nachvollziehen läßt, aus welcher Quelle bspw. Spammer ihre Adressen bezogen haben, und, viel wichtiger, daß sich diese Adressen rückstandslos entsorgen lassen, wenn sie missbraucht werden. Insgesamt eine gute Idee; die Frage ist immer nur, wie man sich diese Adressen erzeugt.

Meine erste Lösung war ein Catch-All, was aber den Zweck der Übung letztlich konterkarierte, weil man auf diese Weise eine unbegrenzte Anzahl valider E-Mail-Adressen erzeugt und Spam potentiell potenziert. Zwar kann man bestimmte Adressen selektiv deaktivieren, bspw. über eine Aliases-Datei, in der sie explizit geerdet werden und ein Catch-All als Fallback für nicht explizit definierte Adressen verwendet wird, aber Spammer permutieren Adressen gerne; wenn man abashop@domain.example deaktiviert, bekommt man stattdessen vielleicht Mail an abasho@domain.example und an abash@domain.example und an … So hat sich das nicht bewährt.

Also habe ich die Adressen stattdessen in einer Aliases-Datei explizit definiert (und für eine Übergangszeit doch einen Catch-All als Fallback verwendet, für den Fall, daß ich eine bereits verwendete Adresse vergessen hatte …). Das tat etliche Jahre seinen Zweck, hatte aber den Nachteil, daß ich mich für Änderungen immer erst auf dem entsprechenden Host einloggen und die Datei ändern mußte. Unbequem und, wenn man gerade unterwegs ist und nur Webzugriff hat, erst gar nicht möglich. Also habe ich reichlich oft doch meine Hauptadresse für diverse Anmeldungen verwendet; diesen Nachteil gab es bei der Verwendung des Catch-All nicht.

Die Lösung wäre - so war mir ebenfalls seit langer Zeit klar - die Verwendung eines bequemen, nach Möglichkeit webbasierten Interfaces zur Anlage neuer solcher Adressen, damit der innere Schweinehund nicht mehr dazwischenkommen kann. Und diese Lösung habe ich jetzt endlich umgesetzt. Zumindest provisorisch, aber das wird vermutlich wieder so ein langlebiges Provisorium werden … ;-)

Der richtige Weg ist eigentlich ganz einfach: eine Weboberfläche, mit der man Mailadressen anlegen, ändern und löschen kann, dazu eine Datenbank, in der sie gespeichert werden, und eine Änderung in der Exim-Konfiguration, damit der Mailserver auf diese Datenbank zugreift. Bereits Ende 2007/Anfang 2008 habe ich das für das "Szafshosting" gelöst; auf diese Lösung konnte ich jetzt für mich aufsetzen. Allerdings habe ich mich - aus mir mittlerweile selbst unklaren Gründen - entschlossen, als Datenbank diesmal nicht mySQL, sondern SQLite zu verwenden, was zu weniger amüsanten Abstechern zu den verschiedenen SQLite-Versionen führte: mit der einen kann Exim nicht umgehen (dort wird SQLite 3.x benötigt), die andere wird von PHP nicht nativ unterstützt (da geht es nämlich um SQLite 2.x). *tiefseufz* Die Lösung war dann, den Zugriff in PHP noch einmal neu mittels PHP Data Objects (PDO) zu implementieren; auf diese Weise wird nämlich auch SQLite 3.x unterstützt.

Die Datenbank für die Mailadressen sieht recht einfach aus:

CREATE TABLE addresses (keyid INTEGER PRIMARY KEY ASC, domain TEXT, mail TEXT, comment TEXT);

Dort werden dann Mailadressen - auch unter verschiedenen Domains - abgelegt. Exim wird dann mitgeteilt, in welchen Domains Adressen via SQLite vergeben werden, und für diese Adressen ein entsprechender Router angelegt:

sqlite_aliases:
  driver = redirect
  domains = /etc/exim/domains-sqlite
  require_files = /etc/exim/sqlite-address.db
  data = ${lookup sqlite {/etc/exim/sqlite-address.db \
         select target from addresses where mail='${quote_sqlite:$local_part}' \<BR>         and domain='${quote_sqlite:$domain}';}}
  user = exim
  check_ancestor
  file_transport = address_file
  pipe_transport = address_pipe

Wenn man einmal dabei ist, kann man in ähnlicher Weise auch "virtuelle Mailboxen" als Maildir im Home des jeweiligen Users unterstützen. Die zugehörige SQLite-Datenbank sieht so aus:

CREATE TABLE mailuser (keyid INTEGER PRIMARY KEY ASC, username TEXT, password TEXT, uid TEXT);

Der zuständige Router in Exim für diese "virtuellen Mailboxen", implementiert als lokal zustellbare Adresse, sieht folgendermaßen aus:

 sqlite_user:
   driver = accept
   domains = +hostname
   local_parts = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
          select username from mailuser where username='${quote_sqlite:$local_part}' }}
   address_data = ${lookup sqlite {/etc/exim/sqlite-mailboxes.db \
          select uid from mailuser where username='${quote_sqlite:$local_part}' }}
   transport = sqlite_delivery
   cannot_route_message = Unknown user

Und so sieht der zugehörige Transport aus:

sqlite_delivery:
  driver = appendfile
  maildir_format = true
  directory = /home/$address_data/mailstore/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  user = $address_data
  group = users
  mode = 0660

Abfragen muß man die Mailboxen natürlich auch; als POP3-/IMAP-Server verwende ich Dovecot. Dort wird folgendes in der Konfiguration ergänzt:

 passdb sql {
   # Path for SQL configuration file, see /etc/dovecot/dovecot-sql.conf for example
   args = /etc/dovecot/sqlite.conf
 }

Und die Datei /etc/dovecot/sqlite.conf sieht so aus (ohne Zeilenumbrüche):

driver = sqlite
connect = /etc/exim/sqlite-mailboxes.db
default_pass_scheme = PLAIN
password_query = SELECT username as user, password, '/home/' || uid || '/mailstore/' || username AS userdb_home,<BR>    'maildir:/home/' || uid || '/mailstore/' || username AS userdb_mail, uid AS userdb_uid, 100 AS userdb_gid<BR>   FROM mailuser WHERE username = '%u'

Und siehe da: es tut. :-)

Trackbacks

Aus dem Leben eines Szlauszafs am : Umabonnieren von Mailinglisten

Vorschau anzeigen
Nachdem ich im letzten Monat meine Verwaltung personalisierter E-Mail-Adressen auf eine bequeme Weboberfläche umgestellt hatte, habe ich dieses Konzept nun auch auf meine abonnierten Mailinglisten erweitert. Bislang habe ich alle Mailinglisten mit dersel

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Arno Welzel am :

Arno Welzel

Es wäre sinnvoll Die PRE-Abschnitte mit passenden overflow-Styles zu versehen (overflow:auto oder overflow-x:auto;overflow-yhidden;), damit der Artikeltext nicht durch die PRE-Abschnitte durch überlange Zeilen nahezu unlesbar wird.

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Favatar, Pavatar, Twitter, Identica, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck