Ein eigener Mailserver - wie geht das?

Hallo @ all

Als ich im Winter angefangen bin, mich mit der Frage aus dem Betreff für eine rein private Lösung zu befassen, musste ich sehr schnell die ernüchternde Erfahrung machen, dass ein Mailserver ein wirklich komplexes und kompliziertes Thema ist. Und darüber hinaus, dass es dafür im Internet kaum was gibt, was dem völlig unvorbereiteten Einsteiger dabei hilft, die Zusammenhänge erstmals grundsätzlich zu verstehen. Isolierte Detail-Infos gibt es en Masse… Zusammenhänge und Komplettlösungen, die zuvor auch erst mal das zu lösende Problem beschreiben, hingegen kaum. Was unterscheidet die Programmalternativen, Stärken, Schwächen, besonders geeignet für *, nicht geeignet für *, welche Programme sind von welchen anderen wie abhängig.... ?... Fragen über Fragen, aber kaum Antworten.

Das war für mich im Nachgang meiner Installation der Anlass, einmal mein Projekt und meine Lösung zu beschreiben, wie ich es gelöst habe, welche Gedanken und Überlegungen die Grundlage meiner Entscheidungen waren und zu welchen Lösungen sie geführt haben. Ob es immer die richtigen Rückschlüsse mit den richtigen Entscheidungen aus meinen Überlegungen heraus waren…?… keine Ahnung… ich hoffe es aber.

Egal, ich hab also zuerst mein Projekt „Mailserver“ fertiggestellt und nun einige Zeit später auch die Dokumentation dazu, die eben nicht nur eine reine Installationsanleitung sein will, sondern sich zu einem großen Teil auch mit dem „Was?“ und „Warum?“ und „Womit?“ befasst, und erst am Ende mit dem „Wie?“.

Wer Interesse hat und mal reinschauen möchte, kann sich meine Beschreibung als PDF hier downloaden:
Mailserver

Moin @all

Eigentlich ist es nicht mein Ding, so alte Kamellen noch mal auszukramen, aber der Umstand eines Designfehlers in der zweiten Version und die tatsächlich vorhandene und wirklich unnötige gravierende Kompliziertheit in einem Teilprozess haben zu einer umfassenden Überarbeitung meiner Installation und in den letzten Wochen zur Bearbeitung des Konzeptes geführt. Man lernt halt nie aus... und ein sehr inspirierendes Gespräch im Herbst hat letztendlich zum Re-Design geführt. Insofern betrachte ich das eher als Benachrichtigung für die, die es für eine eigene Implementierung verwendet haben, ganz oder in Teilen davon. GsD hatte ich das nur hier und im Debian-Forum gepostet....

Falls das also damals jemand als Hilfe zum Bau seines eigenen Mailserver verwendet hat, empfehle ich einen Abgleich mit der aktuellen Version. Das alte funktioniert zwar, das neue reduziert aber maßgeblich den zuvor übertriebenen Aufwand bei der Inbetriebname von Clients und Server sowie in den anschließenden regulären produktiven Prozessen. Die zuvor eigene spezielle TCP-Kommunikation zwischen Client und Server ist einschließlich der dafür notwendigen Software nicht mehr notwendig. Insbesondere die Clients sind damit erheblich einfach einzurichten... also dergestalt, das für die ungewöhnliche Grundidee jetzt nicht mehr zusätzlicher Aufwand erforderlich ist. Nun siehts so aus: Mail-Client installieren, verbinden und läuft... wie man es eigentlich erwartet. An die, die es betrifft: sorry für den Aufwand.

Mailserver

Danke für diesen Hinweis.... ... und ich muss gestehen, dass ich das jetzt überhaupt nicht mehr verstehe ich bin total überfordert. Denn diesen Hinweis hatte ich bereits irgendwann im Frühjahr diesen Jahres bekommen und ich bin absolut sicher, dass ich das schon einmal korrigiert habe. Mir ist unerklärlich, was zum verschwinden dieser Änderung geführt haben konnte und ob ggf. auch noch was anderes davon betroffen ist. Ich habs jetzt sofort erneut geändert.

