- This topic has 7 hozzászólás, 5 résztvevő, and was last updated 18 years, 4 months telt el by
.
-
Bejegyzés
-
Csak pontosítanék, mivel azóta más IP címekkel is megtörtént.
A szerver pontosabban így azonosítja magát:
220 **********************************2*******2****************200************0200
Ha betelnetelek, akkor problémamentesen megy a kommunikáció. Akkor a qmail-ből miért nem?
Hát, csak ennyi … hátha valakinek mégis csak lenne valami ötlete …linuxforum wrote:Csak pontosítanék, mivel azóta más IP címekkel is megtörtént.
A szerver pontosabban így azonosítja magát:
220 **********************************2*******2****************200************0200
Ha betelnetelek, akkor problémamentesen megy a kommunikáció. Akkor a qmail-ből miért nem?
Hát, csak ennyi … hátha valakinek mégis csak lenne valami ötlete …Qmail lecserélése esetleg frissítése, downgradelése?
Ha telnettel megy, akkor a qmail a ludas szerintem.
Vagy próbáld másik levelezövel vagy ahogy már említettem, talán másik verzióval…Nem nagyon van frissebb verzió, mint az 1.03-as. Ezt nem szokták frissítgetni, mert nem szoktak benne hibák lenni. … Ezért is furcsállom a dolgot. egy ilyen alapvető hiba már megjelent volna a bug listákon.
De a kernel sem lehet az oka, mert akkor telnettel sem menne …
Egyébként nem akarom lecserélni, mert az a hír járja, hogy ez a legmegbízhatóbb mail szerver betörés tekintetében.
Tehát az egyetlen járható út, ha kiderítem a hiba okát…Akkor passz, sorry.
Annó én is kerestem valami megbízhatóbb mail szervert, szerencsére egyelöre csak megismerés céljából, de pont az ilyen és hasonló hibák miatt és a nem debian disztróra való bonyultabb telepítés miatt nem a qmail mellett döntöttem.De azért sok sikert kívánok neked a kiderítéshez, bár ezzel tudom nem sokra mész…
a google kiadott egy ilyen fórumot is a találatok közt, esetleg megnézheted…
http://forum.qmailrocks.org/Egyébként nem akarom lecserélni, mert az a hír járja, hogy ez a legmegbízhatóbb mail szerver betörés tekintetében.
Ja, csak nem műxik! 😉
A lényeg hogy biztonságos! ;D ;D ;DHa kikapcsolom a gépem, akkor biztonságos az oprendszer?! ::)
linuxforum wrote:Qmail küld egy EHLO-t, amire a válasz „unknow command”.
…
Vagy valami tűzfal, valahol útközben, vagy …
Azt hiszem, ez a megoldás. Nem a qmail igazán a hunyó. Legalább is nekem ez volt a múlt héten, amikor szívtam, mint a torkosborz!
Abban a szerencsés helyzetben voltam, hogy a teljes környezet a közelben volt, bárhol mérhettem. A küldö oldalon máshogy nézett ki ethereal-lal a csomagsorozat, mint a fogadó oldalon.Elküldtem az EHLO-t és a szerver ehelyett XXXX-et kapott, ami unknown ugyebár. Oka a tüzfalban levö (itt Cisco PIX, de sokan csinálják) content filtering („mailguard”), ami be volt kapcsolva. Ha nem megengedett parancsot észlel, kiikszeli… A probléma, hogy RFC 821 szerint filtrál… 🙁 Abban meg nincs EHLO még, az az esmtp-vel jött be, aktuálisan az RFC 2821 (Ha jól emlékszem). Ha viszont az „SMTP”-ben akarsz authentifikációt, akkor esmtp kell…
Próbálj utánanézni, hol lehet a tüzfalféleség.
Utólag hozzáírom:
a picipuha is foglalkozik a témával: http://support.microsoft.com/kb/895857 , mert nekik is gond. (egyébként szerintem jogosan: manapság az RFC 821-hez tartani valakinek magát – anakronizmus ???)Úgy néz ki, meg van a hiba. Legalábbis kb.
Az eredeti qmail rpm-ből lett telepítve. Most lefordítottam forrásból újra, SSL támogatás nélkül. (Nem tudom, az eredetiben volt-e, de a fentiek alapján azt gyanítom, hogy igen.)
Most minden jól működik.
gendelider-nek igaza lehet, útközben – talán a célállomás körül – lehetnek ilyen korlátozó tűzfalak. A qmail pedig először SSL-lel próbált meg küldeni, ami elakadhatott …
Nem tudom, ha lesz időm, ezt azért még kitesztelem. Egyelőre azonban nincs SSL, csak prosztó SMTP. Mint telnetnél, most már minden tutira működik.
Köszönet a segítségért. Ha pontosabban be tudom határolni a probléma okát, azért még ideírom.Qmail-lel szeretnék levelet küldeni egy adott címre, de amint elküldöm a levelet, a qmail-remote 99.9%-kal elkezdi zabálni a CPU-t, és 1200 (control/timeoutremote) másodpercig abba sem hagyja. Semmi más tevékenység nem nő meg.
A címzett: dwoxonm@oxon.it
A tcpdump szerint a következő történik:
A qmail küld egy Syn-ct a 89.96.236.15 : 25-ös portjára, erre válaszként jön egy Ack.
Qmail küld egy EHLO-t, amire a válasz „unknow command”.
Ekkor küld egy HELO-t a qmail, amire 220 ************************** a válasz, de ez a csomag már megszakad. (Az egy külön kör, hogy hogyan érkezhet meg egy ilyen pici félcsomag, de ez már TCP probléma, és ez talán külön kiokosodást érdemelne.)
A qmail erre elkezd egy bitsor küldeni kifelé, amire több hibaleírásban rátaláltam a neten, de ezek általában TSL kommunikációk hibaleírásai voltak. Mivel mindez 25-ös porton megy, nem hiszem, hogy titkosítottan akarna adatot küldeni. De talán ez sem túl fontos, hisz ez az utolsó érdemi csomag, amit a qmail eküld. Ez megszakad. … És ennyi.
Néha még a távoli szerver ismét küld egy nyugtázást a HELO-ra, de az egész adatforgalom összesen csak párszáz bájt.
De mit csinál a qmail ennyi ideig a procival? És miért?
Tesztből ugyanerre a címre küldtem a freemail-ből is levelet, az pillanatok alatt megfordult, mivel a címzett ismeretlen. Pedig a freemail is qmail.
???
Teljesen tanácstalan vagyok!
A collectd tesztprogram azt mutatja, hogy a processzor 90%-a használatban, és kb 30-40% ebből system használat. Már az is érdekes, hogy ha a top szerint 99%, az uptime szerint messze 1 fölött van az érték, akkor a collection miért csak 80-90%-os terheltséget mutat.
De a lényeg mégis az: mit és miért csinálja ezt a qmail? Miért csak nagyon ritkán? (Talán a másik oldali szerver … ezt a kérdést nem is tudom befejezni. Vagy valami tűzfal, valahol útközben, vagy … A csomagok mindkét szerver ablakméretén belül vannak. Legalábbis én így látom. Igaz, a két ablakméret nem egyforma.)
Miért szakadnak meg a qmail fogadott és küldött csomagjai, és hogyan tudom pontosítani a hibát?
???
Minden ötletnek előre is örülök!
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz