qmail macht dicht

P

Printe

New Member
Hallo,

unser Mailserver qmail macht in der letzten Zeit anstalten und stellt sher häufig die Zustellung von Emails ein. Wenn man ihn neu startet, liefert er brav alles wieder aus, aber das ist natürlich kein Dauerzustand.

Auf dem Weg durch die logfiles machte mich folgendes stutzig:
smtp/tcp server failing (looping), service terminated

Außerdem tauchen extrem viele solcher Zeilen auf:
qmail: 1204212842.524175 starting delivery 1276: msg 174915688 to remote hy_i_das@ademsa.com

Der Hauptadmin ist in Urlaub und ich habe nun den Nutzer an der Backe und wenig Ahnung. Kann mir hier vielleicht jemand wertvolle Tips geben?
 
Interessant wären hier die Status-Meldungen aus dem Logfile, ein Aufruf von /var/qmail/bin/qmail-qstats und evtl. mal einen ganzen Block aus dem Logfile. Am Besten aus der Zeit, wo wirklich gerade nichts geht.

huschi.
 
Alles klar, hier der Aufruf von qmail-stat

/var/qmail/bin/qmail-stat
messages in queue: 1560
messages in queue but not yet preprocessed: 0
 
Last edited by a moderator:
Du bekommst die Emails an Postmaster nicht:
Printe said:
Feb 29 11:21:27 domain qmail: 1204280487.207385 starting delivery 25308: msg 174915614 to remote postmaster@domain.de
Feb 29 11:21:27 domain qmail: 1204280487.207418 status: local 0/10 remote 4/20
Feb 29 11:21:27 domain qmail: 1204280487.211508 delivery 25308: failure: Sorry._Although_I'm_listed_as_a_best-preference_MX_or_A_for_that_host,/it_isn't_in_my_control/locals_file,_so_I_don't_treat_it_as_local._(#5.4.6)/
Feb 29 11:21:27 domain qmail: 1204280487.211766 status: local 0/10 remote 3/20
Feb 29 11:21:27 domain qmail: 1204280487.211925 triple bounce: discarding bounce/174915614
Click to expand...
Setzte Deinen Hostname in die /var/qmail/control/locals.
Und dann nimmst Du noch qmHandle und schaust Dir die Emails in der Queue an.
Könnten es evtl. Spam-Mails sein?

huschi.
 
Hier ein paar mails aus der Remote-Queue:
Code: 
338501786 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: jrandallbrwi@pacpipe.com
  Subject: failure notice
  Date: 25 Feb 2008 16:12:51 +0100
  Size: 4676 bytes

338504500 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: jrandallbrwi@pacpipe.com
  Subject: failure notice
  Date: 25 Feb 2008 16:12:59 +0100
  Size: 4492 bytes

174918656 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: rock_49@yahoo.com
  Subject: failure notice
  Date: 27 Feb 2008 14:52:08 +0100
  Size: 3950 bytes

174916770 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: -mail@aegir.com
  Subject: failure notice
  Date: 27 Feb 2008 15:22:22 +0100
  Size: 2264 bytes

338508088 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: AndreasWerner@wartaponsel.com
  Subject: failure notice
  Date: 27 Feb 2008 14:52:44 +0100
  Size: 2687 bytes

174918242 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: _lil_crazy_1@aam.com
  Subject: failure notice
  Date: 27 Feb 2008 15:04:16 +0100
  Size: 1425 bytes

Ich habe so eine Vermutung: Ich glaube wir haben damals eine Einstellung gesetzt, dass Emails an nicht existente Adressen mit einer Fehlermeldung beantwortet werden sollen. Wenn unser Server nun massiv Spam bekommt, kann es sein, dass sich qmail's smtp Server dann aufhängt, weil er all diese Nachrichten beantworten muss!?

Wie würde man das Problem sinnvoll lösen? Eigentlich ist eine Antwort auf nicht zustellbare Emails ja wünschenswert, wenn sich beispielsweise jemand einfach bei der Emailadresse vertippt hat.
 
Printe said:
Eigentlich ist eine Antwort auf nicht zustellbare Emails ja wünschenswert, wenn sich beispielsweise jemand einfach bei der Emailadresse vertippt hat.
Click to expand...

Nein, ist es nicht, da Du dadurch extrem viel "Back-Scatter" erzeugst. Die richtige Vorgehensweise ist, nicht zustellbare Mails mit einem Fehlercode abzulehnen (noch während die Einlieferung läuft). Der einliefernde MTA bekommt das dadurch richtig mit und erzeugt ggfs. eine Mail für seinen Benutzer. Bei SPAM-Mails ist i.d.R. kein MTA im Spiel und daher werden solche Mails einfach verworfen -- und das Wichtigste dabei: Der (gefälschte!) Absender bekommt dann keine Bounce-Mail für eine Mail, die er nie geschickt hat.

Viele Grüße,
LinuxAdmin
 
Wie kann ich dieses Verhalten denn umstellen? (Ich habe eine vServer mit Debian 3.0 und Plesk 7.5.4)

Außerdem bin ich mir nicht sicher, ob ich das Problem damit nun löse? Ist es denn wahrscheinlich, dass diese "Back-Scatter" Emails die Probleme gebracht haben, so dass der smtp Server seinen Dienst eingestellt hat? Ziel ist es ja, dass in Zukunft der Email Server wegen Überlastung streikt.

