Doménový kôš

linux_pas V pre­doš­lej čas­ti sme si po­ve­da­li, že na vy­be­ra­nie poš­ty zo vzdia­le­nej schrán­ky po­mo­cou pro­to­ko­lu PO3 a jej od­ov­zda­nie na ďal­šie spra­co­va­nie slú­ži prog­ram fetchmail. Uká­za­li sme si, ako ten­to prog­ram na­kon­fi­gu­ro­vať a spúš­ťať pre kla­sic­kú poš­to­vú schrán­ku. My však chce­me vy­be­rať nie oby­čaj­nú poš­to­vú schrán­ku, ale do­mé­no­vý kôš. A to sa ten­to­raz nau­čí­me.

Do­mé­no­vý kôš
Struč­ne si zo­pa­kuj­me, čo to do­mé­no­vý kôš je a ako sa vy­tvá­ra. Pred­stav­me si, že sme správ­com po­čí­ta­čo­vej sie­te ur­či­tej fir­my ale­bo ško­ly, kto­rá má väč­ší po­čet po­ten­ciál­nych poš­to­vých pou­ží­va­te­ľov – ad­re­sá­tov. A my chce­me, aby kaž­dý pou­ží­va­teľ mo­hol mať vlas­tnú poš­to­vú schrán­ku. Pre väč­ší po­čet poš­to­vých pou­ží­va­te­ľov už nie je vhod­né vy­tvá­rať só­lo úč­ty u pos­ky­to­va­te­ľa poš­to­vých slu­žieb. Ok­rem to­ho, že to nie je eko­no­mic­ké, vzni­ka­jú s tým ur­či­té prob­lé­my, keď pri­bud­ne ale­bo ubud­ne ur­či­tý za­mes­tna­nec či žiak, keď sa zme­ní or­ga­ni­zač­ná štruk­tú­ra a po­dob­ne. To by sme mu­se­li za­kaž­dým žia­dať pro­vi­de­ra o zme­nu, a to sú – bo­hu­žiaľ – pe­niaž­ky na­vy­še. Vte­dy je vhod­nej­šie po­žia­dať o zria­de­nie do­mé­no­vé­ho ko­ša.

Do­mé­no­vý kôš je zvláš­tna poš­to­vá schrán­ka, kto­rá sa na­chá­dza u pos­ky­to­va­te­ľa poš­to­vých slu­žieb, ale ne­sie me­no na­šej poš­to­vej do­mé­ny. A všet­ka poš­ta, kto­rá bu­de ad­re­so­va­ná na tú­to poš­to­vú do­mé­nu, bu­de ulo­že­ná do tej­to schrán­ky ne­zá­vis­le od sku­toč­né­ho ad­re­sá­ta.

Na ob­ráz­ku č. 1 má­me vzo­ro­vú sché­mu ne­pria­me­ho do­ru­čo­va­nia poš­ty do do­mé­no­vé­ho ko­ša:

obr.č.1 - 24.jpg
obr. 1

U vy­bra­né­ho pos­ky­to­va­te­ľa poš­to­vých slu­žieb, nech je to POS­KY­TO­VA­TEL(.SK), si ne­chá­me vy­tvo­riť poš­to­vú do­mé­nu pre na­šu fir­mu s náz­vom FIR­MA(.SK). Spra­vid­la kaž­dý pos­ky­to­va­teľ – pro­vi­der – je zá­ro­veň re­gis­trá­to­rom do­mén, tak­že všet­ky pot­reb­né pa­pie­ro­vač­ky vy­ba­ví za nás a vy­tvo­rí nám poš­to­vý účet, kto­rý bu­de mať ná­zov @fir­ma.sk (ten­to zá­pis sa v li­te­ra­tú­re ozna­ču­je RHS – right hand si­de). Nech je na ľa­vej stra­ne zá­pi­su (ozna­čo­va­nej ako LHS – left hand si­de) čo­koľ­vek, bu­de to do­ru­če­né do tej­to schrán­ky.

