"tato prasarna je pouze a jen problemem stroje/spravce, ktery jako posledni prede mnou prijal takovouto kravinu k doruceni, nikoli moje..."
opravil bych vas spise na: 'ktery jako posledni pred mnou chce poslat dal takovouto kravinu'. Ono neni uplne snadne odhadnout, jak ta priloha bude velka, pokud se klient nesmiluje a predem vam to neoznami (coz nekteri fakt nedelaji).
BTW: opravdu jsem narazel na moznost preplneni disku.
"proste pokud se SMTP relay s Vami prestane nekolikrat bavit a odpovi Vam korektni SMTP status kodem a Vy presto jako hluchej budete ty data k nam cpat i nadale, IDS zareaguje a na sitove urovni Vam da tipec."
Pokud uprostred prenaseni nejake obrovske prilohy server usoudi, ze to je fakt moc a prenos nejak utne, tak klient/server sice "korektni SMTP status kod" obrzi, vyhodnoti ho treba jako docasnou chybu a po par minutach zacne s odesilanim vesele znova. Pak tedy zareaguje IDS a vsechna komunikace z postovniho serveru jednoho duleziteho obchodniho partnera bude zahazovana :).
Pozn.: to ovsem plati i pro vas postovni server na vasi siti. Jak odmitate(*) MUA, kteri predem nedeklaruji velikost prilohy a jaky mate zhruba limit? (RFC garantuje AFAIK par kilobytu [tusim 5 kB])
(*) neberu v potaz jina reseni, napr. urcita firemni politika; nutnost pouzivat klienty, kteri to oznamuji velikost prilohy, ...