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}' \
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,'maildir:/home/' || uid || '/mailstore/' || username AS userdb_mail, uid AS userdb_uid, 100 AS userdb_gid FROM mailuser WHERE username = '%u'
Und siehe da: es tut. 
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Arno Welzel am :
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.