(Nech nás te­raz net­rá­pi, že ako je mož­né, že do­mé­na fir­ma.sk exis­tu­je na do­mé­ne pos­ky­to­va­tel.sk – to sa nau­čí­me, keď sa­mi bu­de­me tvo­riť do­mé­no­vé ko­še pre na­šich klien­tov – aj to bu­de, vy­dr­žme!) Tak­že do tej­to schrán­ky mô­že prísť poš­ta pre pá­na ria­di­te­ľa, pre sklad­ní­ka, šé­fa ná­ku­pu, ale aj pre za­mes­tnan­ca, kto­rý vô­bec neexis­tu­je. Jed­no­du­cho všet­ka!

Pri vy­tvá­ra­ní do­mé­no­vé­ho ko­ša nám pro­vi­der pri­de­lí nie­len je­ho zá­pis vo for­má­te @fir­ma.sk, ale tak ako pri kla­sic­kom úč­te aj prih­la­so­va­cie me­no, napr. fixma, a hes­lo, nech je to fi97m45. Ke­by sme sa k do­mé­no­vé­mu ko­šu pri­po­ji­li po­mo­cou tel­ne­tu na port 110 (už sme si viac­krát uká­za­li, ako to uro­bí­me), lis­to­va­ním by sme zis­ti­li, že sa v schrán­ke sku­toč­ne na­chá­dza­jú mai­ly pre rôz­nych ad­re­sá­tov na­šej do­mé­ny fir­ma.sk.

Po­vie­te si, že is­tot­ne by sa da­lo ku ko­šu pri­po­jiť kla­sic­kým kon­co­vým klien­tom MUA. Za­dá­me prih­la­so­va­cie me­no a hes­lo a všet­ku poš­tu si stiah­ne­me. Len­že to by si mu­se­li všet­ci ad­re­sá­ti cho­diť čí­tať poš­tu k nám a to prá­ve nech­ce­me. Pre­to si za­se pos­ta­ví­me poš­to­vý li­nuxový server, kto­rý naz­ve­me nap­rík­lad ru­bin, a pri­de­lí­me mu do­mé­nu fir­ma.sk, tak­že úpl­né me­no bu­de ru­bin.fir­ma.sk (ale ne­mu­sí­me – je­ho ná­zov mô­že byť ľu­bo­voľ­ný, pre­to­že sa ne­zob­ra­zu­je vo sve­te inter­ne­tu).

Skon­fi­gu­ru­je­me pos­tfix pres­ne tak, ako sme si to uká­za­li v pre­doš­lej čas­ti, pre­to­že sku­toč­nosť, že pra­cu­je­me s do­mé­no­vým ko­šom, a nie s kla­sic­kou strán­kou, je vec fetchmai­lu, nie pos­tfixu! Na stra­ne náš­ho server­a vy­tvo­rí­me prís­luš­ných ad­re­sá­tov – li­nuxových pou­ží­va­te­ľov. Nech to sú v na­šom prí­pa­de na­kup, ria­di­tel a sklad. Poš­to­vých klien­tov MTA u jed­not­li­vých pou­ží­va­te­ľov nas­ta­ví­me štan­dar­dným spô­so­bom. Te­raz už len sta­čí nas­ta­viť prog­ram fetchmail tak, aby do­ká­zal vy­brať poš­tu z do­mé­no­vé­ho ko­ša a od­ov­zdať ju pos­tfixu na za­trie­de­nie do schrá­nok jed­not­li­vých ad­re­sá­tov.

fetchmail a do­me­no­vý kôš
Na vý­pi­se č. 2 je vzor kon­fi­gu­rač­né­ho sú­bo­ru .fetchmailrc na spo­lup­rá­cu s do­mé­no­vým ko­šom:

poll mail.pos­ky­to­va­tel.sk aka fir­ma.sk no dns no en­ve­lo­pe
pro­to­col PO­P3
user fixma password fi97m45 to * he­re
smtphost lo­cal­host

