Mail-Server » Qmail

ID #1383 Plesk: Seit Update auf 9.3 funktionieren die lokalen Emails nicht mehr

Problem:

Nach einem Update funktionieren die lokalen Emails (also an Postmaster, root als auch drweb und anonymous) nicht mehr.
Das ist inzwischen ein bekanntes Problem von Plesk 9.3.

Symptome:

  • Ständig bouncende Emails. Besonders häufig ist postmaster@....
  • Die Queue wird ggf. voller (muss aber nicht).
  • Die CPU-Last steigt bei nicht so starken (virtuellen) Servern.
  • Häufig sind es Cronjob-/DrWeb-Update-Mails.
    Es können aber auch Emails sein die nach Extern geleitet werden sollen aber von anderen Mail-Servern nicht angenommen werden, weil eben kein FQDN im helo angegeben wird.
  • Oder der Absender enthält nur einen (nicht FQDN-)Teil des Hostnamen.
  • Evtl. gibt es zusätzlich Probleme mit dem Greylisting-Filter.

Typische Einträge im Logfile:

Remote host said: 504 5.5.2 : Sender address rejected: need fully-qualified address
...
qmail-queue-handlers[26502]: from=postmaster@s12345678

Diagnose:

Fehlerhafte Einträge in /var/qmail/control/me und /var/qmail/control/locals für den FQDN-Hostnamen.

Lösungen:

  1. Qmail stoppen
  2. a) In Plesk unter "Einstellungen" -> "Hostname ändern" die Hostname in irgendwas (z.B. "xxx.de") umändern und speichern. Kurz warten (max. 30 bis 60 Sekunden) bis es auf der Console per "hostname" und die control/me umgesetzt wurde.
    Danach den realen FQDN-Hostnamen (am Besten den RPTR) Eintragen und speichern.
  3. b) Per Hand den Hostname setzten und in control/me und control/locals einsetzten.
  4. Die Bounce-Mails per qmHandle löschen:
    qmHandle -S"failure notice"
  5. Ggf. weitere Cron-Emails aus der Mail-Queue löschen.
  6. Qmail starten

Weitere Ansätze:

Eine andere Lösung findet sich ebenfalls im Internet:
Die qmail-local muss die selben Ausführungsrechte wie die qmail-remote erhalten:

chown mhandlers-user:popuser /var/qmail/bin/qmail-local
chmod g+s /var/qmail/bin/qmail-local

Diese Lösung bezieht sich allerdings auf ein anderes Problem, welches sich in Logfiles in folgender Form äußert und dann das Multi-Bouncen anfängt:

qmail-local-handlers[12270]: cannot create temporary file - (13) Permission denied
qmail-local-handlers[12270]: cannot read message from stdin

Dieser Fehler kam bereits mit Plesk 9.2 auf.

Qmail neu installieren

Die einfachste Methode Qmail neu zu installieren (und damit die aktuellen Binaries, Handlers etc. neu zu laden und korrekte Dateirechte zu vergeben) ist einmal kurz auf Postfix wechseln und dann zurück zu Qmail:

#Wechsel auf Postfix
/usr/local/psa/admin/sbin/autoinstaller --select-release-current --install-component postfix
#...und zurück zu Qmail
/usr/local/psa/admin/sbin/autoinstaller --select-release-current --install-component qmail

 

sozial Bookmarking
Bookmarken bei YIGG Bookmarken bei Mister-Wong Bookmarken bei Icio Bookmarken bei del.icio.us Bookmarken bei Technorati Bookmarken bei Furl Bookmarken bei Spurl Bookmarken bei Yahoo Bookmarken bei Google

vom 2010-02-21 21:50, zuletzt 2010-02-22 09:55     Artikel ausdrucken Artikel weiterempfehlen Als PDF-Datei anzeigen

Dieser Inhalt ist unter der Creative-Commons Lizenz lizensiert.

Probleme bitte im Server-Support-Forum diskutieren.

Rubriken zu diesem Artikel
überflüssig 1 2 3 4 5 wertvoll  
Durchschnittliche Bewertung:   4.25 von 5 (4 Bewertungen)

Artikel kommentieren

Kommentar von Tobias (2010-03-02 17:19:06):
dieses problem tritt übrigens nicht nur bei "reinen" lokalen mails auf, sondern leider auch bei mails von extern, die lokal an eine andere lokale adresse weitergeleitet werden (z.b. bei aliasadressen deren postfach zusätzlich eine mailgruppe benutzt, um die mails an ein zweites (archiv-)postfach zu übergeben)

die oben genannten lösungsansätze brachten leider keinen erfolg :(

Kommentar von ngc (2010-03-06 00:00:51):
ebenfalls kein erfolg problem leider nicht behoben.

Kommentar von Mapache (2010-03-13 13:48:42):
Bei mir gab es anfangs dei Datei qmail/control/helohost gar nicht. Nach erzeugen und mit dem FQDN ausgestattet geht es, allerdings wird die Datei seltsamerweise nachts mit dem unvollständigen HELO überschrieben??
Eine Idee dazu?

Vg
Mapache

Kommentar von Frank Segelke (2010-04-23 08:57:02):
Hallo Jan,
Bei mir war das Phänomen beim Update von 9.0 auf 9.3 und auch beim nächsten Update auf 9.5 aufgetreten. Allerdings liegt die Ursache wohl tiefer:

Die Datei /etc/hosts scheint dafür verantwortlich zu sein:
Bei mir stand folgendes drin (IP-Nummer, Domain und Servernamen unkenntlich):

127.0.0.1 localhost.localdomain localhost
(IP-Nummer) sxxxxxx.onlinehome-server.info sxxxxxx Domain

Der 4. Eintrag Domain ist meines Erachtens falsch. Der müsste eigentlich in die nächste Zeile, dann würde die Datei so aussehen:
127.0.0.1 localhost.localdomain localhost
IP-Nummer sxxxxxx.onlinehome-server.info sxxxxxx
Ip-Nummer Domain

Leider ;-}(?) gibts noch kein neues Update, wo ich das mal ausprobieren kann. Würde mich über Feedback freuen.

Kommentar von huschi (2010-04-23 09:19:12):
Hallo Frank,

nein, die hosts-Datei ist nicht der Grund.
Es können hinter einer IP beliebig viele mit Space/Tab getrennte Domains stehen.
Außerdem wird diese Datei nur zur Auflösung Domain -> IP herangezogen.

Der Fehler von Plesk ist, dass er die /var/qmail/contorl/me mit `hostname` füllt. Häufig ist dieser aber nicht der FQDN der Maschine. Dieser kommt erst mit `hostname -f`.

huschi.

Kommentar von Phillson (2010-06-06 23:20:22):
Bei mir war, neben den beschriebenen Problemen (HELO, Rechte), der grundlegende Auslöser eine leere assign unter /var/qmail/users/. Beim Update wurden scheinbar die Informationen der gesicherten assign nicht zurück in die neu angelegte Datei geschrieben.

Kommentar von sambo (2011-09-12 13:22:57):
Hallo Jan,
interessant bei den fehlerhaften HELO-Einträgen ist, das qmail bei der Kommunikation mit gmx/web.de nur meldet "Sorry,_I_wasn't_able_to_establish_an_SMTP_connection" (postfix gibt eindeutigere Hinweise das es am FQDN liegt)
Hierzu vielleicht auch der Hinweis: Um die IP bei den freemailern wieder frei zu bekommen nutzt man bei web.de am besten das Formular unter http://postmaster.web.de/de/kontakt/ - dann ist die IP normal nach 1 Std. wieder frei (auch am WE). Bei gmx geht's scheinbar nur über eine Mail an mailsecurity@gmxnet.de - die wird dann zu normalen Arbeitszeiten bearbeitet und es dauert ca. 3-4 Std. nach deren Rückmeldung, bis es wieder geht ...
Beste Grüße, Peter