Wenn Sie eine steigende Anzahl an Nachrichten in der qMail-Warteschlange feststellen, oder aber Mails direkt mit dem Hinweis "System_resources_temporarily_unavailable" an den Absender zurück geschickt werden, so kann dies an einem Plesk Update liegen wodurch ursprünglich die IPv6-Kompatibilität u.a. auch für den MTA qmail hergestellt werden sollte.
Zum aktuellen Zeitpunkt konnten wir dieses Verhalten bei folgender Setup-Kombination feststellen:
Prüfen ob das Problem auf dem Server aufritt:
Loggen Sie sich als root auf dem Server ein und prüfen Sie die qMail-Warteschlange
# /var/qmail/bin/qmail-qstat
messages in queue: 34
messages in queue but not yet preprocessed: 0`
Kommt Ihnen die Anzahl unnatürlich hoch vor, können Sie auch das Maillog auf den Fehler mit folgendem Befehl prüfen:
# grep -Ri 'System\_resources\_temporarily\_unavailable' /usr/local/psa/var/log/maillog
Bekommen Sie nun eine Liste mit Fehlern angezeigt ist es ein Zeichen dafür, dass auch Ihr Server das geschilderte Problem hat.
Mutmaßung:
Mit der neuen Version von Plesk 10.3.x sollte die IPv6 Kompatibitlität hergestellt werden. Zu diesem Zweck wurde qmail mit einem entsprechenden Patch kompiliert. Verfügt nun der empfangende Server bereits über eine IPv6 Adresse versucht qmail nun an diese Adresse, statt an die IPv4 Adresse zu senden. qMail prüft scheinbar nicht an dieser Stelle, ob auf dem Server überhaupt IPv6 aktiviert oder konfiguriert wurde und nimmt den IPv6 Wert als default.
Diverse Lösungsansätze wie z.B. die Anlage von Statischen Mailroutes waren bislang erfolglos. Das Problem wurde bereits hier im der Parallels Forum diskutiert. Der dort angebotene Lösungsansatz - postfix statt qmail zu installieren - erscheint jedoch wenig sinnvoll und unattraktiv.
Das Problem wurde bereits an Parallels gemeldet und aktuell seitens der Entwicklung überprüft.
Workaround (Einsatz auf eigene Gefahr! Keine Gewährleistung!):
Auf mehreren Server konnten wir erfolgreich eine ältere Version von den Plesk qMail Paketen installieren, ohne das unserer Einstellungen oder Mails verloren gingen. Dazu haben wir die in der Anlage aufgeführten RPM-Pakete (für Red Hat 5.x - x86_64 Systeme) von einem älteren Server gesichert und auf den Plesk 10.3.x Servern wie folgt installiert:
# rpm -Uvh plesk-mail-qc-driver-10.10.1-rhel5.build1010110120.18.x86\_64.rpm --force --nodeps
# rpm -Uvh plesk-mail-qc-driver-10.10.1-rhel5.build1010110120.18.x86\_64.rpm --force
# rpm -Uvh psa-qmail-1.03-rhel5.build1010110112.13.x86\_64.rpm --force
Sollten Sie einen alternatives Greylisting Verfahren nutzen, müssen Sie ggf. auch die /etc/xinit.d/smtp_psa manuell anpassen.
Starten Sie den qmail Server mit folgendem Befehl neu:
# /etc/init.d/qmail restart
Starten Sie ggf. auch den xinetd neu mit folgendem Befehl:
# /etc/init.d/xinetd restart
Bitte stellen Sie auf jeden Fall vor Einsatz der Dateien ein Backup her. Der Einsatz des o.g. Workarounds erfolgt ohne jegliche Gewähr. Als Anlage sind sowohl die einzelnen Dateien, als auch ein Archiv mit allen Dateien beigefügt. Es handelt sich um unmodifizierte Dateien.
Auch in dem aktuellsten Plesk Sicherheitsupdate vom 10.2.2012 ist der Fehler erneut wieder vorhanden. Der Parallels Plesk Support ist informiert worden und Stand heute (6.3.2012) den Fehler auch bestätigt. Parallels selbst empfiehlt ein Downgrade auf ein älteres qMail Paket ohne IPv6 Unterstützung.
Um nach dem Downgrade die qMail-Warteschlange zur Auslieferung anzustossen, kann man per Konsole folgenden Befehl ausführen:
killall -ALRM qmail-send
Inzwischen gibt es zu diesem Sachverhalt einen offizellen Parallels Knowledgbase Eintrag, welcher u.a. auch entsprechende Patch-Dateien für unterschiedliche Linux Distributionen enthält. Hier der Link zum Knowledgebase Eintrag.
Parallels hat nun mit dem Erscheinen des Micro-Update #7 für Plesk 11.0.9 den Fehler lt. Parallels Knowledgebase behoben. Hier der Link zum Knowledgebase Eintrag.