Zarafa & Spamdyke: " qmail-smtpd exited by timeout, reset connection or..."

[Cepe]

Hi nochmal,

habe erneut ein Problem mit Spamdyke und hoffe ihr könnt mir weiterhelfen.

Ich habe Spamdyke heute nachmittag auf 'nem CentOS 5.1 Server mit Plesk 8.3 installiert und alles lief auch einwandfrei.
Ganz plötzlich (ohne dass ich etwas geändert habe) kann ich keine Emails mehr verschicken.
In den Maillogs steht:

Jan  4 20:56:53 meinserver relaylock: /var/qmail/bin/relaylock: mail from 127.0.0.1:47960 (localhost)
Jan  4 20:56:58 meinserver spamdyke[6468]: ALLOWED from: meine@emailadresse.de to: alternative_email@gmx.de origin_ip: 127.0.0.1 origin_rdns: localhost auth: (unknown)
Jan  4 20:56:58 meinserver qmail-queue-handlers[6473]: Handlers Filter before-queue for qmail started ...
Jan  4 20:56:58 meinserver qmail-queue-handlers[6473]: possible qmail-smtpd exited by timeout, reset connection or with "See http://pobox.com/~djb/docs/smtplf.html."

Durch die Forensuche habe und den Link im Log habe ich erfahren, dass dies darauf zurückzuführen sei, dass mein Emailprogramm die Emails falsch übermittelt.

Wenn ich jedoch den qmail-aufruf in der /etc/xinet.d/stmp_psa Datei entferne, funktioniert es.

Die Lösungsvorschläge in diesem Thread (Kopieren der qmail.origin nach qmail.orig) funktioniert ebenfalls nicht.

Ein test mit telnet, ausgeführt direkt auf dem Server, ergibt folgendes:

[root@server ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
220 meinserver.de ESMTP
HELO someone
250 meinserver.de
MAIL FROM: existierende_emailadresse@meinserver.de
250 Refused. You are not following the SMTP protocol.
RCPT TO: meine_alternative_emailadresse@gmx.de
554 Refused. You are not following the SMTP protocol.
QUIT
221 Refused. You are not following the SMTP protocol.
Connection closed by foreign host.

In einem anderen Thread habe ich gelesen, dass dies die Graylist-Meldung von Spamdyke ist.
Nach dieser Telnet-Session steht in den logfiles folgender Eintrag:

Jan  4 20:55:39 meinserver.de relaylock: /var/qmail/bin/relaylock: mail from 127.0.0.1:47959 (localhost)
Jan  4 20:56:03 meinserver.de spamdyke[6437]: DENIED_EARLYTALKER from: meine@emailadresse.de to: alternative_email@gmx.de origin_ip: 127.0.0.1 origin_rdns: localhost auth: (unknown)

5 Minuten später hat das Verschicken einer Email mit telnet dann funktioniert.

Was ich nicht verstehe ist: Wieso werden ausgehende Emails auf die Greylist gesetzt? Kann man dies abschalten?

Ich muss noch dazu sagen, dass ich bei mir auch zarafa installiert habe. Das Verschicken von Emails über den Horde Webmailer oder über Outlook/Pop3 funktioniert. Nur das Verschicken von Emails über Zarafa (zarafa webmailer und zarafa+outlook) funktioniert nicht.
Bin jetzt schon seit 'ner Stunde am rumfummeln, aber es sieht doch stark danach aus, dass zarafa das smtp Protokoll schlecht implementiert hat. Anderseits funktioniert es ja ohne spamdyke.

Naja, vielleicht hat hier ja jemand 'ne Idee, was es noch sein könnte.

PS: Gibt es eine Möglichkeit, Bytegenau zu loggen, was der SMTP-Server für Nachrichten erhält? Damit könnte ich gucken, ob die Emails richtig formatiert mit CR LF [dot] CR LF ankommen

 

[Cepe]

Okay, nach 'ner Stunde Spamdyke Manual lesen, Googlen und Foren lesen, bin ich immer noch nicht wirklich weiter.

Das telnet-Beispiel und der Log-Eintrag des DENIED_EARLYTALKER hat nichts mit dem anderen Problem zu tun und kann ignoriert werden.


Ich habe mal full-log-dir in der spamdyke.conf gesetzt und hier ist der SMTP-Log:

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 34 bytes
220 meinserver.de ESMTP

01/04/2009 22:26:53 FROM REMOTE TO CHILD: 29 bytes
EHLO meinserver.de

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 28 bytes
250-meinserver.de

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 14 bytes
250-STARTTLS

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 16 bytes
250-PIPELINING

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 14 bytes
250-8BITMIME

01/04/2009 22:26:53 FROM SPAMDYKE TO REMOTE: 3 bytes
250
01/04/2009 22:26:53 FROM SPAMDYKE TO REMOTE: 1 bytes

01/04/2009 22:26:53 FROM SPAMDYKE TO REMOTE: 27 bytes
AUTH LOGIN PLAIN CRAM-MD5

01/04/2009 22:26:53 FROM REMOTE TO CHILD: 39 bytes
MAIL FROM: <meineEmail@meinserver.de>

01/04/2009 22:26:53 LOG OUTPUT
DEBUG(filter_sender_whitelist()@filter.c:1747): searching sender whitelist(s); sender: meineEmail@meinserver.de
DEBUG(filter_sender_blacklist()@filter.c:1881): searching sender blacklist(s); sender: meineEmail@meinserver.de

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 8 bytes
250 ok

01/04/2009 22:26:53 FROM REMOTE TO CHILD: 29 bytes
RCPT TO: <meine_GMX_Adresse@gmx.de>

01/04/2009 22:26:53 LOG OUTPUT
DEBUG(filter_recipient_relay()@filter.c:2183): checking relaying; relay-level: 0 recipient: meine_GMX_Adresse@gmx.de ip: 127.0.0.1 rdns: localhost local_recipient: false relaying_allowed: true
DEBUG(filter_recipient_local()@filter.c:2154): checking for unqualified recipient; recipient: meine_GMX_Adresse@gmx.de
DEBUG(filter_recipient_blacklist()@filter.c:2278): searching recipient blacklist(s); recipient: meine_GMX_Adresse@gmx.de
DEBUG(filter_recipient_graylist()@filter.c:2342): checking graylist; recipient: meine_GMX_Adresse@gmx.de sender: meineEmail@meinserver.de

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 8 bytes
250 ok

01/04/2009 22:26:53 LOG OUTPUT
ALLOWED from: meineEmail@meinserver.de to: meine_GMX_Adresse@gmx.de origin_ip: 127.0.0.1 origin_rdns: localhost auth: (unknown)

[B]01/04/2009 22:26:53 FROM REMOTE TO CHILD: 6 bytes
DATA

01/04/2009 22:26:53 FROM CHILD TO REMOTE: 14 bytes
354 go ahead

01/04/2009 22:26:53 FROM REMOTE TO CHILD: 6 bytes
QUIT

01/04/2009 22:26:53 CLOSED[/B]

Die Verbindung wird vom Mail Programm (zarafa) beendet, ohne daten zu senden, obwohl alles gut aussieht. Oder loggt spamdyke die Daten nicht mit?

In den Zarafa Logs erkennt man folgende Meldung:

 SMTP: Error while executing command 'DATA'. Response: 250 ok

//EDIT: Weiter geht's

Habe gerade folgende sehr interessante Passage gefunden:

spamdyke does modify the incoming message in one way. The SMTP protocol requires the remote sender to end every line with a two character terminator -- a carriage return and a line feed. Unlike most other mail servers, qmail chooses to strictly enforce this requirement. If a remote sender uses only a line feed to end a line (a typical and easy mistake to make), qmail will reject the message:

451 See http://pobox.com/~djb/docs/smtplf.html.

Because qmail's strict enforcement of the protocol tends to cause more problems than it solves, spamdyke silently helps mail clients avoid this error by inserting a carriage return before any bare line feed characters it sees. This doesn't affect the messages, it only allows poorly-written mail clients to send email.

Eigentlich kann der Fehler nur daran liegen.
Denn ohne spamdyke funktioniert es ja, und dies ist die einzige Modifikation, die Spamdyke an den SMTP-Daten vornimmt.

 

[Cepe]

Yuhuh, Problemursache gefunden

Qmail sendet nach dem EHLO-Befehle eine Antwort bestehend aus mehreren Zeilen.
Spamdyke hingegen schickt mehrere einzeilige Antworten an den Clienten zurück, womit mein Mailclient nicht zurecht kommt....

 

[ermaweb]

Hallo,

könnten Sie beschreiben, wie Sie das Problem gelöst haben. Ich habe nämlich auch das gleiche Problem.

Grüße Ermaweb

 

[ermaweb]

Weis keiner eine Antwort?

 

[Cepe]

Hi,

ich habe das Problem nicht gelöst, sondern nur herausgefunden, woran es liegt

Kurz gesagt liegt es daran, dass zarafa eine veraltete Version der libvmime Bibliothek verwendet, welche einen Bug hat und daher inkomatibel zu Spamdyke ist.

Allerdings hat zarafa in der vor drei Tagen veröffentlichen 6.20.6 Version auf eine aktuellere libvmime umgestellt (aber nicht auf die aktuellste), sodass der Bug eventuell behoben ist. (Habe es noch nicht getestet - in der aktuellen ist der Bug definitiv behoben)
Falls es mit der aktuellen Zarafa Version auch nicht klappt, bleibt nix anderes übrig, als abzuwarten, da zarafa schon angekündigt hat, auf die neuste libvmime Version umzustellen. Dies ist jedoch größerer Aufwand und wird noch was dauern...