Všim­ni­me si, že zme­na nas­ta­la v pr­vom riad­ku za slo­vom aka. Kon­tak­tu­je­me sí­ce server mail.pos­ky­to­va­tel.sk, ale pre do­mé­nu fir­ma.sk! Ďal­šia zme­na nas­ta­la v riad­ku user fixma password fi97m45 to * he­re. Znak * (hviez­dič­ka) za slo­vom to sym­bo­li­zu­je, že poš­tu sťa­hu­je­me pre ľu­bo­voľ­né­ho pou­ží­va­te­ľa li­nuxové­ho server­a.

Na pos­led­nom riad­ku za pa­ra­met­rom smtphost de­fi­nu­je­me, kto­ré­mu server­u bu­de poš­ta po stiah­nu­tí od­ov­zda­ná, lo­cal­host zna­čí, že ide o náš server. Tu by moh­lo byť uve­de­né aj úpl­né me­no, te­da ru­bin.fir­ma.sk ale­bo ad­re­sa IP server­a, pod­ľa to­ho, či je náš server pod­ľa me­na do­siah­nu­teľ­ný, ale­bo nie.

Tak­že po stiah­nu­tí poš­ty prog­ram fetchmail kon­tak­tu­je pos­tfix na na­šom server­i a poš­tu mu od­ov­zdá. Ten poš­tu pre­vez­me a roz­trie­di pod­ľa mien, kto­ré sa v obál­ke poš­ty na­chá­dza­jú pred za­vi­ná­čom, te­da pod­ľa LHS. Ak pos­tfix náj­de správ­ne­ho ad­re­sá­ta, te­da me­no pred za­vi­ná­čom sa zho­du­je s me­nom pou­ží­va­te­ľa, poš­tu ulo­ží do je­ho schrán­ky. Ak ne­náj­de zho­du so žiad­nym me­nom na Li­nuxe, poš­tu vrá­ti ako ne­do­ru­či­teľ­nú (ak v nas­ta­ve­niach neur­čí­me inak – ako si eš­te uká­že­me).

Po­dob­ne ako v pred­chá­dza­jú­cej čas­ti aj te­raz za­bez­pe­čí­me pra­vi­del­né spúš­ťa­nie prog­ra­mu fetchmail (set dae­mon) a je­ho auto­ma­tic­ké štar­to­va­nie pri boo­te sys­té­mu (rc.lo­cal) a sťa­ho­va­nie poš­ty z do­mé­no­vé­ho ko­ša má­me za­bez­pe­če­né.

Aby sme náš poš­to­vý sys­tém zlep­šo­va­li, te­raz sa bu­de­me ve­no­vať ur­či­tým „pi­koš­kám“ v nas­ta­ve­ní pos­tfixu. Sú to ve­ci z praxe, kto­ré nás mô­žu za­sko­čiť a my si ne­bu­de­me ve­dieť ra­dy.

Auten­ti­fi­ká­cia
Na inter­ne­te sa čo­raz viac roz­má­ha ro­zo­sie­la­nie ne­vy­žia­da­nej poš­ty. Tej­to poš­te sa ho­vo­rí aj spam. Spa­me­ri vy­uží­va­jú ne­za­bez­pe­če­né SMTP server­y, aby moh­li cez ne v pod­sta­te ne­kon­tro­lo­va­teľ­ne ší­riť spa­my. Pre­to sa mno­hé server­y sna­žia chrá­niť po­mo­cou auten­ti­fi­ká­cie. Ide v pod­sta­te o to, že ak niek­to po­sie­la poš­tu cez da­ný server, mu­sí pred jej od­os­la­ním pos­lať server­u svo­je me­no a hes­lo. Ten ove­rí, či od­osie­la­teľ je je­ho klien­tom s prá­vom od­osie­lať poš­tu, te­da či je­ho me­no a hes­lo exis­tu­je v je­ho da­ta­bá­ze. Ak áno, od­osie­la­nie mai­lu po­vo­lí. Ak me­no ale­bo hes­lo ne­se­dí ale­bo ne­bo­lo vô­bec od­os­la­né, server od­miet­ne poš­tu pri­jať a od­os­lať. Ako sa to pre­ja­vu­je?

