Vlákno názorů k článku Ivo Lukačovič: Seznam používají hard-core uživatelé od Ondřej Čečák - OK, diky :).

OK, diky :).

Ne opravdu jsem to nemyslel ironicky, nekteri si predstavuji, ze takove systemy jsou z rise snu, pripadne pekelne drahe a ono v podstate staci mit rozumnou topologii (ano, je pravda, ze to znamena VICE jak 1 server, ale ne serverovou farmu), par stanovenych pravidel a trochu toho software (treba OSS, mozna i zcela pouze OSS, my mame hybrid) a mate reseni, ktere ma vsechny popsane vlastnosti (a samozrejme dalsi) a jehoz nasazeni neni slozite, drahe ani problematicke.

Ano je pravda, ze utnout komunikaci uprostred je problem, ono se to ale muze udelat i jinak, prijmout celou postu (a to nikoli zpusobem ze hrozi zaplneni disku - treba od 100MB vsechno dalsi zahazovat) a nasledne vygenerovat kod nikoli pro Temporary error (Try again later), ale Permanent error... - ano, jsou cunata, ktere i tak budou tu postu cpat znovu (zaznamenal jsem, ze to delal i nejaky MS Exchange a Spameri urcite). V dusledku jste nakonec odlehcil lince, nepotrebujete sofistikovane IDS a presto jste celkem v pohode... ano, je pravda, ze musite mit aspon trochu slusnou konektivitu, ale to dnes v IT neni ta nejdulezitejsi (= nejdrazsi) polozka... Tim bych povazoval problem nesdeleni velikosti prilohy na zacatku sezeni za vyresene.

Ten tipec od IDS nesmi nastat po/pri prvni takove seanci v okamziku, kdy tech dat uz je presprilis... - to by to IDS nebylo k nicemu (podobne jako IDS na portscan taky nezareaguje hned v okamziku kdy chci otevrit dva porty zaraz...). Naopak, pokud to horentni mnozstvi dat patricne odmitnu (nikoli Try again later - to si o ten pruser rovnou koleduju!), nema mi to protistrana cpat znovu, ale ma informovat odesilatele - a kdyz to nedela a cpe mi to znovu skutecne patri na pranyr... - stejne jako nas antispam v soucasne dobe obsahuje odhadem 15.000 zaznamu IP adres a domen druheho radu.

A pokud narazite na dulezitost partnera... pokud se on ke svym zacne takto chovat, tak velice rychle se z VIP stava outsider, takze neni co resit....:-) (ted si nedelam legraci, je pro mne velmi usmevne, kdyz nejmenovany jeden z nejvetsich IT distributoru v CR nektere sve obchodni nabidky (zadane) sam oznacuje diky svemu antispam systemu nasledovne v Subjektu: [SPAM] puvodni subjekt...).

A pokud se ptate, co na to MUA v lokalni siti tak na to mam bohudik jeste jednodussi odpoved... - proboha, snad nemate v siti jeden stroj, ktery se stara o lokalni MUA, postu z Internetu (a tedy je to stroj v lokalni siti) si necha posilat rovnou atd.... - ale to jsme zpet na zacatku u navrhu topologie....

BTW Ta firemni politika je soucasti toho vseho, svoboda jednotlivce konci tam, kde zacinaji naklady zamestnavatele (at uz financni nebo casove/vypadkove (= opet financni))....

"Mate dalsi otazky k teto problematice?"

Pokud to nemyslite ironicky, tak ano :).

"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, ...

Na to mam naprosto regulerni a jednoduchou odpoved... tato prasarna je pouze a jen problemem stroje/spravce, ktery jako posledni prede mnou prijal takovouto kravinu k doruceni, nikoli moje... - ostatne princip SMTP komunikace a dorucovani je Vam predpokladam dostatecne jasny.

Navic evidentne pletete hrusky a jabka... pokud mi budete posilat maily s 2-3 obrazky, predpokladam tedy, ze velikost takove posty neni vetsi nez rekneme 10MB (pri opravdu vysokem DPI), i kdybyste jich poslal tisic, nasim systemum se nic nestane a vse je v poradku. Pokud jich poslete deset tisic, dojde akorat k prekroceni quoty pro postu toho konkretniho uzivatele, kteremu posilate postu a tudiz dalsi zustane viset na SMTP relay (tedy opet u nas) a to do doby nez dojde misto na disku (resp. chvili pred tim) a opet nic vic nezaplnite. Jeste nez k tomu dojde si system zacne stezovat administratorovi a jednoduchym pohledem do SMTP queue je jasne ktera bije a koho povesit za koule. Pokud budete cune a budete postu posilat mohutne pararelne, mate opet smulu, protoze nas system se aktualne bavi asi s osmi ucastniky a o devateho nema zajem - proste si musi pockat a zkusit to pozdeji znovu (ano, efekt Starving je na miste resit, resi se to formou detekcniho systemu, ktery tuto cinnost monitoruje).

Tak a zbyva nam posledni 'utok' hrubou silou a sice jeden mail o obrovske velikosti... - vzhledem k IDS a inspekcni sonde nad SMTP je to uplne trivialni otazka - 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.

Mate dalsi otazky k teto problematice?

Jak takovy IDS regulerne zarizne SMTP relaci, aby uzivateluv klient pochopil, ze to fakt neprojde? Co kdyz je uz ta stomegova priloha na nejakem postovnim serveru, ktery stoji mezi uzivatelem a vami? Co kdyz vam poslu fotky z dovolene v nekolika emailech, kazdy s jednou az tremi fotkami? (dovolim si strelit od pasu, ze hardcore uzivatele weboveho rozhrani seznamu sto priloh k mejlu neprilozi, protoze to proste nejde)

Drive nebo pozdeji Vas zarizne IDS sonda...:-r

Dobra, mohu vam tedy na vasi emailovou adresu zaslat par emailu s prilohou o velikosti par stovek megabytu s odkazanim na vas prispevek?

Posilat soubory emailem neni rozhodne dobry napad; uz treba jenom proto, ze se k tomu email vubec nehodi. Co kdyz vam treba nejaky MUA zacne na server cpat treba 80 megovou prilohu a pritom se neobtezuje oznamit predem (aby mohl byt odmitnut), jak velka ta priloha bude? Tento prenos muze z rozlicnych duvodu selhat a opakovat se, blokovat frontu apod.

Proc? Ostatni spravci maji politiku nastavenu dle vlastnich a jim vyhovujicich pravidel... a to treba vcetne velikosti postovni MIME prilohy, velikosti hlavicky (envelope) zpravy apod... - pokud to nekdo nema, jeho problem...

Divim se, ze se nad tim nikdo nepozastavil (nebo to spravci, kteri maji co docineni s emailem, radsi vubec nectou? :))

"... Posílají si obrovské přílohy ..."

Uff, doufam, ze
- jenom v ramci seznam.cz
- nebo obrovske bylo mysleno jako treba az 1,5 MB

Pokud ne, bezim pro baseballovou palku :).