Problem s dorucovanim posty

[Dan Lukes]

Vladimir Rengevic wrote:
> 
> Pekny den ;o)
> 
> > Vladimir Rengevic wrote:
> >
> > > mam problem z dorucovanim posty z jedneho servera. V logu sa mi objavia hlasky:
> > > *********
> > > g0VCQEe24891: collect: premature EOM: Error 0
> > > g0VCQEe24891: collect: unexpected close on connection from [195.28.85.118], sender=<xxx na intrel.sk>: Error 0
> >
> > > no a vzdialeny server sa sprava asi tak, ze zacne mail odosielat, ale proces sa nachadza v stave "wait". No a po case
> > > sa spojenie zrusi a skusa to znova. A na X-ty pokus sa mu to dorucit podari.
> > > Prosim, poradte ako zistit na ces strane je chyba? Ci u mna alebo u servera, ktory postu odosiela?
> >
> > Zaklad je podivat se na stav sendmail-procesu pomoci ps. Z vaseho
> > dotazu soudim, ze mate UNIX a protoze jste to nenapsal a ani nenapsal
> > jaky, soudim, ze mate Linux (OS neudavaji zasadne uzivatele Windows a
> > mezi UNIOXari uzivatele LINUXu - to je podobne, jako ze Prazaci zasadne
> > u telef. cisla nerikaji volacku) - v tom pripade nejspis prikazem 'ps
> 
> No kedze Linuxova konferencia tak samozrejme Linux, na ten wait som dosiel

	Ja prispevky ctu a sve prispevku posilam do Newsove konference
cz.comp.mail.sendmail a z toto se na Linux nic moc usuzovat neda. A ani
z jinych dokumentu jsem nezjistil, ze by konference mela byt zamerena
pouze na problemy sendmailu na Linuxu - to bych ji totiz nejspis necetl,
protoze by mi nemela byt k cemu.

	Doufam, ze veskere vase presvedceni o zamerenosti teto konference na
Linuxove problemu s postou neplynou z toho, ze existuje jako
<neco>@linux.cz. Nevim, jak v novodobem Internetu, ale jeste pred par
lety by si nikdo netroufl z neceho takoveho usuzovat, ze konference je
omezena na Linux (tak jako konference pravo-l na kolej.mff.cuni.cz neni
urcena pouze ani predevsim k tem pravnim otazkam, ktere se tykaji
ubytovani na koleji). Nebyvalo automaticke napln konference odvozovat od
OS systemu, na kterem konference bezi ...

	Nicmene, to jsem odbocil. Zpet k vasemu problemu.

> s "ps ax" a vyzera to konkretne takto:
...
> 13999 ?        S      0:01 sendmail: ./g1570me13999 mail@[195.28.85.118]: DATA
> 14005 ?        S      0:00 sendmail: server mail@[195.28.85.118] child wait
...

	Toho jsem se obaval. Z toho se skutecne neda rozeznat nic.

> > -ef'. Soucasne je rozumne na strane odesilaci spustit 'sendmail -qR -v'

> Tak toto sa mi nepodari ;o( - na ten server dosah nemam...

	Tak o to spusteni pozadate toho, kdo tam pristup ma. Nebo on nema zajem
na vyreseni tohoto problemu ?
 
>> pak bude nutny 'tcpdump -s 1600 port 25' - z toho uz bude zcela jasne na
>> jake urovni je vlastne problem.
> Uz bezi, zatial ziaden paket.... uvidime za chvilu

	Tak je spusteny spatne nebo pozde. Do faze "DATA" se prijimaci sendmail
nemohl v zadnem pripade dostat bez vymeny paketu.

> > Takovy problem se obcas vyskytje pokud sendmail na strane prijemce ma
> > chybne nakonfigurovane pouziti TLS - tedy pokud avizuje schopnost TLS,

> No vsetko ohladom TLS zo sendmail.cf (ale vecer nazriem do manualu):

	Kdybyste nemlvil o "nejakem" serveru, pak bych vam mohl rict, jestli je
problem v tomto sam, takhle se opravdu musite podivat do manualu. A
pokud nemate explicitni duvod proc mit TLS zapnute, pak bude mozna
rozumne, abyste zvazil jeho naproste vypnuti - prinejmensim dokud budete
ladit problemy.

> Este ma napadla jedna vec - nemam korektny reverz (ale vyzera, ze po roku a cosi sa to provaiderovi
> podarilo vybavit a je to uz vraj len otazka hodin ;o)) - ale nemoze byt pricinou aj nieco podobne?

	Teoreticky muze, prakticky by k tomu z tohoto duvodu doslo zrejme
daleko drive a ne az v "DATA" fazi.

	Za vasi situace opravdu zrejme nezbyva nez tcpdump, nejlepe s '-X'
optionem (alespon na strane serveru, kdyz na odesilaci stranu nemate
pristup). To by melo prostor problemu zasadne omezit.

									Dan



-- 
Dan Lukes      tel: +420 2 21914205, fax: +420 2 21914206
root  of FIONet,  KolejNET,  webmaster  of www.freebsd.cz
AKA: dan na obluda.cz, dan na freebsd.cz, dan na kolej.mff.cuni.cz