Froschs Blog

Computer und was das Leben sonst noch so zu bieten hat

Zur Website | Impressum

Mailrouting mit Knoten

1. Juli 2016 um 16:58 Uhr von Atari-Frosch

Seit heute früh schlagen bei mir Traffic-Warnungen von Hetzner für den alten Server auf. Der schleust derzeit ca. 3 GB pro Stunde durch (ab 1 GB/h lasse ich warnen). Schließlich fand ich heraus, daß die Tor-Bridge von mehreren Clients verwendet wurde bzw. wird; das könnten die dann wohl (gewesen) sein. Na gut, die dürfen das.

Bei der Suche ging ich natürlich alle Logs durch und stellte dabei eher so nebenbei fest, daß das Mailsystem meinte, keine Mails mehr an die Hauptdomain atari-frosch.de ausliefern zu können. Obwohl mail.atari-frosch.de seit 12. Mai auf dem neuen Server liegt und ich eigentlich der Meinung gewesen war, das dem alten Server kommuniziert zu haben, bestand er darauf, lokal auszuliefern. Oder besser, das zu versuchen: Es ging nicht, weil unter /var/mail angeblich Verzeichnis- und Dateirechte fehlen würden. Also bin ich dem mal nachgegangen.

Daß die alte Maschine überhaupt noch läuft, hängt natürlich damit zusammen, daß mir das ARGE seit nun zwei Jahren und neun Monaten den letzten Nerv raubt und ich deshalb zwar schon vieles, aber eben noch nicht alles auf den neuen Server habe umziehen können. Daß die alte Kiste dann auch noch unter Debian Squeeze rennt, das keine Updates mehr bekommt, macht's nicht besser; ihn noch auf was neueres hochzuziehen, ist aber auch nicht mehr sinnvoll.

Am 12. Mai hatte ich neben meinem Blog und der statischen Website unter atari-frosch.de auch direkt die Mailserver-Einträge entsprechend umgezogen, sodaß mail.atari-frosch.de auf den neuen Server zeigt und dort die darauf eingehenden Mails auch korrekt verarbeitet werden können. Ab dem Zeitpunkt wuchs /var/log/mail.err auf dem alten Server explosionsartig an; nur war mir das nie aufgefallen, weil das, was darüber sonst noch an Mail läuft, funktionierte und ich somit keinen Grund dafür hatte, in die Logs zu schauen. Heute waren wegen Logrotate (wöchentlich; vier Backups aufbewahren) noch die Daten ab Anfang Juni da.

Sagen wir's mal so: Eine mail.err von 10 MB pro Woche auf einer Maschine, die eigentlich nicht mehr viel macht, ist … doch etwas viel.

Zunächst einmal fand ich in diesen Dateien massenweise Meldungen wie diese hier:

Jun 26 00:00:42 seewind dovecot: deliver($user): mkdir(/var/mail/$user/cur) failed: Permission denied (euid=1xxx($user) egid=1xxx($user) missing +w perm: /var/mail)

($user ist ein Platzhalter für meinen lokalen Usernamen; 1xxx steht für die UID des Useraccounts).

Das war auch logisch: /var/mail/$user existierte nämlich gar nicht. Also wie kam er plötzlich auf diesen Postfach-Namen?

Als Workaround versuchte ich es erst einmal damit, daß ich meinen alten Postfach-Namen in $user umbenannte. Das erbrachte aber nur eine neue Fehlermeldung:

Jul 1 14:41:29 seewind dovecot: deliver($user): open(/var/mail/$user/dovecot.index.log) failed: Permission denied (euid=1xxx($user) egid=1xxx($user) missing +w perm: /var/mail/$user/dovecot.index.log)

Ja leck mich. Die Datei gehört vmail.vmail, und User und Gruppe haben Schreibrecht. dovecot wiederum gehört der Gruppe vmail an. Wieso hat er jetzt plötzlich die „Identität“ (m)eines lokalen Users?

seewind:~# chmod 666 /var/mail/$user/dovecot*

… half aber auch nicht weiter: dovecot behauptete im Log weiterhin, da nicht reinschreiben zu dürfen.

