Mails werden mehrfach zugestellt

[Rüdiger Kupper]

Irgend etwas veranlasst den Mailserver, alle Mails mit einer Verzögerung von einigen Tagen erneut zuzustellen. Ursache?

[bau]

Leider ist es so, dass einer unserer Kollegen derzeit sein Mailpostfach überlaufen lässt. Der Mailserver hat dann die unangenehme Angewohnheit eMails bis zu fünfmal zuzustellen, wenn auch nur ein Mitglied eines Verteilers nicht zugestellt werden kann.

[Rüdiger Kupper]

Obwohl der betreffende Kollege sein Postfach nicht in Ordnung hält, ist es dennoch kein adäquates Verhalten des Servers, die Mail an alle Empfänger (bzw. an eine Liste als einzelnen Empfänger) erneut zuzustellen, weil einer der Empfänger die Mail nicht angenommen hat.

Der Server kann an der zurückkommenden Mail erkennen, dass der Empfänger, der die Mail nicht angenommen hat nicht identisch ist mit dem angegebenen Empfänger (Liste). Er sollte die Mail nur an diesen einzelnen Empfänger erneut zustellen.

Ich kann mir kaum vorstellen, dass für dieses Problem keine Lösung verfügbar ist. EMail gibt es seit 1971, und das überflüssige Duplizieren von Mail gilt nach aller Netiquette als schlechtes Benehmen. Wieso tut unser Mailserver das?

[bau]

Ich habe keine Ahnung.
Ich benutze den Server nur in der Version, wie ich ihn von der paedML geliefert bekomme und trage Verteiler in die /etc/aliases ein. Nach einem newaliases tut das Ganze dann. Vielleicht ist das bei Postfix ja auch ganz anders vorgesehen und ich mache das prinzipiell falsch? Ich hatte nur bislang keinerlei Zeit mich darum zu kümmern zumal das Problem lange Zeit (wegen der recht großen Quota) gar nicht erst auftrat. Dann musste man erstmal rausfinden, woran das überhaupt lag, jetzt wissen wir immerhin warum der Swerver sowas macht. Vielleicht bekommen wir es jaauch abgestellt.

[bau]

Erest Abhilfe ist seit dieser Woche, dass die Postfächer täglich per /etc/cron-daily/kepler--mailquota geprüft und ggf. gesichert/geleert werden. Allerdings bewahrt uns das nicht davor, dass Mailpostfächer während des Tages überlaufen und auch nicht davor, dass Mailverteiler von Leuten benutzt werden könne, die das nicht dürfen. In der Literatur wird bei kleinen Verteilern immer auf /etc/aliases bzw. /etc/postfix/virtual hingewiesen. Wir machen das derzeit über die aliases-Tabelle, was das Problem verursacht (auf dem neuen Server sind die Wiederholungsintervalle kürzer, das bedeutet, dass man eine Mail ständig neu zugestellt bekommt).
Professionellere System von z.B. Unis benutzen für die Mailverteilerlisten eine Mailinglistensoftware - meistens mailman. In diese Richtung werde ich weiterforschen, denn damit ist es auch möglich, anzugeben, wer an die entsprechende Liste schreiben darf und wer nicht.

[Rüdiger Kupper]

• Verhält sich /etc/postfix/virtual vielleicht anders als /etc/aliases?
• Mailman ist sehr verbreitet, ich stand da schon auf verschiedenen Mailinglisten, die das verwenden

[bau]

virtual verhält sich nicht anders, es ist nur an einer anderen Stelle des Mailtransports eingeklinkt.
Für mich spricht alles für mailman.

[bau]

Ich habe mir ein Buch zu mailman gekauft - bereits im Vorwort wird klar: Das ist genau, was wir suchen!
Damit ist auch kleinschrittig skalierbar, wer auf welchen Verteiler überhaupt zugreifen darf. Mails an Verteiler von Absendern, die da nichts zu schreiben haben, werden entweder dem Moderator zur Freigabe zugestellt oder einfach ersatzlos gelöscht. Ich muss nun nur noch die Erzeugung der Listen umprogrammieren. Dabei wird gleich auch noch die Struktur der Datenbankprogramme auf db.kg-fds.de modernisiert (cron-Jobs und maintenance-Scripts, Pfade anpassen)

[jas]

nimmt in lezter Zeit wieder arg zu...

[bau]

Das kommt halt immer drauf an, wieviele SuS grade ihre Quota überschritten haben. Unser Server löscht die überfälligen Mails zwar nächtlich, aber manchmal geht das Löschen in letzter Zeit doch schief und es dauert etwas, bis das Potsfach wieder befüllbar ist.

