plesk 8.4, qmail timedout receiving initial server greeting

E

eciatasa

New Member
Hallo,

ich habe ein Problem mit qmail:
Aus manchen Netzen wie z.B. Arcor und T-Online verzögert sich die initial server greeting. Ein Telnet auf Port 25 braucht ca. 35 Sekunden, bis die 220-Greeting kommt.
Dies wird zum Problem, da einige sendende Mailserver da schon in einen timeout laufen.
Aus vielen anderen Netzen kommen die emails einwandfrei an, ein Telnet von einem PC (Windows, Linux & Mac OSX) aus z.B. dem Netz der UnityMedia empfängt die 220-Greeting sofort.
tcpdump zeigt keine Auffälligkeiten, nur eben eine lange Zeit ohne Datenverkehr.
Ein weiterer Server im gleichen Netz von Strato hat keinerlei derartige Probleme, weshalb ich ein Routingproblem erst mal für unwahrscheinlich halte.

Konfiguration:
strato server, 2.6.18-6-686, Plesk 8.3, qmail mit spamdyke.
Spamdyke würde ich mal als Problem ausschliessen, da auch wenn ich es abschalte das Problem genauso besteht.
Was mir aufgefallen ist, ist dass inetd UND xinetd beide laufen. Ich kann nicht sagen, warum; wahrscheinlich hat Plesk da irgendetwas herumgepfuscht.

Für Denkanstöße wäre ich dankbar!

Schönen Gruß
Bernd
 
Hi, interessante Sache das. Allerdings setze ich (wissentlich) keine derartige Technik ein. Selbst mit Spamdyke nicht, abgesehen davon passiert es auch, wenn Spamdyke komplett deaktiviert ist.
Ist Plesk qmail evtl. schon tarpit patched?
Aber selbst wenn, sollten keine Delays > 30 Sekunden auftauchen.
 
Last edited by a moderator:
Miß spaßenshalber mal die Zeit einer DNS-Abfrage (Port 53/UDP).
Die Massenprovider gehen derzeit immer mehr zum transparenten Filtern über...
 
das Thema DNS lokkup hab ich auch schon in Betracht gezogen und mal die IP von einem testsystem in die hosts gesetzt. Selbes Spiel ....
Acuh ein nslookup geht von Hand sehr fix.
 
... was mir auch aufgefallen ist, sind viele lookups dieser Adresse:
rns30.rl.b.rz-ip.net
Und das, obwohl alle RBL Checks ausgeschaltet sind ...

1255342328.147316 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 63) h1399710.stratoserver.net.32813 > rns30.rl.b.rz-ip.net.domain: [bad udp cksum a578!] 31041+ CNAME? redesdalearms.com. (35)
1255342328.225085 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: UDP (17), length: 120) rns30.rl.b.rz-ip.net.domain > h1399710.stratoserver.net.32813: 31041 q: CNAME? redesdalearms.com. 0/1/0 ns: redesdalearms.com. SOA[|domain]
1255342328.225092 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: UDP (17), length: 79) rns30.rl.b.rz-ip.net.domain > h1399710.stratoserver.net.32813: [udp sum ok] 30785 q: A? redesdalearms.com. 1/0/0 redesdalearms.com. A newwww1.queensboroughgroup.co.uk (51)
1255342328.226763 IP (tos 0x0, ttl 64, id 4326, offset 0, flags [DF], proto: UDP (17), length: 73) h1399710.stratoserver.net.32814 > rns30.rl.b.rz-ip.net.domain: [bad udp cksum dd05!] 46127+ PTR? 185.225.148.82.in-addr.arpa. (45)
1255342328.285801 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: UDP (17), length: 121) rns30.rl.b.rz-ip.net.domain > h1399710.stratoserver.net.32813: 30529 q: MX? redesdalearms.com. 1/0/1 redesdalearms.com. MX[|domain]
1255342328.342895 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto: UDP (17), length: 119) rns30.rl.b.rz-ip.net.domain > h1399710.stratoserver.net.32814: 46127 q: PTR? 185.225.148.82.in-addr.arpa. 1/0/0 185.225.148.82.in-addr.arpa. (91)
 
so, über port 587 passiert das Selbe.
Die Listung bei backscatterer.org habe ich schon vernommen, leider kann ich qmail nicht abgewöhnen, manche mails erst nach Bearbeitung "zurückzuplappern"... hab schon bei huschi so ziemlich alles gelesen, aber nichts brachte da Abhilfe.
Die Blockung/Verzögerung bei T-Online kenne ich, aber da bin ich fast sicher, dass es damit nicht zusammenhängt, da ein anderer Server bei Strato im selben Segment (allerdings mit Postfix statt qmail) sofort antwortet.
 
Last edited by a moderator:
gelöst.

http://kb.parallels.com/en/298

Das war das Problem. Lustigerweise kam ich da nicht drauf, weil Plesk den Parameter (nachdem ich in eingebaut hatte) selbständig wieder rausgenommen hat. Danke Parallels ..... mal sehen, wie lange er jetzt drinbleibt.

Danke für die Unterstützung.
 
You must log in or register to reply here.
Back
Top