MaxRecipientsPerMessage selektivne

[Dalibor Toman]

> > Proboha proc snizovat limit na RCPT TO? . Tohle nastaveni podle me nic neresi (klient misto jedne zpravy jich odesle treba padesat)
> 
> No IMHO napr. preto, ze ked je jedna adresa chybna, tak server drzi vsetko
> vo fronte. Kdezto ked to naporcuje napr. po 5 useroch, tak 95 prejde a iba
> stoji s 1 chybovou hlaskou. A sranda je, ked napr. 100 ludom posiela
> prilohu. To sa musi ta priloha 100x poslat a ked jedna adresa nejde, tak
> mu tam stoja pekne nakopene prilohy. A ked to je nejaky 2MB dokument, tak
> nam uz mozno doslo miesto na /var -ku :-)

???? pokud poslu zpravu 1000ci prijemcum ve /var/spoolu/mqueue je vzdy _jeden_ file s obsahem zpravy (s prilohou)! Naopak poslu-li tu zpravu po blocich prijemcu (treba po 100) pak budu mit na serveru 10 zprav a zaberu tedy 10x tolik mista!
> 

> Ale po pravde nie som si teraz isty, ze ked posiela 100 ludom naraz a
> niekomu sa podari poslat, ci automaticky ho vysekne z tych komu to ma este
> dorucit, alebo mu to posle zase.

Samozrejme, ze server _MUSI_ dorucovat kazdemu prijemci nezavisle na ostatnich. Cili jakmile to nekomu doruci (resp. odesle zpravu dalsimu maileru), pak mu ji jiz nikdy znova neposila.

PS. optimalizovany SMTP  server jde tak daleko, ze prijemce sdruzuje podle ciloveho mail serveru. Cili pokud je z tisice adres 50 na jednom serveru, muze se stat, ze na tento server poleti ta zprava jen jednou (ne 50x). Tim ze klienta donutis poslat zpravu nekolikrat ovsem server v teto optimalizaci uspesne branis :-(

Dale je tu argument, ktery jsem zminoval v predchozi zprave - neznam postovniho klienta, ktery umi tuto situaci spravne obslouzit (pokud se takovy najde, pak je stejne pouziva minimum zakaznikut). Cili jsem-li spravce komercniho serveru nemuzu si dovolit klienty takto omezovat. To si muze dovolit akademicka sfera nebo spravce foremniho serveru.

D. Toman