Nun war das sowieso ein bißchen doof, denn ich wollte die Mails ja eigentlich ganz gern im Mailsystem des neuen Servers haben und dort mit den anderen Mails zusammen abholen. Ich hätte sie jetzt noch auf eine Domain umbiegen können, die der alte Mailserver noch bedient, aber die will ich ja auch bald umziehen. Trotzdem hätte ich gern die Systemmeldungen gehabt, zumal da ein paar Scripte laufen, die regelmäßig über den Systemstatus informieren und Backups ausführen. Und ein paar Dienste, die nicht an eine bestimmte Domain gebunden sind, laufen da auch noch.

Also schaute ich mir die Datei /etc/postfix/virtual_domains mal genauer an. Die hat noch ein altes Format, das funktionierte, solange alles einheitlich auf dieser einen Kiste lief. Ob ich das nur mal falsch verstanden hatte oder ob das Format der Datei irgendwann verändert worden war, weiß ich heute nicht mehr. Die Datei ist bald zehn Jahre alt; ich habe in der Zeit immer nur neue Adressen hinzugefügt oder nicht mehr benötigte gelöscht, und sie – wie andere Konfigurationsdateien auch – über alle bisherigen Server hinweg quasi immer mitgeschleift. Auf dem neuen Server funktionierte das dann gar nicht mehr, und ich mußte sie komplett neu aufbauen.

Denn die alte hat das Format:

user@domain.tld postfach@mail.domain.tld

bzw. für die Hauptdomain nahm ich

user@atari-frosch.de postfach@mailintern.atari-frosch.de

– weil es sonst Kuddelmuddel mit dem offiziellen Mailserver-Namen im DNS gab, der ja auch mail.atari-frosch.de lautet.

Weiterleitungen zu externen Mailadressen funktionierten über dieselbe Datei mit

user@domain.tld user@externedomain.tld

Inzwischen sieht das Format aber so aus:

user@domain.tld /var/mail/domain/postfach/

– und Mailweiterleitungen darüber funktionieren vermutlich gar nicht mehr. Das Postfach wird also nicht mehr wie eine Mailadresse angegeben, sondern als Dateipfad.

Also trug ich nun einige Änderungen ein: Alle Adressen in der Domain atari-frosch.de bog ich um auf eine neu eingerichtete Mailadresse unter einer anderen Domain, die bereits komplett auf dem neuen Server läuft (ist schon praktisch, wenn man mehrere Domains hält). Dem postfix auf dem neuen Server wiederum erklärte ich, daß alles, was an diese Mailadresse reinkommt, in mein Postfach unter atari-frosch.de einsortiert werden sollte. Noch ein reload von postfix auf beiden Servern und dem dovecot auf dem alten, und …

… der alte wollte mit konsequenter Boshaftigkeit weiterhin lokal ausliefern. 🙁

Also mußte das WWW ran. Ich fand einen Forumseintrag, der mich drauf brachte, daß die Datei /etc/aliases in der Beziehung nicht ganz so unwichtig ist: Simple Weiterleitung mit postfix. Genauso wie der Fragesteller dort im Forum hatte ich diese Datei überhaupt nicht auf dem Schirm gehabt. Aber bei Mailumleitungen ist die offensichtlich relevant.

Also leitete ich in dieser Datei alle betroffenen Usernamen auf die neue Adresse unter der anderen Domain um. Dann:

seewind:~# postmap /etc/aliases

seewind:~# service postfix reload

seewind:~# postqueue -f

Das letzte Kommando startet die sofortige erneute Auslieferung aller zurückgehaltenen („deferred“) Mails, und endlich begann postfix, den ganzen liegengebliebenen Kram an den neuen Server auszuliefern. Bzw. die Mails der letzten fünf Tage, denn was fünf Tage lang nicht ausgeliefert werden konnte, wird ja gelöscht.

Puh.

Und irgendwann wird der Tag kommen, an dem ich Mailsysteme komplett verstanden habe. Immerhin dürfte ich dem heute wieder ein Stück näher gekommen sein 😉