[bau]

mündlich haben wir schon besprochen:
Wenn eine Mail an dich und einen Verteiler geht, in dem du bist, dann bekommst du die Mail zweimal. Das lässt sich offensichtlich nicht verhindern.

Bei den Quota-Überschreitungen der SuS habe ich bereit zwei Ideen, die ich nur noch umsetzen musss:

• Umstellen der Mailverteiler auf MailMan Das behebt das Problem, dass Mails mehrfach an den ganzen Verteiler gehen, auch wenn nur eine einzige Adresse im Verteiler nicht erreichbar ist (over quota)
• umschreiben des Scripts mailquota.sh, so dass dieses mehrmals nacheinander die Quota der User checkt, solange bis diese im grünen Bereich sind. Löschen/Sichern der Mails zunächst bis auf die letzten 10 Tage, 9 Tage, ...

[Rüdiger Kupper]

Das Problem tritt auch bei den Verteilern für die SMV (Arbeitskreise) auf und produziert viel Mailmüll. Kann hier Abhilfe geschaffen werden?

(severity-->kritisch, weil es mehrere Kollegen sowie Schüler bei der täglichen Arbeit belastet.)

[bau]

Schenk mir einen 48-Stunden-Tag :-)

[Rüdiger Kupper]

Das Problem ist gerade sehr skut -- das hängt vielleicht mit der Bildermassenmail vom Freitag zusammen.
Egal, an welchen Mailverteiler ich schreibe, ich bekomme die Mail doppelt und dreifach (manchmal dreißigfach!!) zugestellt.

Allein in den Verteilern der SMV finden sich heute fünfzehn(!) Adressaten, die ein überfülltes Postfach haben.

Es ist klar, dass du nicht die Ressourcen hast, um auf die Schnelle nach Mailman umzustellen, doch vielleicht lässt sich ein Weg finden, wenigstens die überfüllten Postfächer zu beheben?
Z.B.:

• Mailquota für die Schüler vorübergehend erhöhen
• Zwangsleeren der überfüllten Fächer

Mir scheint, das Problem erfordert augenblickliche Intervention, sonst ziehen wir uns den Groll von Kollegen und Schülern über zigfach zugestellte Mails zu...

(priority escalation -> "höchste")

[bau]

Habe die mailq gerade nochmals gelöscht.
Wird aber nicht lange halten, denn es gibt momentan einfach zu viele SuS mit überlaufendem Postfach :-(

[Rüdiger Kupper]

Problem ist weiter akut: 123 Schüler mit überlaufenden Postfächern. Wir müssen uns etwas einfallen lassen. Nicht nur, dass die Mailverteiler massiv Mails duplizieren (und damit zum Problem beitragen), die betreffenden Schüler erhalten auch keine Mail. Wir können ihnen also nicht einmal bescheidsagen, außer, wir sprechen jeden persönlich an.

Habe erneut zurückgehaltene Mails aus der Mail-Queue gelöscht, nochmal zu Erinnerung:

# postsuper -d ALL deferred

[Rüdiger Kupper]

Lösungsvorschlag

Den Postfix Mail Server so konfigurieren, dass er nicht zustellbaer Mails nicht erneut zustellt, sondern bereits beim ersten fehlgeschlagenen Zustellungsversuch an den Absender zurückschickt. Das ist zwar kein übliches Verhalten für Mailserver, doch unter unseren Bedingungen vielleicht akzeptabel. Pragmatik: Das Bedürfnis von vielen (nicht von duplizierten Mails genervt werden) wiegt schwerer als das Bedürfnis des Einzelnen (Mail verlässlich zugestellt bekommen).* Auf diese Weise ist zwar der Zustellungsprozess unverlässlich, doch Mails werden nicht dupliziert, sondern gehen sofort zurück an den Absender. Der Absender ist in unserem Kontext hoffentlich eine intelligente menschliche Person, die selbst beurteilt, ob die Mail erneut zugestellt werden soll, und an welchen Empfänger.

• Anbei: Woher stammt das Literaturzitat? Die erste richtige Antwort erhält eine kleine Belohnung ;-).

[bau]

So, ich habe jetzt mal radikal das Script /usr/local/sbin/maildel.sh aufgerufen (läuft jede Nacht und löscht normalerweise bei den Übeltätern alle Mails, die älter sind als 10 Tage) mit -d1 (alles was älter als heute ist) aufgerufen - jetzt ist mal wieder etwas mehr Ruhe zu erwarten.