Quote from RUDI-TERROR

Kannst du deine Anleitung noch dahingehend erweitern, dass der dovecot deamon alle x Minuten die POP3-Server abgrast?

Das musste ich mir gerade selber mal kurz anschauen und das kannst Du relativ einfach selber über ein kleines Script einrichten, welches Regelmäßig via root-Crontab gestartet wird.

Im Script werden die virtuellen Usernamen aufgerufen, also exakt die, die in der /etc/dovecot/alias_maps eingetragen sind. Aber Achtung: Ein echter Linux-User kann ja mehrere virtuelle User (resp. Postfächer) innehaben. Das bedeutet, es braucht NUR EINEN virtuellen User, um alle Postfächer des Linux-Users abzurufen. Der Aufruf für die beiden Linux-User Tom und Silvia dann so aus:

#!/bin/bash
export USER='tom';/usr/local/bin/getmail_eventhandler
export USER='sylvie';/usr/local/bin/getmail_eventhandler
exit 0

Wenn für Tom 5 Postfächer in der alias-maps eingetragen sind und für silvie 3, dann würden damit alle 8 Postfächer aktualisiert werden. Wenn man das ganz intelligent machen will, fragt man einfach in einem while-loop die Einträge der alias-maps ab und startet für jeden eingetraenen virtuellen User einmalig den Job. Man muss noch nicht mal zwingend darauf achten, wenn das für einen User mehrfach gestartet wird, getmail-eventhandler prüft das selber, ob für einen User schon ein Lauf gestartet ist und überspringt einfach alle weiteren.

Wenn ich ehrlich bin, ich habe nicht den leisesten Schimmer... ich vermute, das Problem hängt mit stdout zusammen....möglicherweise bist Du da über einen Bug gestolpert, der vielleicht mit dem durch Blank geteilten Linux-User-Namen entstanden ist. Wenn solche Namen als übergebene Parameter nicht mit "" maskiert werden, ist das Verhalten vorhersagbar fehlerhaft.

Ich versuche mal mit ein paar Tests dahinter zu kommen.....

Völlig falsche Rückschlüsse nachträglich gelöscht:

Oh... den ersten Fehler habe ich schon gesehen:

/etc/dovecot/alias_maps

Suitable Linux-User bedeutet, dass zum virtuellen Dovecot-User ein passender Linux-User zugewiesen wird. Laut /etc/passwd ist "Rudi Rodolfson" ein echter Linux-User. Insofern müssten den beiden virtuellen Dovecot-Usern "rudi" und "r.rudi" dieser Linus-User zugewiesen werden, so das das wie folgt aussieht.

Hier stellt sich jetzt nur die Frage, ob das seitens Dovecot überhaupt richtig verarbeitet wird oder ob das trennende Blank möglicherweise eine permanente Problemquelle darstellt.

Fortsetzung des Fehlers "falsche Rückschlüsse".

Quote from RUDI-TERROR

grep rudi /etc/passwd

rudi:x:1002:1002:Rudi Rodolfsen,,,:/home/rudi:/bin/bash

Das ist tatsächlich die Quelle des Problems.... und zwar explizit hier:

....was anstatt (was korrekt wäre) "Rudi Rodolfson" fälschlicherweise nur Feld 2 ("Rudi") zurückgibt.

An die Möglichkeit solcher Linux-User-Namen hab ich nicht gedacht.... das muss natürlich korrigiert werden.

Quote from RUDI-TERROR

grep rudi /etc/passwd

rudi:x:1002:1002:Rudi Rodolfsen,,,:/home/rudi:/bin/bash

Kannst Du mir kurz erklären, wie Du das geschafft hast, einen solchen Usernamen anzulegen?

# adduser "donald duck"
adduser: Um Probleme zu vermeiden, sollte der Benutzername nur aus Buchstaben,
Ziffern, Unterstrichen, Punkten, Klammeraffen (@) und Bindestrichen bestehen
und nicht mit einem Bindestrich anfangen (wie durch IEEE Std 1003.1-2001
festgelegt). Zur Kompatibilität mit Konten auf Samba-Rechnern wird
außerdem $ am Ende des Benutzernamens unterstützt

Ganz offensichtlich verstoßen solche Namen gegen gewisse Regeln hinsichtlich Namenskonventionen. Ich habe das jetzt bei mir in einer Testversion korrigiert, nur scheitert das jetzt an anderer Stelle (s.o.).... und nun stell ich mir die Frage, ob die Korrektur nicht selber ein Fehler ist..... ... oder sehen andere Distributionen das nicht so eng und ignorieren gewisse Regeln?

Hat da vielleicht noch jemand anderes eine Meinung zu solchen geteilten Linux-User-Namen?

Quote from llutz

Field 5: user name or comment field

Oh mann.... sowas bescheuertes.... ... einmal den Blick falsch fokussiert und dann stramm in die falsche Richtung marschiert... ... und dabei weiß ich das alles... so dämlich kann man sich manchmal selber blockieren ....

Quote from RUDI-TERROR

Ein Hinweis noch, statt apt install getmail habe ich apt install getmail14 installiert ("getmail" wurde nicht gefunden)

Das war eine Falle, in die ich dieser Tage getappt bin.... richtig ist "getmail", nicht "getmail4". In einer früheren Version hatte ich damals "getmail4" eingetragen, das ist aber bei Debian heute nur noch ein Übergangspaket, das richtige Paket ist "getmail". Das bedeutet, die Zurücknahme der Änderung auf getmail wieder auf getmail4 war ein Fehler, den ich jetzt wieder geradegerückt habe. Ich konnte mich daran erinnern, dass ich da schon mal was gemacht habe, hatte das aber im Dezember durcheinander gebracht. Wenn die von Dir verwendete Distribution nur das Übergangspaket "getmail4" anbietet, so ist das eine Entscheidung dieser Distri.... das ist aber nicht weiter tragisch... letztlich ist es die gleiche Version... aber korrekt ist "getmail".

Quote from RUDI-TERROR

Wenn ich dein Script manuel durchgehe, funktioniert der Grep-Befehl problemlos:

Ja, das habe ich mir schon gedacht. Aber egal, ich habe die User-Erkennung im Script trotzdem noch mal überarbeitet ...notwendigerweise... denn mit mehr Sorgfalt und kritischerer Betrachtung bei der Prüfung sind mir da jetzt Dinge aufgefallen, die man besser machen kann. Lade Dir die aktuelle Version noch mal mit dem Tarfile runter. Aber daran denken, vorher die alte sichern und die neue mit den korrekten Rechten versehen:

mv /usr/local/bin/getmail_eventhandler /usr/local/bin/getmail_eventhandler.sik

Starte dann mal 2 Terminalfenster mit einer horizontalen Trennung, jeweils über die ganze Breite. Im unteren Terminal startest Du zuerst

journalctl -f | grep eventhandler

... und anschließend im oberen Terminal (der User "rudi" ist ja sowohl virtueller Dovecot-User als auch Linux-User, sollte also klappen) die beiden Varianten:

export USER='ruuuhdi';/usr/local/bin/getmail_eventhandler

export USER='rudi';/usr/local/bin/getmail_eventhandler

Der erste Befehl sollte eine passende Fehlermeldung im unten laufenden Journal anzeigen, ohne das das Script darüber ins stolpern gerät. Der zweite Befehl müsste die Postfächer korrekt abarbeiten. Wenn der genannte Fehler (und auch keine anderen) nicht auftritt, ist also das Script ok.

Quote from RUDI-TERROR

findest du in deiner mail.err keine entsprechende Fehlermeldung?

Damit weiß ich jetzt gar nicht, welches Log das ist. Wo steht diese Meldung, in welchem Logfile, in welchem Verzeichnis?

Bitte berichte mal, wie sich das jetzt mit der Fehlernachricht entwickelt. Ich halte nämlich immer noch für möglich, dass das ein Socket-Problem ist.... ich warte aber erst auf Deine Meldung.