Greylisting, qmail 1.0.3, plesk 8.2.1 (oder 8.3), suse 10.1 und authentifizierte User

L

LeoSaf

New Member
Hallo,

Ich habe die allseits bekannte Anleitung benutzt:
Plesk & Qmail: Spamprotection mit Greylisting - huschi.net

Funktioniert an sich auch sehr gut...

Allerdings habe ich das Problem, daß ich selbst beim Absenden von E-Mails eine Verzögerung hinnehmen muß, die manchmal dazu führt, daß ich eine E-Mail 2 bis 3 mal abschicken muß bevor sie auch vom Server entgegen genommen wird.

Wie kann ich denn authentifizierte Nutzer direkt durchlassen? An der IP kann ich das ja nicht machen, da die Nutzer (es gibt ja mehr als nur ich ;-)) immer wieder neue IPs haben.

In den Logs habe ich dann solche Angaben:
Dec 29 19:37:41 s15219740 relaylock: /var/qmail/bin/relaylock: mail from 131.246.xxx.xxx:39906 (mailgw1.xxx-kl.de)

Die IP ist die des Nutzers, der ja eigentlich berechtigter Weise E-Mails schicken darf.

Würde mich freuen, wenn jemand mir eine Tipp geben könnte :)


Grüßle,

LeoSaf
 
Last edited by a moderator:
Gleiches Problem hab ich hier bei Debian ETCH.

In der greylist_dbg.txt steht jedoch kein Eintrag dazu.

Unter /opt/psa/var/log/maiillog steht nur:
Code: 
Dec 31 14:10:41 HOSTNAME relaylock: /var/qmail/bin/relaylock: mail from 62.178.xxx.xxx:15520
Ich vermute fast eher das es hier irgendeinen Konflikt mit der Qmail Version von Plesk 8.3 und dem Greylist gibt, wirklichen Ansatz hab ich jedoch leider auch keinen :/
 
Seltsam, nach einem neuerlichen QMail restart gehts wieder normal und lässt sich auch nicht mehr reproduzieren. Habe nur zuvor QMail schon x-mal neugestartet ohne Besserung. Naja ich werds mal im Auge behalten.
 
Hallo,

Ich habe mal alles wieder gründlicher untersucht... tatsächlich scheint es kein direkt mit Greylisting verbundenes Problem zu sein. Wahrscheinlich verursacht allerdings die neu kompilierte smtpd Datei mein Problem.

Um Huschi zu beantworten: in der greylist.txt steht nichts (bim Verbindungsaufbau). Das hat mich ja stutzig gemacht... Und der Eintrag in /var/log/messages bzgl. relaylock, ist ja ein normaler qmail Eintrag (wie ich feststellen sollte).

Ich habe den Mailversand von Thunderbird und der Einstellung "TLS, wenn möglich" mit Wireshark überwacht. Außer, daß Thunderbird nach einer gewissen Inaktivität einen RST Paket an den Server schickt, konnte ich nichts anormales feststellen. Die Kommunikation ist ja ab dem Start TLS verschlüsselt.

Auch ohne Verschlüsselung konnte ich nichts anormales entdecken. Es dauert einfach nur ewig. Nach dem Response des Mailsservers mit "220 <Name des Mailservers> ESMTP", kommt nix mehr und Thunderbird meldet einen Timeout (nicht immer), manchmal wird ja die Mail "nur" nach 20 Sekunden Verzögerung verschickt.


Frohes neues Jahr an alle!!!!
 
Last edited by a moderator:
Hallo,

Ich glaube ich gebe es auf.. wenn ich Mails mit Outlook (2003) verschicke, klappt es einwandfrei. Das Problem habe ich also mit Thunderbird (aktuelle Version).

Ich verstehe nur Bahnhof. Ich benutze TB seit nunmehr 2 Jahren...

Seltsam...
 
Das hört sich ziemlich nach einem Problem an, dass ich auch erst vor wenigen Wochen lösen konnte: Qmail in neueren Pleskversionen (bei meinem alten Server mit 7.5 war das nicht so) sendet beim Empfang über SMTP eine Ident-Abfrage an die absendene IP (Ident ist ein Protokoll um auf früheren Unix-Multiuser-Systemen herauszubekommen, von welchem User die Mail stammt oder irgendsowas derartiges). Da in Zeiten von NAT-Routern Abfragen aus dem Netz einfach verworfen werden, wartet der Qmail-Prozess 30sec auf eine Antwort, bis er dann nach dem Timeout aufgibt und die Mail annimmt. In Outlook funktioniert das soweit ganz gut (es dauert aber halt 30sec, bis die Mail angenommen ist), in Thunderbird dagegen ist das Timeout wohl standardmäßig bei genau 30sec, so dass es bei mir mit TB mal klappt und mal nicht.