Regelmäßiger Aufruf von postsuper -d ALL deferred wäre natürlich auch entspannend.

[Rüdiger Kupper]

@bau

Du hast Mailman installiert, sehr gut!

Offenbar hast Du die Mailinglisten der Linuxmusterlösung aus der Schulkonsole übernommen. Ist dieser Prozess autmatisiert? (D.h., werden auch zukünftig Mailinglisten, die über die Schulkonsole eingerichtet werden, direkt als Mailman-Liste umgesetzt?

Es gibt noch ein paar Unstimmigkeiten:

• Bei Listen mit mehreren Administratoren (das sind die meisten), sind die Einträge der Administratoren nicht richtig voneinander getrennt. (Z.B. Liste "p_ak_dayevent": Administratoren: "kup@…@kg-fds.destre@…". Das wird so nicht funktionieren, die Einträge sollten mit Newlines getrennt sein.)
• Die Administratoren haben Zugang zum normalen Admin-Webinterface für Mailman-Listen (z.B. "​http://paedml.kg-fds.de/cgi-bin/mailman/admin/p_ak_dayevent"). Die Verwaltung (z.B. Der Mitglieder) sollte aber nicht von dort aus geschehen, sondern nur über die Schulkonsole. Sonst, so sage ich voraus, wird Chaos ausbrechen :-).

Kannst Du kurz erklären, wie genau Mailman an die Linuxmusterlösung/Schulkonsole angekoppelt ist, und wie weit diese Koppling trägt?

Gute Arbeit :-)!

[bau]

Offenbar hast Du die Mailinglisten der Linuxmusterlösung aus der Schulkonsole übernommen. Ist dieser Prozess autmatisiert? (D.h., werden auch zukünftig Mailinglisten, die über die Schulkonsole eingerichtet werden, direkt als Mailman-Liste umgesetzt?

klar - alles Andere würde keinen Sinn machen!

Es gibt noch ein paar Unstimmigkeiten:

• Bei Listen mit mehreren Administratoren (das sind die meisten), sind die Einträge der Administratoren nicht richtig voneinander getrennt. (Z.B. Liste "p_ak_dayevent": Administratoren: "kup@…@kg-fds.destre@…". Das wird so nicht funktionieren, die Einträge sollten mit Newlines getrennt sein.)

Mist Tippfehler - Mailman möchte bei den Admins und Moderatoren ein JSON-Array der Form
['Text1','Text2'] - bei mir fehlt das Komma :-(

• Die Administratoren haben Zugang zum normalen Admin-Webinterface für Mailman-Listen (z.B. "​http://paedml.kg-fds.de/cgi-bin/mailman/admin/p_ak_dayevent"). Die Verwaltung (z.B. Der Mitglieder) sollte aber nicht von dort aus geschehen, sondern nur über die Schulkonsole. Sonst, so sage ich voraus, wird Chaos ausbrechen :-).

Nein, denn die Admins sollen ruhig administrieren, wie sie wollen - stimmen die Listen nicht mehr, so bügelt das Script täglich wieder drüber :-(
Alles Andere dürfen die Admins aber gerne verändern - wenn sie sich verkonfiguriert haben, dann werde ich ihnen im Kepler-Login unter Mailaliase eine Möglichkeit einrichten nach dem Motto - Hilfe ich habe mich verkonfiguriert - zucüksetzen auf Factory-Default ;-)

Kannst Du kurz erklären, wie genau Mailman an die Linuxmusterlösung/Schulkonsole angekoppelt ist, und wie weit diese Koppling trägt?

Ich werde das Ganze noch im TRAC dokumentieren, die Scripte sind aber auch schon mit einer Direkthilfe ausgestattet.

[Rüdiger Kupper]

Replying to bau:

werden auch zukünftig Mailinglisten, die über die Schulkonsole eingerichtet werden, direkt als Mailman-Liste umgesetzt?

klar - alles Andere würde keinen Sinn machen!

Geschieht das unmittelbar, oder erst in der darauffolgenden Nacht?

die Admins sollen ruhig administrieren, wie sie wollen - stimmen die Listen nicht mehr, so bügelt das Script täglich wieder drüber :-(
Alles Andere dürfen die Admins aber gerne verändern - wenn sie sich verkonfiguriert haben, dann werde ich ihnen im Kepler-Login unter Mailaliase eine Möglichkeit einrichten nach dem Motto - Hilfe ich habe mich verkonfiguriert - zucüksetzen auf Factory-Default ;-)

D.h., Dein Skript überschreibt jede Nacht die Mitgliederliste mit den in der Schulkonsole eingetragenen Namen, ändert aber sonst keine Konfiguration. Das sollten die Listenbesitzer dann noch irgendwie erfahren und auf die Schulkonsole verwiesen werden. Die Schulkonsole ist übrigens auch nicht jedem Nutzer bekannt.

Ich frage mich, ob es überhaupt sinnvoll ist, für unseren Anwendungsfall die Lehrer als Listenbesitzer zu haben.

Alternativvorschlag

Die Lehrer werden Listen-Moderatoren, aber keine Listen-Besitzer. Moderatoren können "von außen eingegangenen" Mails moderieren (also solche, die nicht von Listenmitgliedern stammen), können aber sonst nichts konfigurieren. Als Listen-Besitzer wird dann root oder mailman-owner eingetragen (also wir).

Allerdings haben die Listen-Besitzer noch eine andere interessante Eigenschaft: Sie werden über nicht zustellbare Mails informiert und darüber, wenn Listenmitglieder deshalb deaktiviert wurden (s.u.)

Zum Thema Moderation von Fremdmails

Das wird sehr schnell ein Thema werden, weil viele unserer Nutzer von ihren privaten Mailaccounts aus an unsere Mailinglisten schreiben. Wir sollten überlegen, das einfach zuzulassen, so wie auch bisher. (Also Moderation abstellen.)

Zum Thema Bouncing

Das ist ja der Grund, dass wir Mailman installiert haben, weil es die "Bounces" (nicht zustellbare Mails) analysiert und "intelligent" reagiert.

Ich habe mir gerade die Konfiguration dazu durchgelesen, die ist derzeit folgendermaßen: Kommt eine Mail als unzustellbar von einem Empfänger zurück, so "merkt" sich Mailman das und zählt mit. Passiert das an mehr als fünf Tagen nacheinaneder, wird die Listenmitgliedschaft des Empfängers deaktiviert. (Überschreibt Dein Skript das nachts wieder?) Der Nutzer erhält dann jede Woche eine Nachricht "Your Membership is Disabled". Nach drei Wochen wird er dauerhaft von der Liste entfernt. (Überschreibt das Dein Skript wieder?)

Das sind alles sehr sinnvolle Einstellungen für öffentliche Mailinglisten. Aber auch für unseren Usecase? Wer ist an einer Schule eigentich verantwortlich, wenn z.B. ein Schüler eine Information des Klassenlehrers nicht erhält, weil er sich nciht um sein Postfach kümmert? Das haben wir Administratoren ja bisher mehr oder weniger auf unsere Kappe genommen. (Oder besser: es ist an uns hängengeblieben.) Sind die Lehrer Listenbesitzer, bekommen sie zukünftig die nervenden Bounce-Nachrichten und müssen den Schülern hinterherlaufen. Damit würden wir eine Aufgabe, die uns einfach überlastet, sinnvoll auf andere Köpfe verteilen. Wie diese Köpfe darauf reagieren werden, ist eine andere Frage (überlasse ich Deiner Imagination ;-) ).

Am ehesten wäre uns geholfen, wenn wir die Schüler verpflichten, ihre Postfächer ordentlich zu nutzen. (Wie andere Infrastruktur der Schule auch, Räume dürfen sie ja auch nicht einfach zumüllen.) Und damit wären wir wieder beim Ausgangsproblem, nämlich, wie wir das den Schülern klarmachen. Die täglichen Aufforderungen per Mail funktionieren ja nur selten...

[bau]

Das Script läuft nächtlich auf dem DB und synct die wichtigsten Einstellungen - alles Andere kann der Kollege einstellen, wie er es möchte. Macht er was falsch, gibt es im Kepler-Login den Zurück-Button. In Zukunft haben die Kollegen mehrere Möglichkeiten, an Mailverteiler zu kommen:

• Standard ist die Schulkonsole, Projekt erstellen, Mailverteiler wird nächtlich automatisch erstellt oder gesynct
• im Kepler-Login kann man Mailverteiler in Zukunft als Kollege von Hand einrichten, diese werden in der Datenbank abgelegt und nächtlich mit mailman gesynct
• eine Gruppe in InfoSys anlegen lassen, diese pflegen - diese wird nächtlich mit mailman gesynct

[Rüdiger Kupper]

Ticket kann nach drei Jahren endlich geschlossen werden. Die neuen Mailman-Listen funktionieren, auch wenn es noch an vereinzelten Kleinigkeiten klemmt. (Siehe ticket:1845, ticket:1857.)

Gute Arbeit! :-)