qmail queued ausgehende Mails ohne Fehlermeldung

zeaq · Jun 23, 2008

Hallo zusammen,

ich habe einen Server mit Debian und Plesk 8.4.0 bei Strato. Seit einiger Zeit habe ich das Problem, dass abgesendete Mails eines Freundes "immer häufiger" im Queue landen. Mein Hauptproblem ist, dass ich anhand der Logdateien keinen Grund hierfür erkennen kann. Dazu kommt, dass dieses Problem nicht dauerhaft ist. Mal tritt es auf, mal nicht. Die Empfänger dieser Mails sitzen - ich glaube alle - in England und haben eine *.co.uk Domain - wobei ich mir nicht vorstellen kann, dass das relevant ist. Auf jeden Fall tritt das Problem nicht nur bei einem Empfänger auf, so dass ich das Problem doch wohl bei mir vermuten muss.

Kann jemand anhand des Protokolls einen Grund für das Queuing feststellen oder kann mir jemand einen Tipp geben, wo ich sehe, warum eine Mail gequeued wurde!?

Hier der Auszug aus /var/log/mail.info: (Domainnamen geändert)

Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: Handlers Filter before-queue for qmail started ...
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: from=martin@absender.de
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: to=judith@empfaenger.co.uk
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: hook_dir = '/var/qmail//handlers/before-queue'
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: recipient[3] = 'judith@empfaenger.co.uk'
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: handlers dir = '/var/qmail//handlers/before-queue/recipient/judith@empfaenger.co.uk'
Jun 23 14:53:00 h562633 qmail: 1214225580.322592 new msg 6455597
Jun 23 14:53:00 h562633 qmail: 1214225580.322649 info msg 6455597: bytes 5960 from <martin@absender.de> qp 3699 uid 2020
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: starter: submitter[3699] exited normally
Jun 23 14:53:00 h562633 qmail: 1214225580.326006 starting delivery 24: msg 6455597 to remote judith@empfaenger.co.uk
Jun 23 14:53:00 h562633 qmail: 1214225580.326062 status: local 0/10 remote 1/20
Jun 23 14:53:00 h562633 qmail-remote-handlers[3700]: Handlers Filter before-remote for qmail started ...
Jun 23 14:53:00 h562633 qmail-remote-handlers[3700]: from=martin@absender.de
Jun 23 14:53:00 h562633 qmail-remote-handlers[3700]: to=judith@empfaenger.co.uk

Ich bin dann noch auf die Idee gekommen den Empfaenger-Mailserver zu testen und habe folgende versucht (Domainnamen und IP's geändert):

server:/var/log# nslookup -type=mx empfaenger.CO.UK
Server: 111.111.1.11
Address: 11.111.1.11#53

Non-authoritative answer:
EMPFAENGER.CO.UK mail exchanger = 2 mail-in.mailserver.com.

Authoritative answers can be found from:

server:/var/log# telnet mail-in.mailserver.com 25
Trying 111.111.11.111...
Connected to mail-in.freeserve.com.
Escape character is '^]'.

Hat einer von euch Ideen, woran dieses Verhalten liegen könnte?

Vielen Dank im Vorraus!
Zeaq

Huschi · Jun 23, 2008

Du mußt mal die Mails in der Queue genauer anschauen. (Qmail: Mail-Queue verwalten)
Das klingt als ob Dein Server entweder viel Bounces verschickt oder sogar Spam.
Über meinen Server werden Spam's verschickt!

huschi.

zeaq · Jun 23, 2008

Danke für deine Antwort

Hallo großer Häuptling ;-)

danke für deine Antwort. Aber selbstverständlich (!!!) habe ich deine beiden Seiten schon gelesen, lange bevor ich überhaupt an diesen Artikel gedacht habe ;-)

