opakovany prijem emailu

[Dan Lukes]

Jakub Holcman wrote:

>   Nekolika uzivatelum na nasem hostingovem serveru
>   zacaly chodit nektere emaily opakovane. Jedna se vzdy
>   o jeden konkretni email, ktery (jak je patrno z logu) prichazi
>   na nas server korektne vzdy v rozmezi nekolika minut az hodin.
>   (Tj. Nekdo cizi posle email na adresu naseho uzivatele a ten
>   email chodi opakovane - po dobu mnoha dni s ruznym intervalem
>   minut az hodin - tj. prijde mnohokrat). Jedna se vzdy o ten samy
>   email se stejnym casem odeslani. Stalo se to u ruznych domen i
>   ruznych odesilatelu. Nicmene jine emaily (od toho sameho uzivatele
>   tomu samemu uzivateli) hodi korektne. Jedine co maji ty emaily
>   spolecneho - jsou vzdy s prilohou (tj. relativne velike).

>   Jeste nase konfigurace: Linux 2.2 (Suse), Qmail 1.03


	RFC821 (respektive, dnes uz asi spise RFC2821) ma v designu znamy
casovy hazard - prijimaci server obdrzi <CR><LF>.<CR><LF> jako zaver
data faze, comz povazuje e-mail za doruceny a odesle prislusnou odpoved.
Odesilaci klient vsak povazuje email za doruceny teprve prichodem teto
odpovedi. Pokud tedy dojde k rozpadu spojeni ci jine ztrate ci
prilisnemu zpozdeni teto odpovedi pak dochazi k tomu, ze prijimajici MTA
povazuje dopis za prijaty a zpracovava ho dal, kdezto odesilaci MTA ho
povazuje za neodeslany a za nejakou dobu jej posle znovu.

	Doporuceni pravi, ze odpoved na konec DATA faze ma byt odesilana
neprodlene a ocekavana po pomerne dlouhou doibu (nepamatuji si presne,
tusim 10 minut). Pokud prijimajici MTA hodla provades s dopisem neco, co
vyzaduje delsi zpracovani ma dopis prijmout a pokud se dodatecne
rozhodne, ze dopis odmita, vygeneruje chybove hlaseni ve vlastni rezii
(misto toho, aby dopis odmitlo v ramci SMTP renosu a chybove hlaseni
generoval odesilajici MTA).

	Pokud obe MTA nedodrzi doporuceni trochu, nebo jedno z nich hodne pak
se casovy hazard skutecne muze platnit s vami specifikovanymi projevy.
Jelikoz uvadite, ze vec se objevuje "per konkretni mail" soudim, ze by
to mohlo nejak souviset primo s obsahem a tedy zpracovanim na
prijimajici strane - pokud antivirova kontrola ci jine zpracovani
zpusobi zpozdeni odpovedi na zaver DATA faze - delsi, nez ktere je
ochoten odesilajici MTA snest, pak se stane presne to, co se vam deje.

	Protoze uvadite, ze se to deje pro ruzne dopisu (ja predpokladam, ze
tedy i zasilana ruznymi MTA) pak je potreba hledat chybu spise na vasi
nez na cizi strane. Ale to je v tuto chvili jen pracovni hypoteza.

	Pro jeji overeni potrebujete zdetekovat, ze nastala vami popsana
situace a pak (treba pomoci TCPDUMP) sledovat komunikaci s opakujicim
strojem a tim vysledovat jaka presne data byla v prubehu komunikace
predana i v jake casy - a podle toho pujde zjistit zda je teorie spravna
a prinejmensim pujde presne zjistit na ci strane je problem.

	Mozna by tato situace mohla jit i vyvolat - pokud mate k dispozici
alespon jeden nemodifikovany mail, jaky byl opakovane zasilan, muzete si
jej zkusit zaslat znovu, treba to situaci vyvola.

						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