Odchozí posta je predávána odesílacímu programu (MSP - Message Submission Program), který se stará o její odeslání (usr/sbin/sendmail). Je to program, který predá postu dále. Výhoda je v tom, ze uzivatelský program nemusí vedet nic o postovních protokolech a stará se pouze o interakci s uzivatelem.
MSP predává postu dále programu pro prenos posty (MTA - Mail Transport Agent). Ten postu predá SMTP serveru, to je místo, kde se posta prechovává pred dorucením (Relay). Pro SMTP je vyhrazen TCP port 25.
MTA komunikuje s cílovým serverem (nebo dalsími MTA), aby dorucil postu pro príjemce. Na cílovém serveru predá - dorucovacímu programu (MDA - Mail Delivery Agent). MDA můze postu jeste dále trídit a nalozí s ní podle uzivatelem zadaných pravidel - nejcasteji jde do pridelené schránky. Pak jiz posta ceká jen na to, az si ji vyzvedneme.
Ke konecnému dorucení z postovního serveru do naseho pocítace se jiz pouzívají jiné protokoly: POP (Post Office Protocol; nejcasteji se lze setkat s verzí POP3), nebo IMAP (Internet Mail Access Protocol, dnes ve verzi IMAP4), který je navrzen nejen ke stahování posty, ale i pro dálkovou práci s ní. Na strane postovního serveru k tomu samozrejme musí bezet príslusný démon, který v techto protokolech komunikuje. Existuje mnoho rozsirení protokolu POP3, spocívající na prihlasvání bezpecnejsím nez je heslo v textové podobe - APOP (MD5), RPOP (RPOP), KPOP (Kerberos), POP3+OPIE (OTP) a dalsí protokoly, spocívající na rozsírení ESMTP - ETRN a ODMR (On-Demand Mail Relay). Pro prístup k poste lze samozrejme pouzít i standardní metody vzdáleného prístupu jako NFS nebo LDAP.
Nastavení firewallu
Pred zahájením vlastní instalace serveru musíme upravit nastavení firewallu. Samotný server bude vyzadovat ke svému behu standardní TCP port 25 (SMTP).
Programy pro práci s postou
Historická role MSP a MTA pripadá ve vetsine distribucí na Sendmail. Je to robustní, schopný a dnes jiz snad i bezpecný monolitický program.
Role standardního MDA pripadá programu Procmail. Jeho schopností filtrovat postu vyuzívá denne mnozství uzivatelů na trídení posty a programů a k odhalování nevyzádané posty.
Roli programu pro vyzvedávání posty pak vetsinou plní Fetchmail (dríve zvaný popclient).
Ke kazdému z techto programů existují alternativy, jako napríklad Qmail, Maidrop a Postfix nebo Vpopmail a dalsí.
.
sendmail bezí jako dva démony - jeden, privilegovaný, bezí jako SMTP server, ceká na spojení na TCP portu 25 a stará se o odeslání cekající posty z fronty v /var/spool/mqueue. Druhý, neprivilegovaný, obcas nahlédne do neprivilegované fronty /var/spool/clientmqueue s postou neprijatou k odeslání (vetsinou proto, ze se nepodarilo kontaktovat cílový server) a pokusí se o její opetovné odeslání.
Pri odesílání posty program spustí neprivilegovanou instanci programu
Sendmail (program je sgid a bezí pod skupinou smmsp) a predá mu data zprávy. Sendmail se pokusí kontaktovat SMTP server a predat mu postu k vyrízení. Pokud se to povede, SMTP server data pomerne rychle prevezme a dalsí osud posty je na nem. Pokud se to nepovede, ulozí postu k pozdejsímu dorucení do neprivilegované fronty /var/spool/clientmqueue a dále se o její osud nestará.
Sendmail jako SMTP server
Kdyz mu dojde pozadavek na port 25, nejdríve se overí oprávnení (vetsinou bývá povoleno uzivatelům z místní síte odeslat postu kamkoliv a uzivatelům zvnejsku dorucit postu místním uzivatelům). Provede dalsí testy, a pokud je vse v porádku, postu prevezme a pokousí se ji dorucit. Pritom pouzívá frontu /var/spool/mqueue, kam si odkládá procházející postu a postu, kterou se zatím nepodarilo odeslat. Pokud se odeslání podarí, smaze ji z fronty a jeho úkol je splnen. Pokud ne, periodicky se pokousí odeslat ji znovu. Pokud se to nepovede ve stanoveném case, posle nejdríve odesílateli varování, po delsí dobe pak chybové hlásení a postu z fronty vyradí.
Druhá, neprivilegovaná instance démonu Sendmail bezí pod skupinou smmsp a uzivatelem smmsp a hlídá, zda do neprivilegované fronty /var/spool/clientmqueue nepribyla nejaká neodeslaná posta. Tu se pak periodicky pokousí odeslat místnímu SMTP serveru. V ostatních ohledech se chová podobne jako první instance (az na to, ze nehlídá port 25).
prístupová práva pro adresáre a soubory Sendmailu:
-r-xr-sr-x root smmsp /usr/sbin/sendmail*
drwxrwx--- smmsp smmsp /var/spool/clientmqueue/
drwx------ root root /var/spool/mqueue/
Stav neprivilegované fronty lze kontrolovat príkazem mailq -Ac, stav privilegované fronty můze superuzivatel overit príkazem mailq. Ke statistice mailového provozu slouzí mailstats.
Ke konfiguraci Sendmailu slouzí balík m4 maker, který ulehcuje správu.
cd /usr/share/sendmail/cf/m4
m4 ../m4/cf.m4 /etc/mail/sendmail.mc >/etc/mail/sendmail.cf
killall -HUP sendmail
Komentáre v m4 zacínají dnl (Delete to New Line) nebo se uzavírají mezi divert(). Ostatní parametry, uvádené dále, jsou zarazovány v tomto poradí:
VERSIONID
OSTYPE
DOMAIN
FEATURE
lokální definice maker
MAILER
LOCAL_CONFIG
LOCAL_RULE_*
LOCAL_RULESETS
Novejsí Sendmail pouzívá dve konfigurace - /etc/mail/sendmail.cf, pokud je spousten jako superuzivatel nebo je v príkazovém rádku -Am, a /etc/mail/submit.cf, pokud není spousten jako superuzivatel nebo je v príkazovém rádku -Ac.
Sendmail se tedy spoustí pod superuzivatelem jako dva démony, typicky temito príkazy:
# Sendmail jako MTA
/usr/sbin/sendmail -L sm-mta -bd -q1h
# Sendmail pro kontrolu MSP fronty
/usr/sbin/sendmail -L sm-msp-queue -Ac -q30m
Argument -bd ríká, ze se spustí jako SMTP démon, -L slouzí k identifikaci v systémových záznamech, a -qinterval ríká, jak casto se bude pokouset odeslat postu cekající ve fronte.
Na stav front se lze zeptat jako superuzivatel:
# dotázat se na fronty
mailq -Ac ; mailq
K príkazům lze pridat argument -v, který zapne upovídaný rezim. Pak můzeme sledovat navazování komunikace mezi programy.
V UNIXovém svete se bezne pouzívá postovní soubor ve formátu zvaném mailbox, dle doporucení FHS umístený v adresári /var/mail a nesoucí prihlasovací jméno uzivatele. Na nekterých systémech se posta ukládá v novejsím formátu maildir, coz je adresár, kde je kazdá zpráva v samostatném souboru.
.
Nejrozsírenejsí aplikací pro stahování posty je bezesporu Fetchmail od Erica S. Raymonda. Nedisponuje sice pokrocilými funkcemi jiných programů, ale zato zvládá prakticky vsechny postovní protokoly, vcetne rozsíreného ESMTP, jednorázových hesel, SSL certifikátů ci overování Kerberos a NTLM. Stazenou postu pak umí predat dalsímu MTA nebo MDA k dorucení.
Jeho základní pouzití je jednoduché - na príkazové rádce zadáme jméno serveru; program se poté zeptá na heslo a zkousí stáhnout postu.
Detaily komunikace sice můzeme upresnit i argumenty na príkazové rádce, ale pokud stahujeme postu stále ze stejných serverů, je to nevýhodné.
resením je, zalozíme-li si soubor ~/.fetchmailrc, kam vsechny tyto informace vyplníme. Popíseme si, jak takové nastavení provést. Pri nastavení si můzeme pomoci téz GUI programem fetchmailconf.
Základní parametry
-p, --protocol / proto jméno: volba protokolu. Nejcasteji POP3 nebo IMAP. Nezadáme-li nic, pouzije se AUTO (zkousí tri nejbeznejsí protokoly IMAP, POP3, POP2).
-u, --username / user jméno: jméno postovního konta. Nezadáme-li nic, pouzije se prihlasovací jméno.
pass heslo (pouze v konfiguracním souboru): Heslo postovní schránky. Nezadáme-li nic, program se pokazdé zeptá.
--auth / auth typ: Způsob overování pri prihlásení na server. Nezadáme-li nic, pouzije se password (overování heslem).
-U, --uidl / uidl: UIDL je jednoznacná identifikace zpráv v rozsírení protokolu POP3 a umozňuje programu zjistit, které zprávy jiz byly stazeny. Tato volba primeje Fetchmail, aby informaci pouzil.
-e, --expunge / expunge pocet: Vetsina protokolů maze zprávy pouze po odeslání speciálního príkazu nebo pri ukoncení spojení. Pokud se behem stahování rozpadne linka, program zacíná stahovat postu opet od zacátku. Tato volba umozňuje omezit pocet zpráv, stazených bez jejich smazání na výchozím serveru. Tato volba lehce prodlouzí komunikaci mezi zprávami (v protokolu POP3 je totiz nutné se odhlásit a znovu prihlásit).
-v, --verbose (pouze na príkazové rádce): Zapne upovídaný rezim Vhodné pri ladení, nedarí-li se stáhnout postu. (Lze zadat i -v -v.)
Spoustení
Krome standardního spoustení lze Fetchmail spustit i jako démon. Následující príkaz zajistí, ze se kazdých 900 sekund pokusí stáhnou postu ze serverů v konfiguraci.
/usr/bin/fetchmail -d 900 syslog
Fetchmail standardne dorucuje postu pomocí lokálního SMTP. Pokud nechcete na lokálním stroji spoustet zádný MTA, můzete si explicitne vyzádat prímé dorucení pres MDA, napr.:
fetchmail -m "/usr/bin/deliver"
fetchmail -m "/usr/bin/procmail -d %T"
# Toto je ekvivalent standardního chování:
fetchmail -m "/usr/sbin/sendmail -oem -f %F %T".
Zatímco RFC2822 popisuje formát dopisu, ve kterém se vyskytují pouze znaky US-ASCII, formát MIME (Multipurpose Internet Mail Extensions) dovoluje pouzít i jiné znakové sady nebo typy záznamu dat jako zvuk a video.
Formát zprávy podle RFC2822
Hlavicka a telo zprávy
Doporucení RFC822 chápe zprávu jako text clenený na jednotlivé rádky a rozdeluje ji do dvou základních cástí: na hlavicku (header) a telo (body). obsah tela zprávy nijak presneji nevymezuje - pouze ríká, ze hlavicka musí predcházet telu a telo musí být od hlavicky oddeleno nejméne jednou prázdnou rádkou (neboli: vse, co následuje za první prázdnou rádkou, je povazováno za telo zprávy).
Na hlavicku zprávy se doporucení RFC822 dívá jako na posloupnost polozek, kterým v originále ríká header fields. Kazdá polozka musí zacínat na nové rádce (a dokonce na první pozici rádky) a můze pokracovat i na dalsích rádkách (v takovém prípade ale nikoli od první pozice).
Kazdá polozka je vzdy uvozena urcitým klícovým slovem (zakonceným dvojteckou), které definuje její význam (a tím soucasne ulehcuje práci programům, které mají hlavicku analyzovat a rídit se jejím obsahem). Za tímto uvozujícím klícovým slovem (a povinnou dvojteckou) pak následuje vlastní obsah príslusné polozky.
Formát zpráv
Zpráva jsou rozdelena na rádky, na konci kazdé rádky je dvojce znaků CR a LF. Znaky jsou povoleny US-ASCII v rozmezí 1 - 127, vsechny ostatní znaky jsou povoleny pouze v standardu MIME. Kazdá rádka musí být maximálne 998 znaků dlouhá, nemela by vsak být
delsí nez 78 znaků (mimo CRLF). Důlezité je neprekracovat limit 998 znaků, protoze zprávy delsí nez 1000 znaků (i s CRLF) nejsou prijímány. Druhý limit je pro správné zobrazení v uzivatelském rozhraní, zpráva s více jak 78 znaky nemusí být správne zobrazena.
Polozky hlavicky
Doporucení RFC822 dále pamatuje i na moznost, ze původní iniciátor zprávy (nebo lépe: autor zprávy) není totozný s jejím skutecným odesilatelem. K takovéto situaci můze dojít napríklad tehdy, kdyz nekdo posílá vzkaz nekoho jiného, kdyz si prílis zaneprázdnený séf nechává odesílat zprávy svou sekretárkou, nebo také napríklad tehdy, kdyz nekdo posle príspevek do nekteré z elektronických konferencí. Pak jej totiz posle nejprve na adresu správce konference a ten ji následne rozesle vsem úcastníkům konference. Ti pak dostanou zprávu, jejímz odesilatelem je správce konference (a jiz je to clovek ci pouhý program), zatímco autorem zprávy je "Sender".
Dalsí polozkou, která souvisí s moznou disproporcí mezi autorem a odesilatelem zprávy, je polozka "Reply-To". Ta totiz explicitne ríká, kam mají být zasílány odpovedi,. Napríklad práve u elektronických konferencí je dosti podstatný rozdíl mezi tím, kdyz se odpoveď posle na adresu konference (a pak ji dostanou vsichni její úcastníci), nebo kdyz se posle prímo původnímu autorovi (a pak ji dostane pouze on). Pomocí polozky "Reply-To" lze explicitne predepsat, kam mají být odpovedi posílány. Je to uzitecné napríklad i pro uzivatele, kterí mají více pracovis, resp. svou elektronickou postu odesílají z více různých míst - pomocí této polozky si pak mohou predepsat, ze odpovedi jim mají chodit na jedno konkrétní místo. Jeste dalsí moznost nabízí polozka "Return-Path", která umozňuje predepsat,
kam má být zpráva vrácena v prípade její nedorucitelnosti.
Podobnou syntaxi jako polozka "From" (i dalsí, které jsme zmiňovali v predchozím odstavci) má i polozka "To", urcující adresáta zprávy. Jak jsme si jiz uvedli v predcházejících dílech, zprávy elektronické posty je mozné zasílat i jako tzv. kopie na vedomí (Carbon Copy), a dokonce i jako tzv. "slepé" kopie (Blind Carbon Copy) - o kterých se hlavní adresát zprávy nedozví (na rozdíl od príjemců bezných kopií, o kterých se v hlavicce svého originálu dozví). Pro specifikaci adresátů kopií jsou urceny polozky "Cc" a "Bcc", napríklad:
From: Jiri Peterka odesilatel
To: Jan Novak adresát
Cc: Petr Votava príjemce kopie
Bcc: Jan Pavelka príjemce slepé kopie
V kazdé prijaté zpráve bývá obvykle obsazen urcitý pocet polozek "Received", které obsahují záznamy o "ceste" zprávy mezi jednotlivými prenosovými slozkami - v zásade by bylo mozné ríci, ze kazdému jednotlivému "preskoku" by mela odpovídat jedna tato polozka (a jedna dalsí obvykle pripadá i na první prenosovou slozku, která zprávu prijme k odeslání). V polozkách "Received" pak můze být vyjádreno napríklad i to, jakým protokolem byla zpráva prenesena, pod jakým oznacením apod. - tyto informace jsou vetsinou urceny pro potreby ladení a resení nestandardních situací.
Dalsí polozky, na které RFC822 pamatuje, umozňují vyjádrit datum a cas, kdy byla zpráva zadána k odeslání (polozka "Date"), její predmet (polozka "Subject") apod. Dále RFC822 pamatuje napríklad i na moznost automatického presmerování (tzv. auto-forward), kdy uzivatel sice prijímá postu na urcité adrese, ale odsud si ji nechává automaticky posílat jeste nekam jinak - coz je výhodné napríklad tehdy, kdyz na urcitou dobu odcestuje nekam, kde je stále v dosahu elektronické posty, a chce-li nadále prijímat svou beznou elektronickou korespondenci. Doporucení RFC822 zavádí za tímto úcelem celou sérii polozek zacínajících prefixem "Resent-".
Telo zprávy
Na telo zpávy jsou kladena pouze 2 omezení:
1) Znaky CR LF se nesmí nikde vyskytovat oddelene.
2) Pocet znaků na rádku musí být maximálne 998 znaků, nemel by vsak mít vice jak 78 (oboje bez CRLF).
.
. Sendmail . Fetchmail . Spamassasin