Ich habe übrigens mit ./qmHandle -Sfailure mal all diese Emails aus der queue gelöscht.

Und noch etwas es häufen sich Zeilen in den maillog mit dem folgenden Fehler: Wie kann ich diese interpretieren?

Code: 
Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)
 
Last edited by a moderator:
Und noch etwas, was mich stutzig macht:

Code: 
domain:/var/qmail/bin# ./qmHandle -s
Messages in local queue: 0
Messages in remote queue: 6
domain:/var/qmail/bin# ./qmail-qstat
messages in queue: 204
messages in queue but not yet preprocessed: 197

Sorry, wenn ich jetzt vielleich bei Adam und Eva anfange, aber woher kommen diese Unterschiede!?
 
Printe said:
Und noch etwas es häufen sich Zeilen in den maillog mit dem folgenden Fehler:
Click to expand...
Die waren wahrscheinlich auch vorher schon da, sind nur in der Menge untergegangen.
Du muß im Maillog den passenden Info-Eintrag zu der jeweiligen Delivery finden.

Printe said:
aber woher kommen diese Unterschiede!?
Click to expand...
Da ist kein Unterschied: 204 - 197 = ~6. Paßt doch... :)
qmHandle sieht die "not yet preprocessed" Messages nicht sondern zählt nur die, die wirklich in der Queue hängen.

Ein Qmail-Neustart veranlaßt Qmail dazu die anderen Mails einzulesen. Bzw. einfach warten... Irgendwann holt er sie sich...

huschi.
 
Ok bisher habe ich viel gelernt, vielen Dank schonmal dafür! Aber das eigentliche Problem, dass der mail-Server zeitweise nicht mehr mitkommt habe ich noch nicht gelöst.
Ist es die Masse an "Back-Scatter", oder zu viele SMTP Verbindungen, oder...??

Einen Fehler habe ich ja schon gefunden:
Auf dem Weg durch die logfiles machte mich folgendes stutzig:
smtp/tcp server failing (looping), service terminated
Click to expand...

Wonach sollte ich denn in den Logfiles noch suchen?

Auch jetzt scheint sich die queue nur aufzubauen! Den mailserver habe ich bereits neu gestartet.

Code: 
domain:/var/qmail/bin# ./qmHandle -s
Messages in local queue: 0
Messages in remote queue: 6
domain:/var/qmail/bin# ./qmail-qstat
messages in queue: 496
messages in queue but not yet preprocessed: 490
 
Schau nach, was es für Emails sind. Wo kommen die her, wo gehen die hin.
Es klingt nun fast nach einem Spam-Problem.

huschi.
 
qmHandle -R liefert vor allem solche mails in der queue:

Code: 
338500866 (22, R)
  Return-path: 
  From: MAILER-DAEMON@domain.de
  To: jrankin@polyprep.org
  Subject: failure notice
  Date: 29 Feb 2008 13:58:44 +0100
  Size: 2472 bytes

Und nochwas, als ich gerade den inetd neu gestartet habe wurde alle Emails bearbeitet und in die remote queue geschoben.
 
Ok ich habe gefunden, wie ich die Beantworung von nicht existierenden Email-Adressen abstellen kann:

Wenn man sich als admin in Plesk einlogged und eine Domain auswählt,
klickt man bei EMail auf Einstellungen. Dort kann man bei
der Option 'E-Mail an nicht existierenden Benutzer' auf Zurückweisen
klicken. Somit werden dann keine Responsemails mehr verschickt.

Ich hoffe das nimmt die Last vom Mailserver und die Probleme gehören der Vergangenheit an...
 
Hallo Huschi!

Die ganzen Messages in der queue waren tatsächlich automatische Antwort-Emails vom qmail. Die wurden versendet wenn eine Email (meist spam) an eine nicht vorhandene Email-Adresse auf dem Server gesendet wurde. Das hat natürlich eine große Last auf den Server gebracht, die wahrscheinlich zu groß wurde nach der Zeit. Das habe ich nun im Plesk für alle Domains abgestellt, so dass diese Emails einfach zurückgewiesen werden.
Derzeit werden alle Emails sauber ausgeliefert ohne Stau in der Queue.

Ein anderes Problem macht mir aber noch zu schaffen und dass hängt mit dem smpt Server zusammen. Teilweise können die Leute kein Webmail machen oder keine Mails versenden. Ich bekomme regelmäßig folgende Fehlermeldung im syslog:

Mar 1 15:49:40 domain inetd[9912]: smtp/tcp server failing (looping), service terminated

Denkt ihr das KB #1470 - SMTP service stops to work with an error like "smtp/tcp server failing (looping), service terminated" in /var/log/messages. könnte mir dabei helfen!?

Stimmt die Syntax mit nowait.1000, denn in meiner inetd.conf kommt auch mal nowait/1000 vor!? :confused:

Vielen Dank!!

Und wenn ja, ist das ein sinnvoller Schritt
 
Du glaubst eher einem User hier statt dem Hersteller der Software?
Click to expand...

Ich versuche mir einfach nur mehrere Meinungen einzuholen und verändere nicht einfach irgendwelche Dinge an einem live-System, bloß weil es auf irgendeiner Webseite steht!

Das Problem scheint behoben und die richtige Syntax ist nowait.1000, falls das nochmal jemand ließt, dem das helfen könnte.

Trotzdem danke für die Hilfe hier im Forum...
Printe
 
You must log in or register to reply here.
Back
Top