3 Kommentare zu “Mailrouting mit Knoten”

  1. SackOhneSenf quakte:

    Zum Thema Merkwürdigkeiten: Ich hatte gerade ähnliche Probleme und Fehlermeldungen, die mir eine ganze Woche Sucherei mit Dovecot beschert haben.

    Das merkwürdige daran war, wenn ich /usr/sbin/dovecot von Hand gestartet habe, hat alles funktioniert, wie es sollte, doch sobald ich dovecot beim Systemstart (systemd) automatisch hochlaufen lies … Pustekuchen!

    … bis ich drauf gekommen bin, dass dovecot zwar keine Probleme hat auf die Postfach-Dateien zuzugreifen, aber dann beim Anlegen der Index-Dateien scheiterte, die man in der Konfiguration ja auf ein anderes Verzeichnis verschieben kann.

    Hat eine Weile gedauert, bis ich bemerkt habe, dass systemd beim start eines service an den mounts rumfummelt um das Programm besser zu isolieren. Auf dem von Hand angelegten tmpfs hatte das Verzeichnis für die Index-Dateien mode 1777 (root.root), auf dem von systemd angelegten tmpfs jedoch 0755 … und damit war dovecot nicht mehr in der Lage die Index-Dateien anzulegen.

    … nur so als Anmerkung, von wegen kleine Ursache, große Wirkung und dass es dabei meist notwendig ist mehr als einmal um die Ecke zu denken um das Problem zu finden.


  2. Atari-Frosch quakte:

    @SackOhneSenf: Du hast mir gerade einen weiteren guten Grund dafür genannt, warum ich nach einem Upgrade auf Debian Jessie als erstes systemd eliminiere. 🙂

    Oder anders: Bei mir kann systemd nicht dazwischengepfuscht haben, den gibt’s hier nicht.


  3. SackOhneSenf quakte:

    Zunächst mal wollte ich damit nur ein weiteres Beispiel geben, wie schnell man in eine lange Sucherei gezogen wird und dann die Ursache an ganz anderer Stelle liegt, als man sie zunächst erwartet.

    Zum Thema systemd, ich bin mit Sicherheit kein Freund davon, aber leider gibt es immer mehr gute Software, die nur noch mit systemd funktioniert oder irgend eine Kleinigkeit davon benötigt und daher systemd in den erforderlichen Abhängigkeiten landet … sick!

    … also habe ich mich mal auf das Abenteuer systemd eingelassen und nach einigem Suchen und ausprobieren festgestellt, dass die größten Probleme nicht von systemd selbst kommen, sondern von dem Chaos, das die Distributions Ersteller anrichten und bezüglich Startsystem bei der Einrichtung bzw. Paket-Installation auf dem Rechner hinterlassen.

    Ich habe daher mal zum Test versucht alles zu eliminieren, das nicht zum systemd Start-System gehört und siehe da, das ganze System funktioniert auf einmal sogar richtig gut. Die bislang erste Ausnahme war das dovecot Problem, allerdings ist es auch nicht gerade Standard-Installation von Dovecot die Index Dateien der Mailboxen jedesmal auf einem tmpfs neu anlegen zu lassen, wenn sich ein User beim IMAP Server anmeldet.

    Das soll nicht heißen, dass ich jetzt ein systemd Freund bin. Ich hoffe inständig, dass die Paket-Bauer endlich kapieren, dass man bei der Installation nicht einfach allen möglichen Müll auf der Platte abkippen kann und hoffen, das funktioniert dann bei allen reibungslos. Etwas mehr Auswahl bei der Installation, was man nutzen möchte und etwas mehr Rücksicht darauf bei nachfolgenden Installationen, so dass nur das vom Admin gewünschte installiert wird. Also nicht einfach Scripte und Dateien für alle möglichen Start Systeme, Konstellationen und/oder Sprachen abladen, sondern gezielt das für ein System benötigte installieren.

    Der größte Unbill kommt mehr davon, dass ein Einsteiger bei all dem Chaos kaum noch was versteht und dann leicht in eine Falle tappt und sich ein Fehler einschleicht.

    … so, jetzt hab ich einfach mal meinen Frust hier abgekippt!


Kommentieren

Bitte beachte die Kommentarregeln!

XHTML: Du kannst diese Tags verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>