Thema Spam: Das kann ich relativ sicher ausschließen. Es ist weder so, dass mein Mailserver annähernd unter Volllast fährt, noch dass sich nur eine einzige Spammail in die Mailqueue verirrt hat. Im Gegenteil lesen sich die Logfiles (maillog, mail.info) sehr übersichtlich - ich habe dort noch keinen unberechtigten Absender entdeckt und in der Mailqueue steht eigentlich auch nie eine einzige Mail. Bis auf eben diese Mails von meinem Freund, die da nun eigentlich überhaupt nichts zu suchen hätten.... jedenfalls aus meiner Sicht.

Thema Mailqueue Verwaltung: Auch qmHandles habe ich schon auf meinem Server. Die Seite hat mir damals auch schon sehr weiter geholfen. Allerdings fehlt mir genau das was ich suche: Wie kann ich heraus finden, warum eine Mail überhaupt in der Queue steht. Überlicherweise erwarte ich diese Meldungen im Maillog. Dort habe ich sie teilweise auch gefunden z.b. SMTP Server vorübbergehend überlastet o.ö. Diesesmal finde ich aber keinen Hinweis, keine Warnung und keine Fehlermeldung.

An diese Stelle vielleicht direkt noch eine Frage zu qmHandles: Wenn ich "./qmHandles -a" aufrufe soll die Queue ja komplett abgearbeitet werden. In Folge dessen würde ich Ausgaben im Maillog erwarten. Dort passiert aber einfach garnichts. Was mich dazu verleitet daran zu Zweifeln, dass Qmail überhaupt etwas tut. (Ist ja sonst so eine Laberbacke). Aber selbst ein "kill -ALRM <pid>" bringt keine Reaktion. Das sollte aber doch mit jedem Qmail - selbst wenn Plesk mit von der Partie ist - funktionieren, oder?

Spontaner Gedankengang: Läuft Qmail per Inetd und wird nur zum Mailversand gestartet...*grübel*.... bis zur nächsten Antwort halte ich mal Rücksprache mit meinem Server ;-)

Also meine eigentliche Frage ist, wie ich heraus finden kann, warum eine Mail in die Mailqueue gewandert ist anstatt verschickt zu werden. Das sollte doch dick und fett in irgendeiner Logfile stehen. Mich wundert das Ganze ja eben deshalb so, weil ich eine halbe Stunde erfolgreich eine Mail an den gleichen Empfänger geschickt habe - also der Mailaccount existiert definitiv.

Nochmal vielen Dank für deine Antwort!

Viele Grüße aus Köln
Zeaq

Huschi · Jun 23, 2008

zeaq said:
Bis auf eben diese Mails von meinem Freund, die da nun eigentlich überhaupt nichts zu suchen hätten....

Das kann ich nicht riechen und geht aus Deinem ersten Beitrag auch nicht hervor.

Diesesmal finde ich aber keinen Hinweis, keine Warnung und keine Fehlermeldung.

Was findest Du denn zu dieser Email im Logfile?

Wenn ich "./qmHandles -a" aufrufe soll die Queue ja komplett abgearbeitet werden.

Kann ggf. mit Plesk nicht 100%ig funktionieren. Er ruft dabei lediglich einen Qmail-Restart auf.
Diesen kannst Du aber auch per Hand ausführen.

Spontaner Gedankengang: Läuft Qmail per Inetd und wird nur zum Mailversand gestartet...

Nein. Siehe "ps aux|grep qmail".

Das sollte doch dick und fett in irgendeiner Logfile stehen.

Wie dick und fett es drin steht, kann ich von hier aus nicht sagen.
Aber theoretisch gesehen muß fast jeder Eintrag dick und fett sein.

huschi.

zeaq · Jun 24, 2008

Huschi said:
Das kann ich nicht riechen und geht aus Deinem ersten Beitrag auch nicht hervor.

Ich hatte versucht es verständlich auszudrücken. Aber macht ja nix, solange ich mich jetzt verständlich machen konnte ;-)

Huschi said:
Was findest Du denn zu dieser Email im Logfile?

Ich habe alle Zeilen die ich zutreffend fand in meinen ersten Beitrag gepackt. Ich habe jetzt gerade noch mal die Logfile durch sucht und zu der "starting delivery 74" Zeile die "delivery 74" Zeile gefunden - ich hoffe mal das gehört nach der Logik zusammen. In Gänze schaut das also so aus:

Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: Handlers Filter before-queue for qmail started ...
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: from=martin@absender.de
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: to=judith@empfaenger.co.uk
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: hook_dir = '/var/qmail//handlers/before-queue'
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: recipient[3] = 'judith@empfaenger.co.uk'
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: handlers dir = '/var/qmail//handlers/before-queue/recipient/judith@empfaenger.co.uk'
Jun 23 14:53:00 h562633 qmail: 1214225580.322592 new msg 6455597
Jun 23 14:53:00 h562633 qmail: 1214225580.322649 info msg 6455597: bytes 5960 from <martin@absender.de> qp 3699 uid 2020
Jun 23 14:53:00 h562633 qmail-queue-handlers[3698]: starter: submitter[3699] exited normally
Jun 23 14:53:00 h562633 qmail: 1214225580.326006 starting delivery 24: msg 6455597 to remote judith@empfaenger.co.uk
Jun 23 14:53:00 h562633 qmail: 1214225580.326062 status: local 0/10 remote 1/20
Jun 23 14:53:00 h562633 qmail-remote-handlers[3700]: Handlers Filter before-remote for qmail started ...
Jun 23 14:53:00 h562633 qmail-remote-handlers[3700]: from=martin@absender.de
Jun 23 14:53:00 h562633 qmail-remote-handlers[3700]: to=judith@empfaenger.co.uk
...
Jun 23 14:53:00 h562633 qmail: 1214225580.326006 starting delivery 24: msg 6455597 to remote judith@empfaenger.co.uk
...
Jun 23 15:13:00 h562633 qmail: 1214226780.229956 delivery 24: deferral: Connected_to_111.111.11.111_but_connection_died._(#4.4.2)/
Jun 23 15:13:00 h562633 qmail: 1214226780.230048 starting delivery 33: msg 6455597 to remote judith@empfaenger.co.uk
...
Jun 23 15:33:00 h562633 qmail: 1214227980.109449 delivery 33: deferral: Connected_to_111.111.11.111_but_connection_died._(#4.4.2)/

Da stören mich jetzt aber zwei Dinge:
1. Weshalb versucht er erst um 15:13 die erste Zustellung (oder ist die Verbindung die Ganze Zeit offen gewesen und jetzt zusammen gekracht)?
2. Für mich hört sich "but connection died" ziemlich erfolglos an. Weshalb wird zwar noch eine "delivery 33" gestartet aber danac - nach Logfile - offensichtlich nichts mehr? (Und das obwohl die Mail zwischenzeitlich versand ist.) Ist das richtig, die Ausgaben anhand der "delivery <number>" zu kombinieren?

Kann ggf. mit Plesk nicht 100%ig funktionieren. Er ruft dabei lediglich einen Qmail-Restart auf. Diesen kannst Du aber auch per Hand ausführen.

Danke für den Tipp.

Viele Grüße
ZEaq

zeaq · Jun 24, 2008

Soo... Teil 1 gelöst.

So. Ich glaube jetzt bin ich etwas schlauer:

Code:

    Jun 23 14:53:00 h562633 qmail: 1214225580.322592 new msg 6455597
    Jun 23 14:53:00 h562633 qmail: 1214225580.322649 info msg 6455597: bytes 5960 from <martin@absender.de> qp 3699 uid 2020

    Jun 23 14:53:00 h562633 qmail: 1214225580.326006 starting delivery 24: msg 6455597 to remote judith@empfaenger.co.uk
    Jun 23 15:13:00 h562633 qmail: 1214226780.229956 delivery 24: deferral: Connected_to_193.252.22.186_but_connection_died._(#4.4.2)/
    Jun 23 15:13:00 h562633 qmail: 1214226780.230019 status: local 0/10 remote 1/20

    Jun 23 15:13:00 h562633 qmail: 1214226780.230048 starting delivery 33: msg 6455597 to remote judith@empfaenger.co.uk
    Jun 23 15:13:00 h562633 qmail: 1214226780.230073 status: local 0/10 remote 2/20
    Jun 23 15:33:00 h562633 qmail: 1214227980.109449 delivery 33: deferral: Connected_to_111.111.11.111_but_connection_died._(#4.4.2)/
    Jun 23 15:33:00 h562633 qmail: 1214227980.109506 status: local 0/10 remote 1/20

    Jun 23 15:41:37 h562633 qmail: 1214228497.353356 starting delivery 68: msg 6455597 to remote judith@empfaenger.co.uk
    Jun 23 15:41:37 h562633 qmail: 1214228497.353415 status: local 0/10 remote 2/20
    Jun 23 15:42:33 h562633 qmail: 1214228553.421269 delivery 68: success: 1111.111.11.111_accepted_message./Remote_host_said:_250_Ok:  _queued_as_CA6F11C0006A/
    Jun 23 15:42:33 h562633 qmail: 1214228553.421329 status: local 0/10 remote 0/20
    Jun 23 15:42:33 h562633 qmail: 1214228553.421355 end msg 6455597

Ich habe jetzt immer nach der "Message-ID" gesucht bis ich eine "starting delivery <delivernummer>" gefunden haben. Dazu habe ich dann das entsprechende "delivery <deliverynummer>" gesucht. Und so findet man dann die Fehlermeldung, weshalb die Mail weiterhin in der Queue bleibt (das findet man leider über die Message-ID nicht!). Sucht man nach "end msg <nummer>" findet man anschließend die Erfolgsmeldung - wenn es sie gibt.

Jetzt mache ich mich wohl mal auf die Suche nach der Meldung "but_connection_died". Falls wer Ideen hat immer her damit ;-)

zeaq · Jun 24, 2008

but_connection_died

Ich habe jetzt versucht etwas über den Fehler zu finden und zwei Lösungen gefunden, die aber beide bei mir nicht funktionieren:

#!/bin/bash
echo 1 > /proc/sys/net/ipv4/netfilter/ip_contrackk_tcp_be_liberal

This will enable the option on startup in SuSE 10.0

Quelle: Connected_to_< Remote IP >_but_connection_died [Archive] - Parallels Server Product Forums

Ich habe diese Datei leider nicht. Gibt es vlt. nur auf SuSE!?

You need to check your qmail-send run file an up the memory size for it. Its probably in /var/qmail/control/qmail-send/run
increase the value to 10000000 (10 MB of RAM per instance) and see if it can handle the work.
You are running out of the protected memory available to the daemon (I think). Be sure to restart qmail.

Diese Datei habe ich leider auch nicht ab "qmail-send".

Quelle: D. J. Bernstein: qmail - Connected to x x x x but connection died. (#4.4.2)

Hat jemand weitere Ideen für mich? Weiß außerdem jemand wie ich die Zeitabstände zwischen den Zustellungsversuchen verkürzen kann (auf http://www.huschi.net/5_272_de.html habe ich das leider nicht gefunden)?

Huschi · Jun 24, 2008

zeaq said:
echo 1 > /proc/sys/net/ipv4/netfilter/ip_contrackk_tcp_be_liberal

Bevor man so etwas macht sollte man immer Onkel Google befragen!
Denn mit "ip_contrackk_tcp_be_liberal" förder er lediglich diese eine Seite zu Tage, was sehr Auffällig ist und auf einen Schreibfehler hinweißt.
Korrekt heißt die Datei "ip_contrack_tcp_be_liberal".

Ich habe diese Datei leider nicht. Gibt es vlt. nur auf SuSE!?

Dies ist (grob gesagt) ein Kernel-Parameter und gibt es also auf allen modernen Linux-Kernel. Das sie nicht existiert heißt lediglich, daß der Kernel dann einen Default-Wert nutzt.

Weiß außerdem jemand wie ich die Zeitabstände zwischen den Zustellungsversuchen verkürzen kann

Ja, weiß ich. Die Abstände sind in Qmail hardcodiert. D.h. Du müßtest Qmail dafür verändern und neu kompilieren.

huschi.

zeaq · Jun 24, 2008

Mailauslieferung

Hallo Huschi,

danke für die Antworten. Den Schreibfehler hatte ich innerlich schon korrigiert. Auch eine "ip_contrack_tcp_be_liberal" finde ich bei mir nicht. Kannst du denn sagen ob eine dieser beiden Möglichkeiten überhaupt Abhilfe für mein Problem schaffen kann?

Zeaq

marneus · Jun 24, 2008

Huschi hat es doch schon deutlich gemacht. Die Datei erstellst Du und überschreibst damit einen Kernel-Default Wert. Wenn es die Datei nicht gibt, wird wahrscheinlich der default Wert 0 sein. Durch die Erstellung der Datei wird der Wert auf 1 gesetzt.

--marneus

Huschi · Jun 24, 2008

Ich zitiere mich nur ungern selber:

Huschi said:
Das sie nicht existiert heißt lediglich, daß der Kernel dann einen Default-Wert nutzt.

Ob es bei Dir helfen kann, verrät mir meine Kristallkugel gerade nicht. Aber evtl. ein andermal, nachdem Du es bereits ausprobiert und das Ergebnis hier veröffentlicht hast.

huschi.

/edit: Da mischt sich doch glatt jemand in meine Kommunikation ein...

zeaq · Jun 24, 2008

ip_conntrack_tcp_be_liberal

Ok. Das mit "ip_conntrack_tcp_be_liberal" (übrigens mit zwei n!!) habe ich jetzt verstanden. Allesdings habe ich keinen schimmer, was diese Einstellung ändern. Ich werde da mal suchen und es ggf. ausprobieren. Falls ihr mir die Suche abnehmen wollt, freue ich mich über Antworten

zeaq · Jun 25, 2008

ip_conntrack_tcp_be_liberal

Hallo,

nächstes Problem. Mein Proc wehrt sich beschrieben zu werden. Mein System ist ein Debian Sarge. Ist das gewollt?

Code:

server:/proc/sys/net/ipv4/netfilter# touch ip_conntrack_tcp_be_liberal
touch: kann ,,ip_conntrack_tcp_be_liberal" nicht berühren: Datei oder Verzeichnis nicht gefunden

Vielen Dank
Zeaq

Huschi · Jun 25, 2008

Von "touch" steht da auch nirgendwo etwas.
Aber kann es sein, daß Du einen Vserver hast? Da lassen sich einige Netzwerk-Einstellungen nicht ändern weil sie nun mal vom Hostsystem abhängig sind. (Ob ip_conntrack_tcp_be_liberal darunter fällt weiß ich aus dem Stegreif auch nicht.)

huschi.

zeaq · Jun 25, 2008

touch

Hallo Huschi,

Von "touch" steht da auch nirgendwo etwas.

Mit echo habe ich das natürlich vorher versucht. Das sollte nur zeigen, dass es selbst mit "billigsten" Werkzeugen nicht möglich ist die Datei anzulegen.

Der Vollständigkeitshalber:

Code:

server:/home/zeaq# echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
bash: /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal: Datei oder Verzeichnis nicht gefunden

Aber kann es sein, daß Du einen Vserver hast? Da lassen sich einige Netzwerk-Einstellungen nicht ändern weil sie nun mal vom Hostsystem abhängig sind. (Ob ip_conntrack_tcp_be_liberal darunter fällt weiß ich aus dem Stegreif auch nicht.)

Nein es ist kein VServer, da kenne ich dieses Verhalten. Es ist ein vollwertiger dedicated Server.

PS: Laut "mount" sollte das Verzeichnis schreibbar sein:

Code:

h562633:/boot# mount | grep "proc"
proc on /proc type proc (rw)

Zeaq.

Roger Wilco · Jun 25, 2008

Wie schon unter RootForum.de • qmail stellt Mails ohne BegrÃ¼ndung in Warteschlange beschrieben dient die Datei in /proc zur Steuerung eines Parameters für das Connection Tracking von Netfilter. Wenn du Netfilter bzw. dessen Connection Tracking nicht benutzt, hast du logischerweise auch diese Pseudodatei nicht und kannst sie auch nicht anlegen!

Huschi · Jun 25, 2008

Klär Dich bitte über das /proc/-Verzeichnis auf!

Code:

lsmod | grep conn
sysctl -a | grep ip_conntrack

huschi.

zeaq · Jun 25, 2008

sdfsfd

Hallo Huschi,

Huschi said:
Klär Dich bitte über das /proc/-Verzeichnis auf!

danke für deine Tipps. Damit komme ich schon mal ein ganzes Stück weiter.

Erstmal die Ausgabe zu deinen beiden Befehlen:

Code:

server:/etc# lsmod | grep conn
ip_conntrack           35432  2 iptable_nat,ipt_state
server:/etc# sysctl -a | grep ip_conntrack
net.ipv4.ip_conntrack_max = 32648
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_buckets = 4081
net.ipv4.netfilter.ip_conntrack_max = 32648

Für mich sieht das so aus, als wäre der Parameter hier auch nicht vorhanden, was folgende bestätigt (wenn ich beim Umsetzen der Notation jetzt keinen Fehler gemacht habe):

Code:

server:/etc# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1
error: 'net.ipv4.netfilter.ip_conntrack_tcp_be_liberal' is an unknown key

Ich fange dann mal an zu googlen. Bis dahin bin ich wie immer für weitere Anmerkungen offen ;-)

Zeaq.

Huschi · Jun 25, 2008

Vielleicht wäre es noch sinnvoll mal anzugeben, welches Debian und welchen Kernel Du nutzt.
Ich denke der Kernel von Debian 3.1 war noch nicht so weit. Was aber bedeutet, daß dort die neuen Netfilter-Features nicht drin sind, die man mit dieser Zeile ausschalten würde.

PS: Hast Du den Hinweiß im rootforum bzgl. dem Greylisting gelesen und verstanden?

huschi.

zeaq · Jun 25, 2008

Hey,

Huschi said:
Vielleicht wäre es noch sinnvoll mal anzugeben, welches Debian und welchen Kernel Du nutzt. Ich denke der Kernel von Debian 3.1 war noch nicht so weit.

Macht sinn ;-) Es handelt sich um ein Debian Sarge System:

Code:

Linux server 2.6.8-4-686 #1 Wed Feb 20 03:50:44 UTC 2008 i686 GNU/Linux

Demnach benötige ich diese Einstellung übernimmt. Mhh... Schade, das war so ein schöner Ansatzpunkt ;-)

Huschi said:
PS: Hast Du den Hinweiß im rootforum bzgl. dem Greylisting gelesen und verstanden?

Ja. Ich stehe mit den Empfängern in Kontakt. Zum Teil konnte ich hier schon Lösungen erreichen (z.B. bei der Meldung "Sorry, I wasn't able to establish an SMTP connection" wurde eine Anti-Spam Lösung mit Reputationslevel nach Provider geführt). Zum "Connected_to_111.111.11.111_but_connection_died" habe ich habe keinen weiteren Ansatzpunkt. Einzige Feststellung die ich machen konnte ist, dass bei manuell Zustellung (per telnet) die verbindung sehr schnell wegen Timeouts getrennt wird, wenn man nicht schnell genug ist. Aber das sollte bei automatischer Bearbeitung wohl nicht das Problem sein.

Zeaq.

qmail queued ausgehende Mails ohne Fehlermeldung

New Member

Moderator

New Member

Moderator

New Member

New Member

New Member

Moderator

New Member

Registered User

Moderator

New Member

New Member

Moderator

New Member

Active Member

Moderator

New Member

Moderator

New Member

We value your privacy