Vollaufen von E-Mail-Postfächern mit Skript verhindern

Hallo,

durch die Maillisten wie teachers@ kommt es leider immer wieder zu Problemen mit vollaufenden E-Mail-Postfächern.

Das Problem:
Da es sich um Maillisten (und nicht um Mailinglisten) handelt, versucht postfix die E-Mail an eine Mailliste so lange immer wieder ALLEN zuzustellen, bis sie JEDER bekommen hat.
Hat nun ein User ein volles Postfach, weshalb die E-Mail nicht allen zugestellt werden kann, erhält jedes Mitglied der Mailliste die E-Mail wieder und wieder, bis irgendwann immer mehr Postfächer vollaufen - ein Schneeballeffekt.

Da KuK oft nicht rechtzeitig auf die automatischen E-Mails von root kurz bevor das Postfach voll ist reagieren, checke ich die Belegung der Postfächer per cronjob mit

sophomorix-mail --showmailboxes | LC_NUMERIC=C sort -t "|" -k 5,5gbr

Damit bekomme ich Zeilen dieser Form

| --- | user.username | 3 | 144.248 MB | 150 MB|

Wenn ein User auf meinen Hinweis ebenfalls nicht zeitnah genug reagiert und sein Postfach volläuft, dann unterbinde ich derzeit händisch weitere Zustellversuche in sein Postfach durch einen Eintrag in die /etc/aliases

username: "|echo 5.2.1 Das Postfach des Benutzers ist voll. Bitte wenden Sie sich mit Ihrer Nachricht unter Angabe der Person, die Sie erreichen wollen, an das Sekretariat.; exit 77"

Ist wieder genug Speicherplatz im Postfach, entferne ich den Eintrag wieder.

Im Prinzip läuft das ja bei jedem Mailprovider so ähnlich: Ist das Postfach eines Users voll, lehnt der Mailserver eingehende E-Mails mit einer Nachricht an den Absender ab.

Unterschied: Dort passiert der Mechanismus aus Ablehnung wenn Postfach voll und Annahme wenn wieder Platz ist automatisiert.

Daher die Frage: Wie kann ich das ebenfalls automatisieren?

Im Prinzip muss ein Skript laufen, das

  1. den Füllstand der Postfächer ausliest
  2. ab einem vorgegebenen Füllstand (% oder MB) automatisch den entsprechenden Eintrag in die /etc/aliases erzeugt
  3. newaliases aufruft
  4. Beim Sinken des Füllstandes unter den vorgegebenen Wert den Eintrag aus /etc/aliases entfernt
  5. wieder newaliases aufruft

Ich kann leider ein solches Skript nicht schreiben, wäre aber dankbar für eine entsprechende Lösung, um das leidige Problem ein für alle mal zu “erschlagen”. Wer kann mir dabei helfen?

Viele Grüße
Steffen

Hallo,

ach so, oder die Alternative - ist vielleicht sogar viiiel einfacher: Der Server unternimmt nicht erst x weitere Zustellversuche, sondern lehnt E-Mails, die er nicht zustellen kann, sofort ab.

Das würde ja meines Wissens eh irgendwann passieren. Korrigiert mich, wenn ich mich irre, aber üblicherweise ist das doch so:

  1. Mail kann nicht zugestellt werden --> bleibt in der queue
  2. erneuter Zustellversuch nach kurzer Zeit --> kann nicht zugestellt werden --> bleibt in der queue
  3. erneuter Zustellversuch nach länger werdender Zeit --> kann nicht zugestellt werden --> bleibt in der queue
  4. […]
  5. E-Mail geht zurück an den Absender (Mail Delivery System Meldung)

Es lässt sich doch sicher konfigurieren, dass nach 1. gleich 5. kommt, oder zumindest nich dutzende bis hunderte Zustellversuche erfolgen, ehe die Mail zurück geht.

Viele Grüße
Steffen

und nochmal,

