Reseller-Paket, Mails verschwinden nach Überschreitung Mailbox Quota

  • In meinem Reseller Paket 4000 hatte das Postfach eines Abos das Quota-Limit erreicht (2GB). Die Folge war, dass Mails natürlich nicht mehr zugestellt wurden - allerdings haben die Absender auch keine Benachrichtigung erhalten und Mails wurden auch nicht gebounced/rejected.


    Konkret war das nun über 3 Tage bei einem Postfach. Nachdem der Kunde mir davon berichtete dass keine Mails mehr ankommen, habe ich einige Testmails das Postfach geschrieben (Quota-Limit war mir nicht sofort aufgefallen). Später dann nach Erhöhung des Quotas auf 5GB (3 Tage später!) kamen meine eigenen Testmails jedoch auch nicht mehr zurück (wieso auch plötzlich).


    Das ist natürlich eine ziemlich schwerwiegende Sache, da die Mails de facto weg sind.

    Im Service-Paket gewählt war die Option "Überbeanspruchung von Speicherplatz und Traffic ist zulässig. Erlauben Sie die Überbeanspruchung von Speicherplatz und Traffic. Lassen Sie die Überbeanspruchung anderer Ressourcen nicht zu." - "andere Resourcen" ist natürlich Mails, ist klar.


    Insofern ist die Nicht-Annahme neuer Mails natürlich völlig korrekt!

    Aber dass dem Absender keine Info/Bounce zugestellt wird, kann nur ein Fehler im MTA sein. Liest der Support hier mit? Ich frage erstmal hier ... Danke!

  • Der Support liest hier mit, primär ist das aber ein Kundenforum. Ich würde vorschlagen, dass du dich direkt an den Support wendest, vermutlich wirst du dann schneller eine Antwort erhalten. Du kannst in deiner Anfrage auf diesen Forenthread verweisen.


    Halte uns gerne auf dem Laufenden - sollte das Problem wirklich so bestehen, halte ich das für relativ schwerwiegend.

  • also jetzt war ich etwas irritiert. Habe nochmal beim Sender-MTA das Logging mitgelesen und der Netcup-MTA refused tatsächlich die Mails mit Hinweis "Mailbox full". Soweit so gut! Allerdings erfolgte trotzdem keine Benachrichtigung (keine Ahnung warum mir das bei den anderen Tests nicht aufgefallen ist)


    Hier das Postfix-Log des sendenden Servers mit einer Mail an das Postfach im Netcup Reseller-Paket:


    Sep 21 15:27:28 s13 postfix/smtp[6882]: 273F77D85C6A: to=<quotatest@meinedomain.de>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.34, delays=0.13/0/0/0.21, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 5D6247D85C6B)


    Sep 21 15:27:28 s13 postfix/smtp[7914]: 5D6247D85C6B: to=<quotatest@meinedomain.de>, relay=webmail.meinedomain.de[185.243.11.XX]:25, delay=0.38, delays=0.06/0.01/0.1/0.21, dsn=4.2.2, status=deferred (host webmail.meinedomain.de[185.243.11.XX] said: 452 4.2.2 Mailbox full (in reply to end of DATA command))


    Ich war mir nun gerade unsicher, ob der Sender-MTA (dieses Log) oder der Empfänger-MTA (Netcup) die Refuse-Mail an den Mail-Absender schicken muss und habe Mails von meinem Gmail- und web.de-Account an das Postfach quotatest@ geschickt. Auch hier kommt keine Benachrichtigung. Das bedeutet dann, dass der Netcup-MTA die Refuse-Meldung "Mailbox full" an den Mail-Sender nicht rausschickt. Also da stimmt dann was nicht.

    Ich schreibe das nun wie empfohlen an den Support. Bin neu bei Netcup und weiß noch nicht so genau wie das hier läuft, danke für den Tipp! :)

  • 4xx = Versuche es später noch mal lieber einliefernder Mailserver


    Der einliefernde Mailserver versucht es dann bis zu ca 2 Tage. Ob er den Absender benachrichtigt, das ist alleine seine Sache.

    "Security is like an onion - the more you dig in the more you want to cry"

  • 4xx = Versuche es später noch mal lieber einliefernder Mailserver


    Der einliefernde Mailserver versucht es dann bis zu ca 2 Tage. Ob er den Absender benachrichtigt, das ist alleine seine Sache.

    Danke, das war ein guter Hinweis. In der Mailqueue des Sender-MTA hab ich die Mails von heute tatsächlich gefunden! Hab dooferweise nicht reingeschaut.
    Ok, mal schau'n was passiert.

    Bei T-Online Empfängern bin ich selbst schon oft über das "Postfach voll" gestolpert und habe bisher immer sofort und direkt die Mail zurück bekommen. Das ist jetzt hier nicht so, was mich vielleicht fehlgeleitet hat.

    Werde weiter berichten, ganz glücklich bin ich noch nicht damit.

  • In älteren Dokus steht noch was von 7 Tage lang alle 3h: http://www.exim.org/exim-html-…/html/spec_31.html#SEC663 . Da steht aber auch drin, wenn man nichts definiert dann wird es nur genau 1 mal versucht und dann geht die Email zurück mit "Unzustellbar".


    Wenn du schon in die Mailqueues reinschauen kannst, dann drehe es einfach runter. Ich würde irgendwas um die 12h nehmen. Das heißt wenn du abends eine Emails schickst, dann hast du am nächsten Vormittag die Gewissheit ob die Email durchging.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Bei mir läuft eh postfix und bzgl. der Bounce-Konfig ist alles auf default. Der Netcup Server jedenfalls meldet völlig korrekt "Mailbox full" (was ja anfangs mein Irrtum war). Was dann die MTA des Mailsenders aus dieser Response machen, ist ja wieder was anderes.


    Es macht irgendwie keinen Sinn, dass der Mail-Absender nicht zeitnah die Bouncemail von seinem MTA bekommt und die Mail erstmal tagelang resended wird und der Absender damit tagelang völlig im unklaren ist - und das eben per default. Nicht nur bei meinem postfix, sondern auch bei gmail, web.de und protonmail. Dort habe ich (nach weniger als 24h) auch noch keine Info über die Verweigerung meiner Testmail.


    Klar, die delays und Anzahl der Zustellversuche lassen sich bei postfix leicht ändern, aber das ändert ja grundsätzlich nichts am Problem (die Versuche über meinen eigenen postfix dienten nur als Test).


    Wie gesagt, was mich stutzig machte waren die Bounce-Mails die ich selbst hin und wieder (sehr selten) mal bekommen habe an T-Online Adressen, deren Mailbox voll war. Dort kamen die dann immer sofort und daher hatte ich dann in meinem Fall einen Fehler vermutet.


    Ich warte also also erstmal auf mehrere Bounce-Mails. Werde es dann hier posten.

  • Also wäre die Anpassung, die netcup hier machen könnte, dass die Mail nicht mit temporärem (4.x.x) sonders mit permanentem (5.x.x) Fehler abgelehnt wird.


    Hätte den Nachteil, dass der Empfänger nicht mal eben schnell sein Postfach aufräumen und Platz schaffen kann, aber den Vorteil, dass der Absender nicht so lange im Ungewissen bleibt.

  • Was ich ganz vergessen hatte zu erwähnen: Du kannst dir vom einliefernden SMTP auch für jede Email die auf 4xx steht einen Delay Report schicken lassen.


    Das sind jetzt aber schon alles die kleinen Kniffe die man als Mail-Admin irgendwann mit umsetzt.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Wie erwartet kamen dann nun von gmail und protonmali die Non delivery reports:

    "Zustellung nicht abgeschlossen Bei der Zustellung Ihrer Nachricht an quotatest@meinedomain.de ist ein vorübergehendes Problem aufgetreten. Gmail versucht noch weitere 45 Stunden, die Nachricht zuzustellen. Sie werden benachrichtigt, falls die Zustellung dauerhaft fehlschlägt. Die Antwort vom Remoteserver ist: 452 4.2.2 Mailbox full"


    Ich hake das jetzt ab und danke euch für die Tipps!