Sendmail a pozdrzanie velkej posty na noc

[Dan Lukes]

Lubos Kaspar wrote:


>>	Ten ruleset, o kterem byla rec se jmenuje "queuegroup", na vstupu dostava 
>>jmeno prijemce (coz nas pro nase ucely az zas tak nezajima) a ocekava 
>>se, ze vrati $#GROUPNAME.
>>
>>		Makro obsahujici velikost se pak jmenuje 'msg_size'.
>>
>>Ruleset by pak tedy mohl vypadat nejak takhle:
>>
>>KNightLimit arith
>>
>>Squeuegroup
>>R $* $: $(SLimit l $@ $&{msg_size} $@ 1536000 $)
>>R TRUE  $: $#JUSTNOW
>>R FALSE $: $#ATNIGHT
> 
> 
> To je uz uplna magie... Mozna by bylo dobre nekterym mene zbehlym
> ucastnikum konference (snad to nejsem jen ja) vysvetlit ponekud podrobneji,
> jak to funguje. Napr. nechapu, jaky je vztah mezi "NightLimit" a "SLimit"
> a co konkretne vypadne z "$(SLimit l $@ $&{msg_size} $@ 1536000 $)".
> Pokud je to vse nekde popsano, omlouvam se a staci odkaz (doufam, ze ne
> na zdrojaky sendmailu nebo na "bichli" od O'Reillyho).


	sendmail.cf je svym zpusobem magie - jako vsechno co funguje a clovek 
prilis nerozumi proc, protoze to je nebo vypada slozite.

	Je treba si uvedomit, ze program "sendmail" je jen polotovar MTA - 
znacnou cast jeho skutecnych schopnosti si musi "naprogramovat" teprve 
jeho uzivatel, a to prave vytvorenim sendmail.cf - coz je (pri trose 
tolerance) program ve specialnim jazyku.

	sendmail.cf je hlavni silou sendmailu jako takoveho a troufam si tvrdit, 
ze je jednim z dulezitych duvodu toho, proc jde o nejrozsirenejsi MTA - 
protoze tam proste muzete udelat skoro vsechno co vas napadne. A ze jsem 
videl uz nejake silene konfigurace ...

	Nicmene, zpatky k memu prispevku - vztah mezi "NightLimit" a "SLimit" je 
ten, ze mezi napsanim tech dvou radek jsem odesel zkontrolovat pripravu 
vecere a mezitim zapomel jake jmeno promenne jsem pred tim pouzil - 
takze spravne mela byt ta slova stejna -  omlouvam se, kvuli tomu se uz 
tak slozity text stal, zrejme, jeste obtizneji pochopitelny.

	Co se tyce vyznamu, ten ve zkratce popsal uz Petr Rehor a uvedl i odkaz 
na zdroj informaci. Myslim, ze neuvedl presne kde soubor op.me je, takze 
ja doplnuji, ze v podadresari docs (kdyz stahnete a rozbalite zdrojaky).

	Nicmene, sama dokumentace trochu predpoklada zakladni zkusenost s UNIX 
systemy - napriklad rozhodne hodne pomuze, pokud tusite co jsou 
regularni vyrazy (skoda, kdybyste se ozval o mesic driv, rekl bych vam, 
kdy a kde mam cviceni pro studenty, kde jsme prave tohle probrali - mohl 
jste se stavit - ale ted uz jsme za nimi).

> A to by ty daemony spoustely neco jako "sendmail -q" (se specifikaci
> prislusne fronty)?

	Psal jsem, ze to konceptu vice front jsem jeste nepronikl zcela, takze 
tady presnou radou nemohu slouzit - zajemcum mohu doprucit znovu op.me 
nebo pockat az se s frontami spratelim (pokud si jeste na tuto debatu 
vzpomenu, poslu sem pote navod).


> Nemohu posoudit narocnost takoveho reseni, ale dovolim si napsat, jak bych
> to zkusil delat. Kdyby se vyskytl podobny pozadavek, asi bych veskerou
> postu danym smerem daval nejakemu maileru s F=e (expensive),
> specifikoval bych volbu, aby se takove zpravy hned neodesilaly
> ("O HoldExpensive=True") a pak uz by to bylo snad dost jednoduche. Asi by
> stacilo nejakym programkem (i skriptem) probirat spool-dir a kontrolovat
> velikosti souboru typu dfID (s neexistujicim xfID, aby se nepreposilaly
> jeste zcela neprijate zpravy): pro ty nadlimitni davat pro dane ID
> "sendmail -qIID" pouze v definovane "nocni" dobe, pro podlimitni vzdy.
> Nevyhodou by mozna byla nejaka ztrata paralelismu, i kdyz treba pri
> spousteni "sendmail -qIID &" (na pozadi) by nemusela byt tak velka
> (navic mam dojem, ze by misto vyse uvadenych 2 daemonu stacil jeden).
> Bylo by to mozna trochu "bastlovni", ale snad by to mohlo fungovat
> (samozrejme sendmail-daemon by nesmel bezet s -qtime, aby to neposilal
> tomu udelatku "pod rukou").

	Blabol to uplne neni, ale nejspis by to nefungovalo. "F=e" a "O 
HoldExpensive=True" se, pokud se nepletu, tyka pouze "initial 
submissions" a pokud vim, i po jejich nastaveni se mi dopisy, ktere jen 
prochazely (RELAY) odesilaly ihned - takze i ve vasem pripade by i velke 
dopisy za urcitych okolnosti prochazely "rovnou".

	To uz mate jednodussi nadefinovat sendmail jako queue-only tak, aby nikdy 
nic neodesilal a pak si skutecne udelat dva druhe adresare, do jednoho 
tim vasim scriptem prehazovat denni postu, do druheho tu nocni (abyste 
se nemusel vsem porad venovat opakovane, jako tomu bylo ve vasem 
pripade) a nad temito adresari (tedy, nad tim nocnim jen v noci) byste 
spoustel (nebo dokonce nechal trvale bezet) dalsi sendmail, ktery by ji 
obsluhoval a dopisy odesilal. Vada tohoto reseni je, ze zasahuje i 
prichozi, nejen odchozi postu (to by ale slo vyresit vetsi inteligenci 
toho scriptu, co rozhoduje jestli je posta denni nebo nocni). 
Mimochodem, pro toto reseni je naopak vhodnejsi nejaky starsi sendmail, 
ktery jeste koncept vice front sam od sebe nezna - u soucasneho 
sendmailu se pomerne jasne pise, ze samotne datove souboru mezi frontami 
beztrestne prehazovat nelze.

	Kazdopadne, toto a i vase reseni vyzaduje naprogramovani jakehosi 
scriptu, cemuz jsem se s ohledem na tazatele chtel vyhnout a ma 
negativni dopad na zpozdeni pri dorucovani, zvysene naroky na diskovy 
prostor a do jiste miry i na pamet a vykon. Pripoustim ale, ze posledni 
tri namitky maji vyznam jen u velmi zatizenych postovnich uzlo, coz 
zrejme nebyl pripad tazatele.


	Mimochodem, pro tazatele mam jednu uplne odlisnou radu - (nejmene pres 
den) omezit maximalni velikost posty, kterou jsem vubec ochoten 
zpracovavat (a vetsi zcela odmitat - jde o nastaveni jedne konstanty v 
sendmail.cf) a uzivatele naucit pouzivat nejaky jiny zpusob prenosu dat. 
Mail nebyl navrzen a neni urcen pro prenos velkych dat.

	Ostatne, SMTP MTA ma povinnost prenaset soubory do velikosti 64kB - 
ostatni prenaset muze, ale nemusi - takze posilat vetsi soubor nekam, 
kdyz nevite kudy vlastne pujde a jake MTA a jak nakonfigurovane jsou po 
ceste je v zasade sazka do loterie - i kdyz pripoustim, ze 
pravdepodobnost vyhry je znacna.


						Dan


-- 
Dan Lukes,  SISAL, MFF UK  tel: +420 2 21914205, fax: +420 2 21914206
AKA: dan na obluda.cz, dan na freebsd.cz, dan na kolej.mff.cuni.cz, dan na fio.cz