Mož­no sa nám sta­lo, že keď sme sa skú­ša­li tel­ne­tom pri­po­jiť na niek­to­ré­ho pos­ky­to­va­te­ľa po­mo­cou pro­to­ko­lu SMTP, ne­bo­lo mož­né s ním ko­mu­ni­ko­vať, le­bo vy­pi­so­val nie­čo o ove­re­ní. Ako prík­lad si uká­že­me pri­po­je­nie na SMTP server mail.ston­li­ne.sk:

[root@ru­bin root]# tel­net mail.ston­li­ne.sk 25
Trying 213.81.152.7...
Con­nec­ted to mail.ston­li­ne.sk (213.81.152.7).
Es­ca­pe cha­rac­ter is ‘^]’.
220 smtp.ston­li­ne.sk – Server ESMTP (St On­li­ne)
mail from: leon­ka@do­ma.sk
250 ok
rcpt to: mior@fir­ma.sk
530 5.7.1 Pri 
od­osie­la­ni pos­ty je 
nut­ne pou­zit me­no a hes­lo. 
Pro­si­me 
nas­tav­te vas e-mai­lo­vy prog­ram aby 
pou­zi­val SMTP auten­ti­fi­ka­ciu. .....
Re­laying not allowed – plea­se use SASL: mior@fir­ma.sk
Ti­meout whi­le waiting for com­mand.
Con­nec­tion clo­sed by fo­reign host.

Vi­dí­me, že nie sme schop­ní od­os­lať poš­tu, pre­to­že server je chrá­ne­ný pro­ti neauto­ri­zo­va­ným od­osie­la­te­ľom. (Vy­ko­na­nie auten­ti­fi­ká­cie pria­mo po­mo­cou tel­ne­tu vô­bec nie je jed­no­du­ché, pre­to sa ním te­raz ne­bu­de­me za­obe­rať). Dô­le­ži­té je však to­to: Ak nie sme schop­ní bez auten­ti­fi­ká­cie od­os­lať poš­tu my, ta­kis­to ne­bu­de schop­ný od­os­lať poš­tu pos­tfix! Čo te­raz?

Poz­nám­ka:
Naj­prv si mu­sí­me uve­do­miť, že na auten­ti­fi­ká­ciu mô­že­me na­ze­rať z dvoch strán. Z jed­nej stra­ny je to auten­ti­fi­ká­cia, kto­rú vy­ža­du­je náš pos­tfix vo­či na­šim klien­tom. To je prí­pad, kto­rý nás však te­raz ne­zau­jí­ma (ale aj to­to si nes­kôr uká­že­me). Čo nás za­ují­ma, je dru­há stra­na – auten­ti­fi­ká­ciu po na­šom pos­tfixe vy­ža­du­je je­ho náp­ro­ti­vok na stra­ne pos­ky­to­va­te­ľa poš­to­vých slu­žieb, te­da náš pos­tfix je v tom­to prí­pa­de klien­tom na­dria­de­né­ho pos­tfixu, kto­rý je na­de­fi­no­va­ný v sú­bo­re main.cf ako hod­no­ta pa­ra­met­ra re­lay­host. A pre­to sa to­mu­to ho­vo­rí aj ove­ro­va­nie na stra­ne klien­ta.

Tak­že mu­sí­me pos­tfix nas­ta­viť tak, aby do­ká­zal ove­ro­va­nie na stra­ne klien­ta. Uro­bí­me to tak­to:
Prip­ra­ví­me si sú­bor s me­nom a hes­lom pre náš­ho pos­ky­to­va­te­ľa. Nech sa ten­to sú­bor na­zý­va sasl_passwd. Ulo­ží­me ho do ad­re­sá­ra /etc/pos­tfix/. Sú­bor sasl_passwd bu­de mať tú­to štruk­tú­ru:

pos­ky­to­va­teľ   me­no:hes­lo
Tak­že v na­šom prí­pa­de to bu­de tak­to:

mail.pos­ky­to­va­tel.sk	fixma: fi97m45

Sú­bor /etc/pos­tfix/sasl_passwd ulo­ží­me. Spus­tí­me prí­kaz pos­tmap na vy­tvo­re­nie da­ta­bá­zy z toh­to texto­vé­ho sú­bo­ru:

 [root@ru­bin pos­tfix]# pos­tmap /etc/pos­tfix/sasl_passwd

V sú­bo­re /etc/pos­tfix/main.cf mu­sí­me za­pnúť ove­ro­va­nie klien­ta. Do toh­to sú­bo­ru do­pí­še­me tie­to riad­ky:

smtp_sasl_auth_enab­le = yes
smtp_sasl_password_maps = hash:/etc/pos­tfix/sasl_passwd

Sú­bor main.cf ulo­ží­me. Reš­tar­tu­je­me pos­tfix, aby si na­čí­tal no­vé nas­ta­ve­nie kon­fi­gu­rač­né­ho sú­bo­ru, nap­rík­lad po­mo­cou služ­by servic­e

 [root@ru­bin pos­tfix]# servic­e pos­tfix re­load

Od­te­raz pri od­osie­la­ní poš­ty do sve­ta po­mo­cou na­dria­de­né­ho SMTP server­a bu­de náš pos­tfix od­osie­lať me­no a hes­lo na auten­ti­fi­ká­ciu sám!

Neexis­tu­jú­ci ad­re­sát Po­ve­da­li sme si, že ak prí­de do náš­ho do­mé­no­vé­ho ko­ša poš­ta pre kon­krét­ne­ho ad­re­sá­ta, bu­de ulo­že­ná do je­ho poš­to­vej schrán­ky. Ak je však ad­re­sát nez­ná­my, bu­de tá­to poš­ta vrá­te­ná ako ne­do­ru­či­teľ­ná. Ob­čas sa však stá­va, že by sme chce­li, aby náš server poš­tu nev­ra­cal, ale ju od­ov­zdá­val niek­to­ré­mu zo sku­toč­ných ad­re­sá­tov – pou­ží­va­te­ľov.

Na čo je to dob­ré, to je vždy po­le­mic­ké. V praxi som sa však stre­tol s tým, že fir­my po­ža­du­jú za­chy­tá­va­nie všet­kej poš­ty, te­da aj tej pre neexis­tu­jú­cich pou­ží­va­te­ľov, a to z dô­vo­du, aby im neuš­la dô­le­ži­tá in­for­má­cia. Mô­že sa stať, že sa niek­to pri pí­sa­ní mai­lu pá­no­vi ria­di­te­ľo­vi prek­lep­ne a na­mies­to ad­re­sy ria­di­tel@fir­ma.sk na­pí­še ri­di­tel@fir­ma.sk.

V kla­sic­kom prí­pa­de sa poš­ta vrá­ti ako ne­do­ru­či­teľ­ná, a tak skú­se­ný od­osie­la­teľ ad­re­su op­ra­ví a sprá­vu poš­le zno­va. Ale čo ak na dru­hej stra­ne poš­to­vé­ho ka­ná­la je niek­to me­nej zna­lý poš­to­vých sú­vis­los­tí a ne­do­ká­že po­sú­diť, či poš­ta bo­la do­ru­če­ná ale­bo nie? A tak sa spo­lie­ha, že je­ho sprá­va do­ra­zi­la na správ­ne mies­to (to nie je fik­cia, to je prax!!!).

Za­chy­tá­va­nie poš­ty pre nez­ná­mych ad­re­sá­tov do­siah­ne­me tak­to: Naj­prv v li­nuxovom sys­té­me vy­tvo­rí­me pou­ží­va­te­ľa, kto­ré­mu bu­de tá­to poš­ta do­ru­čo­va­ná, nap­rík­lad s me­nom zvy­sok. V kon­fi­gu­rač­nom sú­bo­re pos­tfixu main.cf nas­ta­ví­me tie­to pa­ra­met­re:

lu­ser_re­lay = zvy­sok
lo­cal_re­ci­pient_map =

(Pa­ra­me­ter lo­cal_re­ci­pient_map ne­chá­me prázd­ny, te­da za zna­kom „rov­ná sa“ nič ne­vypl­ní­me!)

Pos­tfix re­loa­du­je­me a od­te­raz bu­de poš­ta, kto­rá ne­má sku­toč­né­ho ad­re­sá­ta v na­šej poš­to­vej do­mé­ne, uk­la­da­ná do poš­to­vej schrán­ky pou­ží­va­te­ľa zvy­sok.

Tre­ba poz­na­me­nať, že sve­tom inter­ne­tu sa ší­ri už spo­mí­na­ný spam. Spa­me­ri zis­tia od­nie­kiaľ poš­to­vé do­mé­ny a po­tom slov­ní­ko­vou me­tó­dou sa sna­žia ší­riť spam do na­šej do­mé­ny s pred­pok­la­dom, že sa niek­to pred­sa len na ich rek­la­my chy­tí. Po­tom bu­de vše­tok spam za­chy­te­ný a do­ru­če­ný pou­ží­va­te­ľo­vi zvy­sok. A pre­to tre­ba za­chy­tá­va­nie ne­do­ru­či­teľ­nej poš­ty dob­re zvá­žiť. Mo­rál­nos­ti spa­me­rov a ús­peš­nos­ti spa­mu sa te­raz ne­bu­de­me ve­no­vať. Ale to, že spam sa dá znač­ne re­du­ko­vať, si uká­že­me nes­kôr.

Alia­sy
Alia­sy sú fik­tív­ne me­ná ad­re­sá­tov, kto­rí v sku­toč­nos­ti na poš­to­vom server­i neexis­tu­jú, ale sú za­stú­pe­ní sku­toč­ný­mi pou­ží­va­teľ­mi. Pred­stav­me si, že má­me v na­šej fir­me expe­dič­né od­de­le­nie, kde pra­cu­jú pa­ni No­vá­ko­vá, sleč­na Krás­na a pán Ra­dost­ný. Všet­ci tra­ja ma­jú za po­vin­nosť rie­šiť a vy­ba­vo­vať poš­tu, kto­rá na to­to od­de­le­nie pri­chá­dza.

Pre­to vy­tvo­rí­me fik­tív­nu poš­to­vú ad­re­su expe­di­cia@fir­ma.sk a nas­ta­ví­me pos­tfix tak, aby pri­ja­tú poš­tu do­ru­čil kaž­dé­mu z toh­to od­de­le­nia – te­da na sku­toč­né poš­to­vé ad­re­sy no­va­ko­va@fir­ma.sk, kras­na@fir­ma.sk a ra­dost­ny@fir­ma.sk (pou­ží­va­te­ľa expe­di­cia ne­vyt­vá­ra­me, za­to pou­ží­va­te­lia no­va­ko­va, kras­na a ra­dost­ny mu­sia v sys­té­me exis­to­vať!!!) To do­siah­ne­me tak­to:

V ad­re­sá­ri /etc/pos­tfix/ sa na­chá­dza sú­bor alia­ses. Ak sa doň po­zrie­me, vi­dí­me, že v ňom už exis­tu­jú ur­či­té alia­sy, nap­rík­lad:

pos­tmas­ter:	root
ad­min:		root
ma­na­ger:	root
ope­ra­tor:	root
web­mas­ter:	root	
abu­se:		pos­tmas­ter
all:		pos­tmas­ter
root:		pos­tfix

Mô­že­me si ove­riť, že v li­nuxovom sys­té­me pou­ží­va­te­lia pos­tmas­ter, ad­min, ma­na­ger, ope­ra­tor, abu­se a all neexis­tu­jú. Z uve­de­ných sku­toč­ne exis­tu­je iba root a pos­tfix (vzni­kol pri in­šta­lá­cii pos­tfixu). Ale keď niek­to poš­le poš­tu na pos­tmas­ter, ad­min, ma­na­ger ale­bo ope­ra­tor, ma­la by byť v zmys­le toh­to sú­bo­ru pre­pos­la­ná pou­ží­va­te­ľo­vi root. Ale keď­že exis­tu­je alias, že root je pos­tfix, sprá­vy bu­dú pria­mo do­ru­če­né ad­re­sá­to­vi pos­tfix! Po­dob­ne keď niek­to poš­le poš­tu na ad­re­su abu­se@fir­ma.sk, tá bu­de pos­la­ná tiež pou­ží­va­te­ľo­vi pos­tfix, aj keď je sme­ro­va­ná na prí­jem­cu pos­tmas­ter a cez ne­ho na roo­ta! Is­to nás za­ují­ma, pre­čo je to tak­to kom­pli­ko­va­ne uro­be­né, veď by bo­lo jed­no­duch­šie po­sie­lať to rov­no roo­to­vi, nie? Mu­sí­me si uve­do­miť, že vy­be­ra­nie schrán­ky hes­lom roo­ta je pro­ti všet­kým bez­peč­nos­tným pra­vid­lám. Pre­to bo­la všet­ka poš­ta po­mo­cou sú­bo­ru alia­ses pres­me­ro­va­ná na pou­ží­va­te­ľa pos­tfix. Vráť­me sa však k náš­mu prík­la­du. Na ko­niec sú­bo­ru alia­ses do­pí­še­me ria­dok:

expe­di­cia:	no­va­ko­va, kras­na, ra­dost­ny

Sú­bor alia­ses ulo­ží­me.
Z texto­vé­ho sú­bo­ru /etc/pos­tfix/alia­ses mu­sí­me vy­tvo­riť da­ta­bá­zo­vý sú­bor alia­ses.db.
Za­dá­me prí­kaz:

 [root@ru­bin pos­tfix]# newalia­ses

Pos­tfix re­loa­du­je­me.

Od­te­raz kaž­dá poš­ta ad­re­so­va­ná na ad­re­su expe­di­cia@fir­ma.sk bu­de auto­ma­tic­ky do­ru­če­ná všet­kým trom pra­cov­ní­kom expe­dič­né­ho od­de­le­nia.

Pres­me­ro­va­nie poš­ty (forward)
Stá­va sa, že ko­le­ga No­vák z na­šej fir­my od­išiel pra­co­vať inam, a tak chce­me, aby poš­ta ad­re­so­va­ná na je­ho sta­rú ad­re­su no­vak@fir­ma.sk bo­la pres­me­ro­va­ná na je­ho no­vú ad­re­su no­vak@ina­fir­ma.sk.

Ale­bo dru­hý prí­pad: Pán Let­ko od­chá­dza na do­vo­len­ku, ale pot­re­bu­je poš­tu čí­tať aj na do­vo­len­ke. Keď­že na­še bez­peč­nos­tné opat­re­nia sie­te ne­do­vo­ľu­jú čí­ta­nie poš­ty po­mo­cou web­mai­lu cez inter­net, bu­de­me po­čas je­ho do­vo­len­ky pre­po­sie­lať je­ho poš­tu na niek­to­rý z ve­rej­ných poš­to­vých server­ov, kto­rý web­mail umož­ňu­je, nap­rík­lad na VE­REJ­NY.SK. Paľ­ko­vi Let­ko­vi za­lo­ží­me ve­rej­ný poš­to­vý účet s ad­re­sou pa­vel.let­ko@ve­rej­ny.sk.