Abhilfe schafft:
  • Einfügen des Parameter -Rt0 in die xinetd.conf an den smtp / smtps: Dies soll genau das Problem beheben, da ich in einem Forum aber von einem User gelesen hab, der dann irgendwie keine Mails mehr versenden konnte, hab ich das dann gelassen. Der Parameter scheint eh etwas schlecht dokumentiert zu sein.
  • Blockieren ausgehender Ident-Abfragen über eine Iptables-Rule: Wichtig eben, dass das Paket nicht gedroppt wird, sondern rejected (denn dann wird die Verbindung gleich beendet und Qmail hört damit auf). Das ist zwar mehr Bekämpfung der Symptome, als der Ursache, aber das läuft bei mir absolut problemlos und da Ident ja eh nicht mehr genutzt wird, sollte es auch nicht tragisch sein, wenn der Server keine Abfragen mehr senden darf. Das geht mit der Rule "iptables -I OUTPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset"
Ich denke mal, das liegt ehr dadran - hat mit Greylisting gar nix zu tun.
 
Danke für Deine Antwort. Allerdings ist es nun so, daß -Rt0 bereits in dem Config File steht und das Problem vor dem Installieren des greylisting Patches nicht existierte. Ident Port habe ich zu keinem Zeitpunkt gesperrt/entsperrt.

Ich kann es mal probieren, dennoch mach ich mir keine großen Hoffnung :(
 
LeoSaf said:
Nach dem Response des Mailsservers mit "220 <Name des Mailservers> ESMTP", kommt nix mehr
Click to expand...
Nach einem "EHLO" sollte vom Qmail noch ein paar Zeilen mehr kommen. Egal ob TLS oder nicht, denn zu dem Zeitpunkt ist der Handshake noch nicht vollzogen.

StephenKing said:
Parameter -Rt0 [,,,]
Der Parameter scheint eh etwas schlecht dokumentiert zu sein.
Click to expand...
Nicht wirklich wenn man weiß, daß es eigentlich zwei Parameter sind:
-R: Keine Reverse-Auflösung.
-t0: Timeout für Reverse-Auflösung auf 0 setzten.
Es ist also eine doppelt gemoppelte Lösung und rein theoretisch funktioniert jeder Parameter für sich allein genauso...

PS: Ident ist ungleich Reverse-Auflösung...

Der Ident von Qmail wird an den localhost geschickt. Aus irgendeinem Grund meinte der Qmail-Autor, daß Qmail sich jedesmal selbst per DNS-Anfrage seinen Hostname holen soll (statt wie alle anderen Programme einfach die hostname-Funktion vom System zu nutzen).
Sehr problematisch bei zerschossenen DNS-Konfiguration.
Bei wem ein "ping gmx.de" nicht funktioniert, hat daher zwangsweise auch mit Qmail ein Problem.

huschi.
 
Hallo,

Nun, ich habe nochmal einen Log erstellt (Wireshark). Dazu habe ich zunächst mein Mailkonto auf "Niemals verschlüsseln" eingerichtet (um möglichst viel zu sehen).

Leider haben sich trotz einiger Vorkehrungen ein paar andere Pakete im Log eingemischt. Diese habe ich gelöscht - also nicht wundern, wenn die Paketreihenfolge Lücken hat.

Wie man unschwer erkennen kann, ist es so, daß die Verbindung via TCP (Handshake) stattfindet. Aber nachdem der Server das erste SMTP Paket schickt (Response: 220 s15437330.online-server.info ESMTP) sendet der Client ein weiteres TCP Paket anstatt ein SMTP Paket mit EHLO blablablah.

Anbei das Dokument... wenn jemand dazu eine Idee hat...
 

Attachments

LeoSaf said:
sendet der Client ein weiteres TCP Paket
Click to expand...
Das ist lediglich der üblich ACK um über die Ankunft des Paketes zu berichten.
Warum der Client sich mit dem Empfangenen Paket nicht zufrieden stellt, weiß ich nicht.

Ein kleiner Test per Telnet sagt mir aber, daß bei Dir gerade auch kein SMTP-Server am lauschen ist.

huschi.
 
Hallo,

Ich habe in dem Logauschnitt nicht meine IP eingetragen... also kein Wunder, daß da kein Mailserver horcht :)

Ich glaube ich werde am WE mal diese debugging Funktion für qmail einkompilieren und mal schauen, ob sich so zusätzliche Informationen gewinnen lassen.

Jedenfalls vielen Dank für Deine Mühe :)
 
Hallo,

Die Download-URL auf Plesk/Qmail: Qmail selber kompilieren - huschi.net zu den SwSoft Patches funktioniert leider nicht mehr. Zu finden sind nun Patches auf KB #1161 - Plesk 8 uses patched Qmail. How do I compile Qmail with my own patches?.

Es gibt dort eine Version für Plesk 8.2 und eine für Plesk 8.3. Ich habe die für 8.2 genommen.

Zum einen, für diejenigen, die ein Standardsystem haben: patch muss installiert werden. Einfach per Yast für Suse oder yum für Fedora... wie auch immer:)

Ich habe die Befehle ausgeführt:
for p in ../qmail_patches/patch-* ; do patch -p0 < $p ; done
patch -p0 < ../qmail_patches/fr49-quota-patch

wget http://www.qmail.org/qmailqueue-patch
patch -p1 < qmailqueue-patch

Nur hier hab ich probleme bekommen:
make WITH_QMAILQUEUE_PATCH=yes

Zunächst kam die Meldung:
Oops. Your system's FD_SET() has a hidden limit of 1024 descriptors.
This means that the qmail daemons could crash if you set the run-time
concurrency higher than 509. So I'm going to insist that the concurrency
limit in conf-spawn be at most 509. Right now it's 1000.
make: *** [spawn.o] Error 1

Also habe ich den Wert in conf-spawn auf 508 gesetzt.

Dann make clean und nochmal:
make WITH_QMAILQUEUE_PATCH=yes

Jetzt bekomme ich folgenden Fehler:
make: *** [auto_uids.c] Error 100

Hier die letzten Zeilen vor dem Fehler:

./compile prot.c
./compile coe.c
./compile cdb_hash.c
./compile cdb_unpack.c
./compile cdb_seek.c
./makelib cdb.a cdb_hash.o cdb_unpack.o cdb_seek.o
./compile auto-uid.c
auto-uid.c: In function âmainâ:
auto-uid.c:21: warning: return type of âmainâ is not âintâ
./load auto-uid substdio.a error.a str.a fs.a
./compile auto-gid.c
auto-gid.c: In function âmainâ:
auto-gid.c:21: warning: return type of âmainâ is not âintâ
./load auto-gid substdio.a error.a str.a fs.a
( ./auto-uid auto_uida `head -1 conf-users` \
&&./auto-uid auto_uidd `head -2 conf-users | tail -1` \
&&./auto-uid auto_uidl `head -3 conf-users | tail -1` \
&&./auto-uid auto_uido `head -4 conf-users | tail -1` \
&&./auto-uid auto_uidp `head -5 conf-users | tail -1` \
&&./auto-uid auto_uidq `head -6 conf-users | tail -1` \
&&./auto-uid auto_uidr `head -7 conf-users | tail -1` \
&&./auto-uid auto_uids `head -8 conf-users | tail -1` \
&&./auto-gid auto_gidq `head -1 conf-groups` \
&&./auto-gid auto_gidn `head -2 conf-groups | tail -1` \
) > auto_uids.c.tmp && mv auto_uids.c.tmp auto_uids.c
make: *** [auto_uids.c] Error 100

Dazu fällt mir momentan nichts ein... muß wohl googlen.. Wenn jemand was weiß, bitte sagen :)

Mein OS: SuSe 10.1 Dazu Plesk 8.2.1. Keine nennenswerte Modifikationen sonst.

Danke ;-)
 
Das liegt daran, daß im original Qmail die Dateien conf-groups und conf-users lediglich die Gruppen- und Usernamen enthalten.
Mit Plesk kommt ein Patch dazu, der dahinter noch die GID's und UID's erwartet.
(Siehe auto-gid.c und auto-uid.c)
Vergleiche es einfach mit dem vollständigen Qmail-Greylisting-Paket. Darin findest Du auch die richtigen conf-Dateien.

PS: Danke für den Link-Update.

huschi.
 
Ich habe auch einen VPS mit Plesk (inzwischen PLesk 8.3) den ich als Mail Backup nutze. Ich habe dort mein E-Mail Konto identisch eingerichtet und synchronisiere mit mailsync meine E-Mails stündlich.

Ich habe auf dem VPS ebenfalls Greylisting eingerichtet.

Nun ist es so, daß ich da mit Thunderbird KEINE Probleme beim Versenden von E-Mails habe.

Wenn ich von einem anderen Computer aus, mit Thunderbird auf beide Konten zugreife, ist die Verbindung beim Versenden (über ded. Server) immer noch verzögert, wenn auch bislang kein Timeout bekommen. Das Senden über den VPS läuft einwandfrei.

So viel dazu... ich schaue weiter mit dem Debugging...
 
Last edited by a moderator:
Nun, Debugging ist eingebaut...

Ergebnis:

Jan 12 16:01:00 <hostname> qmail-smtpd: smtp-auth[1081] ok for login: [email protected]

Hat ca. 25 Sekunden beim zweiten Versuch gedauert bis die Mail verschickt wurde. 1ster Versuch endete mit Timeout :(

Ich habe aber nun folgende Fehlermeldung in /var/log/messages:
Jan 12 16:08:53 <hostname> spamd[7890]: dns: sendto() failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm line 340, <GEN817> line 27.

Zumindest fällt sie mir erst jetzt auf... Wenn mit der Debugging-Funktion sonst nichts anzufangen ist, werde ich dann nachher wieder den alten Zustand wiederherstellen...

Hat jemand sonst noch eine Idee? Thx :)
 
Last edited by a moderator:
Immerhin ist der Fehler

Jan 12 16:08:53 <hostname> spamd[7890]: dns: sendto() failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm line 340, <GEN817> line 27.

wieder weg. Ich habe lediglich spamd (vom Plesk Interface aus) restartet.

Ich hatte kürzlich Probleme mit den nameserver aus /etc/resolv.conf. Dort hatte ich bereits neue NS eingetragen, aber spamd nicht neugestartet...

Der Fehler bzw. die Verzögerung mit Thunderbird ist aber immer nochvorhanden... :(
 
You must log in or register to reply here.
Back
Top