manchmal hat man den kompliziertesten Weg im Kopf (weil man von der Seite her „kommt“). Aber ich denke nach etwas „Suchmaschinen befragen“ das Ändern der Parameter von Postfix ist in der Tat der bessere und bei weitem einfachere Ansatz.

Am Einfachsten wäre wohl das hier:

maximal_queue_lifetime (default: 5 days)
How long a message stays in the queue before it is sent back as undeliverable. Specify 0 for mail that should be returned immediately after the first unsuccessful delivery attempt.

Die Frage ist nun nur noch, ob das negative Auswirkungen hat, die ich noch nicht sehe?

Das Setting des E-Mail-Empfangs unseres Server ist:

  • Domains sind bei Belwü gehostet
  • Der Belwü-Mailserver pusht die E-Mails per smtp auf unseren Server
  • Unser Mailserver verteilt an die User

Ist unser Server von Belwü aus nicht erreichbar, dann werden die Mails ja dort nach obiger Einstellung für maximal_queue_lifetime (bei Belwü) zwischengespeichert, ehe sie als unzutsellbar an den Absender zurück gehen.

Ist unser Server ereichbar, werden die Mails ja - nehme ich an - sobald sie da sind beim ersten Versuch an die Postfächer erfolgreich verteilt (sofern das Postfach nicht voll ist).

Also sollte es doch kein Problem sein, die Ablehnung gleich beim ersten erfolglosen Zustellversuch zu konfigurieren?!?

Oder kann der Mailserver trotz genügend Speicherplatz in einem Postfach auch mal mehr als einen Zustellungsversuch benötigen?!?

Noch besser wäre natürlich, wenn man die exakte Zahl der Zustellversuche einstellen könnte (und nicht wie mit dem Parameter oben die Zeitspanne). Also z.B: 3 Zustellversuche, dann geht die E-Mail zurück.

Was meint ihr?

Viele Grüße
Steffen

und noch eine Überlegung / Frage:

Ausgangspunkt sind ja Mails an Maillisten. Wenn nun eine Mail an eine Mailliste eingeht und diese kann einem User der Liste nicht zugestellt werden, dann würd sie mit maximal_queue_lifetime = 0 ja sofort abgelehnt werden.

Jetzt ist halt die Frage: bekommen alle anderen die Mail trotzdem, oder bekommt sie dann keiner (oder nur der Teil der User, in deren Postfach zugestellt wurde, ehe der User an die Reihe kommt, bei dem es nicht klappt?!?

Viele Grüße
Steffen

Hallo,

also ein Test mit extrem restiktiver Einstellung hat erfolgreich funktioniert.

Ich habe oben in die /etc/postfix/main.cf folgendes eingetragen:

maximal_queue_lifetime = 10m
maximal_backoff_time = 4m
minimal_backoff_time = 2m
queue_run_delay = 1m

Nach Restart von postfix und E-Mail an einen Verteiler, bei dem ein Empfänger ein volles Postfach hat, wurde den anderen die E-Mail genau 5 mal zugestellt, danach bekam ich als Absender die Nachricht, dass User x ein volles Postfach hat.

Jetzt stellt sich nur noch die Frage nach sinnvollen Werten.

Möglichkeit 1: Alles auf sehr lange Zeiträume dehnen, z.B.

maximal_queue_lifetime = 2d
maximal_backoff_time = 12h
minimal_backoff_time = 6h
queue_run_delay = 4h

Also erneuter Zustellversuch nur alle 6 Stunden und max 2 Tage lang.

Möglichkeit 2: Alles auf eher sehr kurze Zeiträume einstellen, z.B.

maximal_queue_lifetime = 80m
maximal_backoff_time = 20m
minimal_backoff_time = 10m
queue_run_delay = 5m

Also erneuter Zustellversuch alle 10 min und max 80 min lang.

Ergebnis von 1:
Der User hat länger Zeit sein Postfach zu leeren und die E-Mail wird doch noch zugestellt.
Dafür dauert die E-Mail-Zustellung bis zu 6 Stunden, was natürlich auch doof ist.

Ergebnis von 2:
Der User hat praktisch keine Zeit sein Postfach zu leeren und die E-Mail geht in den meisten Fällen an den Absender zurück.
Dafür kommt die Rückmeldung an den Absender viel schneller, dass seine E-Mail gar nicht zugestellt wurde. Der Absender erfährt das also nicht erst nach Tagen und wundert sich, waum der Empfänger nicht auf sein Anliegen reagiert.

Das könnte natürlich zur Folge haben, dass sich Leute öfters ans Sekretariat und letztlich an mich wenden, was da los sei.

Hm… schwierig, wie man das einstellen soll…

Wie würdet ihr es als goldenen Mittelweg machen?

Viele Grüße
Steffen

Lieber Steffen,

habe fasziniert Deine “Selbst-Reflektionen” durchgelesen und vermute, dass Dein workaround funktionieren könnte.
Dennoch stellt sich mir die Frage, ob Du zum Schutz vor eMail-Loops nicht Dein eMail-Verteilersystem umstrukturieren möchtest. Du könntest mit postfix relativ komfortabel eine “echte” Maillingliste erstellen und Deine Probleme damit individuell lösbar machen. Oder Du setzt auf moodle als “Abbild” der Schulkommonikation und -Gremien - da scheint hier in NRW gerade sehr gepusht zu werden - und hast dann gleich ein Verteilersystem, das man einem weiteren “Moodle-Kollegen/ einer Moodle-Kollegin” in die Hand drücken kann, damit Du nicht alles selbst machen musst.
Oder Du setzt gleich auf eine Groupware (Zarafa, …)
Was meinst DU ?

Grüße aus dem nebligen NRW,
Christoph Gü

Hallo Christoph,

ja, manchmal hilft mir allein schon das „laut“ denken hier :smiley:

Nun, die Maillisten erstellen sich mit LMN ja von selbst (Bestandteil von Sophomorix).

Der große Vorteil dabei ist halt, dass LMN (Sophomorix) die Mitglieder für mich (oder wen auch immer) automatisch pflegt. Wenn ich nun eine Mailingliste für das Kolllegium einrichte, müsste ich die Mitglieder selbst pflegen.

Das Problem mit der wiederkehrenden Zustellung haben wir nur gelegentlch, wobei ich mich immer wieder frage, warum manche KuK ihr Postfach immer bis fast unter der Decke voll haben, während es der Rest hinkriegt, dass da nur wenig drin ist und nein, das liegt nicht an Weiterleitungen, sondern daran, wiie man damit umgeht.

Nun, auch das habe ich schon zu forcieren versucht, schließlich ist bei uns Moodle sogar zeitgleich Schulhomepage und wird von mir selbst zur Bereitstellung und Verteilung von Infos genutzt. Die Möglichkeit wäre also eigentlich da.

Aber: Es ist halt bisher niemand mit aufgesprungen. Das Problem dabei:
a) Es geht viel schneller eine E-Mail in seinen TB, Outlook oder was auch immer zu tippen, als eine Mitteilung über Moodle zu machen (Anmeldung entfällt)
b) Wenn die KuK nicht zur Nutzung eines Systems verpflichtet sind, machen viele davon es ganz einfach nicht.

Ich habe hier neben Moodle auch eine Owncloud laufen als Tauschplattform oder auch, um seine eigenen Materialien daheim und in der Schuie auch ohne Stick & Co immer aktuell parat zu haben.

Außer mir nutzt diese Möglichkeit aber fast keiner. Irgendwie sind viele
a) entweder zu zu analog unterwegs, um die Vorteile für sich zu sehen, oder
b) zu bequem, eine ggf. schon vorhandene Arbeitsweise zu überdeken, geschweige denn zu ändern.

Habe ich auch schon drüber nachgedacht, aber aus den o.g. Gründen verworfen.

Ich denke, so traurig das ist, dass es Zeit wird, dass die landesweite Schulcloud (wie auch immer die dann aussehen wird) in BW endlich eingeführt wird und dann per VwV die KuK einfach gezwungen werden, ihre Arbeitsweise zu ändern.

Viele Grüße
Steffen