Pre­po­sie­la­nie (forwar­ding) poš­ty za­bez­pe­čí­me tak­to:
V do­mov­skom ad­re­sá­ri pou­ží­va­te­ľa let­ko vy­tvo­rí­me sú­bor .forward (aj s tou bod­kou).
Do sú­bo­ru /ho­me/let­ko/.forward za­pí­še­me ad­re­su, kam sa má poš­ta pre­po­sie­lať, te­da

pa­vel.let­ko@ve­rej­ny.sk

Sú­bor .forward ulo­ží­me.

Ho­to­vo! Od­te­raz bu­de poš­ta pre Paľ­ka Let­ka (môj­ho dob­ré­ho bra­da­té­ho ka­ma­rá­ta) bez náš­ho pri­či­ne­nia pres­me­ro­va­ná na je­ho do­vo­len­ko­vú ad­re­su. Nes­mie­me za­bud­núť na dve ve­ci. Po pr­vé, poš­ta sa pres­me­ro­vá­va, te­da sa na server­i neuk­la­dá ani jej kó­pia! Po dru­hé, keď sa Paľ­ko z do­vo­len­ky vrá­ti, sú­bor .forward zma­že­me, aby mo­hol za­se nor­mál­ne pri­jí­mať poš­tu.

S poš­tou sa da­jú ro­biť aj inak­šie „psie ku­sy“. Mô­že­me ju ko­pí­ro­vať, filtro­vať, tes­to­vať na ví­ru­sy, spam a po­dob­ne. Na to slú­ži ďal­ší prog­ram, kto­rý dopĺňa poš­to­vý sys­tém. Na­zý­va sa proc­mail a o ňom si bu­de­me roz­prá­vať na­bu­dú­ce.

Ďal­šie čas­ti >>

Zdroj: Infoware 8/2005



Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

Li­nux prak­tic­ky ako server úvod
Linux ako server je pomerne zložitá technológia. Jej výhodou je určitá modularita, keď sa nemusí nastaviť celý server naraz, ale postupne. čítať »
 
Syn­chro­ni­zá­cia ča­su v Li­nuxe
V predchádzajúcich dvoch častiach sme si ukázali, že Linux a všeobecne open source softvér sa nenachádza iba v serveroch a počítačových sieťach, ale aj v iných zariadeniach bežnej domácej potreby a v oblasti hobby. čítať »
 
Za­ria­de­nia za­lo­že­né na Li­nuxe
V predchádzajúcej časti sme si spomenuli definície nie - ktorých pojmov z oblasti nášho záujmu, teda Linuxu. Vysvetlili sme si, čo je to Open Source, Public Domain, proprietárny softvér a GNU GPL. Tentoraz ukážeme, ako sa tieto pojmy využívajú v praxi. čítať »
 
Po­jmy z ob­las­ti
Tentoraz na chvíľu trochu odbočíme od bezpečnosti Linuxu a jeho siete. V tejto neštandardnej časti seriálu sa mu budeme venovať len okrajovo. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí II.
V predchádzajúcej časti sme sa začali zaoberať bezpečnosťou bezdrôtových sietí. Poukázali sme na rôzne faktory zneužitia siete, podstatu rizika a vysvetlili sme základné prvky bezpečnosti. čítať »
 
Bez­peč­nosť bez­drô­to­vých sie­tí I.
V predchádzajúcich častiach sme sa venovali bezpečnosti linuxového servera. Riešili sme firewall, bezpečnosť prístupu na internet, zaoberali sme sa demilitarizovanou zónou a podobne. čítať »
 
Údr­žba lo­gov – kon­fi­gu­rá­cia log­ro­ta­te
V predchádzajúcej časti sme sa venovali rotácii logov. Vysvetlili sme princíp ukladania logov, spôsob, ako sa rotujú, a uviedli sme niečo o tom, čo a ako treba nastaviť čítať »
 
Údr­žba lo­gov – ro­tá­cia
V predošlej časti sme sa zaoberali spôsobom logovania informácií na iný alebo vzdialený počítač a ukázali sme, ako riešiť problém s logovaním uzavretých procesov pomocou chroot. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter