Postfix Dovecot MYSQL

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (Mellékletek)
a
1. sor: 1. sor:
  +
== Bevezető ==
  +
A rendszert eredetileg egy olyan projecthez terveztem, ahol a felhasználót a csatlakozást követően egy adminisztrátor bevitte a rendszerbe, és így automatikusan létrejött a fiókja. Erre a feladatra egy webes felület volt a legkényelmesebb, ezért is esett arra a választásom, hogy adatbázisban tároljam a felhasználókat. Ebben a konfigurációban nem látszik, de a useres táblához tartozott egy kibővített információkat tartalmazó tábla is, ahol a név, cím, stb adatok vannak tárolva(userIDval mint idegen kulccsal, InnoDB táblákban - MYSQL alatt csak ez támogatja), ennek köszönhetően, amikor egy felhasználót próbál a rendszer beléptetni, gyorsabb a működése. A kvóta képesség is fontos volt, hogy egy felhasználó, aki nem nézi a fiókját, spamekkel ne foglaljon több 100MB helyet. Kvótát alapesetben postfix nem támogat(patchelni lehet) és nem is olyan kifinomult, mint a dovecot megvalósítás, ahol figyelmeztető levelek küldésére, script futtatására is lehetőség van különböző határok átlépésénél. Kérés volt, hogy egységesen mindenhol felhasználónévnek ne kelljen a teljes user@domain.hu címet használni, ezért kerültek külön oszlopba a felhasználók. Ennek a döntésnek a másik oka az volt, hogy ha más országban is elindítják a céget, akkor egy helyen legyenek kezelve az adatok (a felhasználóneveknek az egész rendszerben egyedieknek kellett lenniük) ezért van domain oszlop. Mivel várhatóan nagyon sok felhasználója lett volna a rendszernek, így nem alkalmaztam azt a lehetőséget, hogy minden felhasználónak külön uid-t adjak, másrészt ez a hordozhatóságát csökkenti a rendszernek.
 
== Szerver alkalmazások kiválasztása ==
 
== Szerver alkalmazások kiválasztása ==
Az email rendszer, amit bemutatok, egy honlap rendszerhez tartozott. Szempont volt, hogy közös felhasználói adatbázis legyen és minden platform képes legyen a felhasználókat authentikálni. A rendszer minden felhasználója automatikusan kapott egy email címet.<br />
 
Az általam választott szerver alkalmazások:
 
 
* [http://en.wikipedia.org/wiki/Message_transfer_agent MTA] (Mail Transfer Agent): [http://www.postfix.org/ Postfix]. Nagyon sok levelezőszerver közül tudunk válogatrni, a postfix mellett szólt a jó dokumentáció(ha néha kicsit szegényes is), gazdag funkcionalitás, aktív fejlesztői és karbantartói gárda, széleskörben használják, szinte minden disztribúcióban elérehető. [http://cr.yp.to/qmail.html Qmail] nem tűnt jó választásnak, nem látttam ilyen könnyen illeszthetőnek a rendszerbe és még nem volt vele dolgom, új funkciók nem nagyon kerülnek bele(Kérdés ez mennyire fontos, a tárgy keretén belül többször előkerült Dan Bernstein, ha most állnék neki lehet kipróbálnám. Persze mostmár azt is értem, miért idegenkedtek tőle több helyen is a neten).
 
* [http://en.wikipedia.org/wiki/Message_transfer_agent MTA] (Mail Transfer Agent): [http://www.postfix.org/ Postfix]. Nagyon sok levelezőszerver közül tudunk válogatrni, a postfix mellett szólt a jó dokumentáció(ha néha kicsit szegényes is), gazdag funkcionalitás, aktív fejlesztői és karbantartói gárda, széleskörben használják, szinte minden disztribúcióban elérehető. [http://cr.yp.to/qmail.html Qmail] nem tűnt jó választásnak, nem látttam ilyen könnyen illeszthetőnek a rendszerbe és még nem volt vele dolgom, új funkciók nem nagyon kerülnek bele(Kérdés ez mennyire fontos, a tárgy keretén belül többször előkerült Dan Bernstein, ha most állnék neki lehet kipróbálnám. Persze mostmár azt is értem, miért idegenkedtek tőle több helyen is a neten).
 
* [http://en.wikipedia.org/wiki/Message_delivery_agent MDA] (Mail Delivery Agent): [http://www.dovecot.org/ Dovecot]. Több open source rendszert megnéztem, ezek közül a dovecot jól skálázható, robusztus. Natívan támogatja a felhasználók adatbázisban tárolását és az SSHA([http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Salted] [http://en.wikipedia.org/wiki/SHA-2 Safe Hash Algorithm]) algoritmust (Én személy szerint jelszót SSHA256 alatt nem tárolnék, MD5 és főleg a pure password tárolás, hogy elfelejtett jelszót küldjünk ki elég felelőtlen dolog //szerintem). A dovecot további előnye, hogy a levelek fiókokba helyezését is el tudja látni, így az esetlegesen eltérő mailbox megvalósítások nem okoznak hibát. Élesben kipróbáltam a [http://www.courier-mta.org/ Courier]-t is, de sokkal nagyobb volt a memóriaigénye a tesztidőszak alatt és a dovecot beállítása is könnyebben kezelhetőnek tűnt.
 
* [http://en.wikipedia.org/wiki/Message_delivery_agent MDA] (Mail Delivery Agent): [http://www.dovecot.org/ Dovecot]. Több open source rendszert megnéztem, ezek közül a dovecot jól skálázható, robusztus. Natívan támogatja a felhasználók adatbázisban tárolását és az SSHA([http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Salted] [http://en.wikipedia.org/wiki/SHA-2 Safe Hash Algorithm]) algoritmust (Én személy szerint jelszót SSHA256 alatt nem tárolnék, MD5 és főleg a pure password tárolás, hogy elfelejtett jelszót küldjünk ki elég felelőtlen dolog //szerintem). A dovecot további előnye, hogy a levelek fiókokba helyezését is el tudja látni, így az esetlegesen eltérő mailbox megvalósítások nem okoznak hibát. Élesben kipróbáltam a [http://www.courier-mta.org/ Courier]-t is, de sokkal nagyobb volt a memóriaigénye a tesztidőszak alatt és a dovecot beállítása is könnyebben kezelhetőnek tűnt.
 
* [http://en.wikipedia.org/wiki/DBMS DBMS]: [http://www.mysql.com/ MYSQL]. A MYSQL az egyik széleskörben alkalmazott adatbázis-kezelő rendszer, könnyen használható különböző programozási nyelvek alól, ami a project megvalósításánál fontos szempont volt (php, node.js, java, stb), személyes tapasztalatom csak ezzel volt (viszonylag sok) nem nagyon merült fel kérdés mit válasszak. [https://www.mysql.com/products/workbench/ MySQL Workbench] segítségével pedig az adminisztráció, tervezés és minden más folyamat is könnyen elvégezhető (kivéve, hogy utf-8 legyen (ami már szinte minden programra igaz) a felépített kliens csatorna alapértelmezetten, mert azt csak config fájlból lehet beállítani, a másik 6 működés közbe beállítható környezeti változó nem befolyásolja).
 
* [http://en.wikipedia.org/wiki/DBMS DBMS]: [http://www.mysql.com/ MYSQL]. A MYSQL az egyik széleskörben alkalmazott adatbázis-kezelő rendszer, könnyen használható különböző programozási nyelvek alól, ami a project megvalósításánál fontos szempont volt (php, node.js, java, stb), személyes tapasztalatom csak ezzel volt (viszonylag sok) nem nagyon merült fel kérdés mit válasszak. [https://www.mysql.com/products/workbench/ MySQL Workbench] segítségével pedig az adminisztráció, tervezés és minden más folyamat is könnyen elvégezhető (kivéve, hogy utf-8 legyen (ami már szinte minden programra igaz) a felépített kliens csatorna alapértelmezetten, mert azt csak config fájlból lehet beállítani, a másik 6 működés közbe beállítható környezeti változó nem befolyásolja).
+
=== POP(3) vs IMAP(4) ===
  +
Én a szervereken, amiket építettem, nem is engedélyeztem a POP3 protokollt(nem is telepítettem a dovecot-pop3 csomagot), ezért ebben a szócikkben nem is foglalkozom a beállításával, az általam fontosnak tartott érveket felsorolom. A [http://wikipedia.org/wiki/POP3 POPv3] protokoll első verzióját 1984-ben specifikálták, a 3ast pedig 1988-ban. A [http://wikipedia.org/wiki/IMAP IMAP] protokoll első verziója 1986-ban készült el (jelenleg a 4. verziót használjuk) és a POP3-nál sokkal modernebb szemléletű. Érdekesség, hogy a RAID-hez hasonlóan a mozaikszó mögötti jelentés változott: Interim Mail Access Protocol(IMAPv1) -> Interactive Mail Access Protocol(IMAPv2) -> Internet Message Access Protocol(IMAP2bis - 1993, amit késöbb IMAPv4-ben szabványosítottak és amit most értünk alatta, látszik, hogy az IMAPv3 zsákutcának bizonyult)
  +
* IMAP előnyei:
  +
** A POP3 alapértelmezett mechanizmusa, hogy letörli a levelet, amit letöltött (mint egy array.pop(), de a nevének(Post Office Protocol) ehhez semmi köze), ez több kliensen, webmailen lehetetlenné teszi az összes levelünk olvasását. Persze például a google alkalmaz egy POP3 hacket, egy külön flaget használ, amivel megjelöli a POP3 által letöltött leveleket, és azokat már nem mutatja a kliensnek és figyelmen kívül hagyja a törlési utasításokat. POP3 egyértelműen egy gépen való használatra készült és kis postafiókméretre, mára már egyik sem jellemző.
  +
** A kliens nem csak a levelek letöltésének idejére kapcsolódhat a szerverhez, hanem folyamatosan kapcsolódhat rá, így minimális késleltetéssel értesülhet új levelek érkezéséről. Ez nem teljesen triviális, hogy előny, mivel így folyamatosan rengeteg kliens csatlakozik a szerverhez, de nem feltétlen jobb, ha a türelmetlen felhasználók 5 percenként új kapcsolatot nyitnak a szerver fele, hogy érkezett-e új levelem?
  +
** Több kliens is csatlakozhat egyszerre egy adott e-mail fiókhoz. Ez a funkció mára már sokak számára hasznos, mivel elvárják az emberek, hogy ha a telefonjuk folyamatosan várja a leveleiket, akkor ettől függetlenül az asztali gépükre is letölthessék a leveleiket.
  +
** Részenkénti letöltés. A különböző MIME részeit a levélnek(képek, tömörített fájlok, stb), nem tölti le automatikusan, ez külön kezdeményezhető. Ez a funkció újra előnyös, mivel most már nem a modemes kapcsolat, hanem a telefonok sávszélessége(adatkorlátja) szab határt, nem is beszélve, hogy így a kliens a levelek meta-adatait gyorsan letölti, és egy-egy nagy méretű e-mail nem "blokkolja" az újabbakat míg azt letöltjük (olyan kliensek is amik minden adatot letöltenek offline használatra, először letöltik az összes levél meta-adatát és után külön töltik le a csatolmányokat).
  +
** Szerver oldali levél állapotok. Ha több kilenst, esetleg webmailt is használunk IMAP segítségével, ha az egyiken elolvassuk/megjelöljük/átmozgatjuk a levelünket ez mindenhol érvénybe fog lépni.
  +
** Szerver oldali keresés. Ez nyilván komoly teljesítményt foglalhat le kiszolgálói oldalon, ha valaki visszaél vele, de például a telefonom e-mail kliense a legújabb 10-20-stb levelet tárolja a különböző e-mail fiókjaimhoz. Egy webmailnél valahol mindenképpen szerver oldalon kell keresnünk (Ha a kliens oldalon keresnénk, minden adatot át kellene vinnünk a kereséshez, van amikor ez jobb lehet).
  +
** Levelek biztonsági mentésének feladata nem a felhasználó(/rendszergazda, pl. nem kell mindenkinek 1 klienst használni, szerver oldalon (remélhetőleg) eleve van redundás tárolás és rendszeres backup) feladata.
  +
* IMAP hátrányai (az extra funkciók ára):
  +
** A kliensek nem törlik a letöltött leveleiket, magasabb tárigény.
  +
** Bonyolultabb szerver logika.
  +
** Szerver oldali kereséses visszaélés, lásd fent.
  +
** Még mindig nem biztos, hogy elég. Pl: címtár, naptár, etc nem tárolható szerver oldalon.
  +
** Kétszer kell feltöltenünk az elküldött levelünket (viszont, így minden kliens azt is meg fogja kapni).
 
== Működés áttekintése ==
 
== Működés áttekintése ==
 
A levelek fogadásáról és küldéséről a postfix gondoskodik. A levelek elhelyezéséről, tartóstárba írásáról, azonosításáról pedig a dovecot. A működéshez szükséges adatokat 4 MYSQL táblában tárolja, így azok könnyen menedzselhetőek. Amikor a leveleket a postfix megkapja, átadja a különböző szűrő alkalmazásoknak, ezek egyelőre nem részei ennek az írásnak. A levelezőszerverek a leveleket a /var/vmail/ mappába teszik, a leveleket mint vmail(uid: 150) felhasználó teszik be, aki a mail(gid: 8) csoport tagja. Lehetőség van minden fiók számára saját linux felhasználó létrehozására, ezzel biztonságosabbá téve a fiók hozzáférését, ha az IMAP szerverben biztonsági rés lenne.<br />
 
A levelek fogadásáról és küldéséről a postfix gondoskodik. A levelek elhelyezéséről, tartóstárba írásáról, azonosításáról pedig a dovecot. A működéshez szükséges adatokat 4 MYSQL táblában tárolja, így azok könnyen menedzselhetőek. Amikor a leveleket a postfix megkapja, átadja a különböző szűrő alkalmazásoknak, ezek egyelőre nem részei ennek az írásnak. A levelezőszerverek a leveleket a /var/vmail/ mappába teszik, a leveleket mint vmail(uid: 150) felhasználó teszik be, aki a mail(gid: 8) csoport tagja. Lehetőség van minden fiók számára saját linux felhasználó létrehozására, ezzel biztonságosabbá téve a fiók hozzáférését, ha az IMAP szerverben biztonsági rés lenne.<br />
15. sor: 15. sor:
 
** nem tartozhat több domainhez ugyanolyan felhasználónév, vagy ha ezt szeretnénk, akkor elveszítjük az előnyöket
 
** nem tartozhat több domainhez ugyanolyan felhasználónév, vagy ha ezt szeretnénk, akkor elveszítjük az előnyöket
 
[[Fájl:mailtop.png]]
 
[[Fájl:mailtop.png]]
  +
== Tűzfal/NAT ==
  +
* A kliensek(WAN) fele minden kapcsolat TCP
  +
* "e-mail portok":
  +
** 25: SMTP port, sok szolgáltató(otthoni) tiltja, átirányítja(van ahol kikapcsolható, pl T-nél webes felületükön ki lehet, vezetékes kapcsolat esetén), ez főleg más SMTP szerverek számára van
  +
** 465: SSMTP port, titkosított SMTP, külső kliensek számára ez ajánlott
  +
** 143: IMAP port
  +
** 585: IMAP4-SSL port, ezen tapasztalat, hogy a m$ outlook nem tudja megemészteni ezekkel a beállításokkal, alapértelmezésben dovecot nem is nyitja meg
  +
** 993: IMAP4 over SSL port, igazából ez az, amit a dovecoton beállítunk
  +
** 110: POP3 port(teljesség kedvéért)
  +
** 995: SPOP3 port(teljesség kedvéért)
 
== Egy gyakorlati megvalósítás ==
 
== Egy gyakorlati megvalósítás ==
 
=== Postfix beállítása ===
 
=== Postfix beállítása ===

A lap 2012. november 3., 17:58-kori változata

Tartalomjegyzék

1 Bevezető

A rendszert eredetileg egy olyan projecthez terveztem, ahol a felhasználót a csatlakozást követően egy adminisztrátor bevitte a rendszerbe, és így automatikusan létrejött a fiókja. Erre a feladatra egy webes felület volt a legkényelmesebb, ezért is esett arra a választásom, hogy adatbázisban tároljam a felhasználókat. Ebben a konfigurációban nem látszik, de a useres táblához tartozott egy kibővített információkat tartalmazó tábla is, ahol a név, cím, stb adatok vannak tárolva(userIDval mint idegen kulccsal, InnoDB táblákban - MYSQL alatt csak ez támogatja), ennek köszönhetően, amikor egy felhasználót próbál a rendszer beléptetni, gyorsabb a működése. A kvóta képesség is fontos volt, hogy egy felhasználó, aki nem nézi a fiókját, spamekkel ne foglaljon több 100MB helyet. Kvótát alapesetben postfix nem támogat(patchelni lehet) és nem is olyan kifinomult, mint a dovecot megvalósítás, ahol figyelmeztető levelek küldésére, script futtatására is lehetőség van különböző határok átlépésénél. Kérés volt, hogy egységesen mindenhol felhasználónévnek ne kelljen a teljes user@domain.hu címet használni, ezért kerültek külön oszlopba a felhasználók. Ennek a döntésnek a másik oka az volt, hogy ha más országban is elindítják a céget, akkor egy helyen legyenek kezelve az adatok (a felhasználóneveknek az egész rendszerben egyedieknek kellett lenniük) ezért van domain oszlop. Mivel várhatóan nagyon sok felhasználója lett volna a rendszernek, így nem alkalmaztam azt a lehetőséget, hogy minden felhasználónak külön uid-t adjak, másrészt ez a hordozhatóságát csökkenti a rendszernek.

2 Szerver alkalmazások kiválasztása

  • MTA (Mail Transfer Agent): Postfix. Nagyon sok levelezőszerver közül tudunk válogatrni, a postfix mellett szólt a jó dokumentáció(ha néha kicsit szegényes is), gazdag funkcionalitás, aktív fejlesztői és karbantartói gárda, széleskörben használják, szinte minden disztribúcióban elérehető. Qmail nem tűnt jó választásnak, nem látttam ilyen könnyen illeszthetőnek a rendszerbe és még nem volt vele dolgom, új funkciók nem nagyon kerülnek bele(Kérdés ez mennyire fontos, a tárgy keretén belül többször előkerült Dan Bernstein, ha most állnék neki lehet kipróbálnám. Persze mostmár azt is értem, miért idegenkedtek tőle több helyen is a neten).
  • MDA (Mail Delivery Agent): Dovecot. Több open source rendszert megnéztem, ezek közül a dovecot jól skálázható, robusztus. Natívan támogatja a felhasználók adatbázisban tárolását és az SSHA(Salted Safe Hash Algorithm) algoritmust (Én személy szerint jelszót SSHA256 alatt nem tárolnék, MD5 és főleg a pure password tárolás, hogy elfelejtett jelszót küldjünk ki elég felelőtlen dolog //szerintem). A dovecot további előnye, hogy a levelek fiókokba helyezését is el tudja látni, így az esetlegesen eltérő mailbox megvalósítások nem okoznak hibát. Élesben kipróbáltam a Courier-t is, de sokkal nagyobb volt a memóriaigénye a tesztidőszak alatt és a dovecot beállítása is könnyebben kezelhetőnek tűnt.
  • DBMS: MYSQL. A MYSQL az egyik széleskörben alkalmazott adatbázis-kezelő rendszer, könnyen használható különböző programozási nyelvek alól, ami a project megvalósításánál fontos szempont volt (php, node.js, java, stb), személyes tapasztalatom csak ezzel volt (viszonylag sok) nem nagyon merült fel kérdés mit válasszak. MySQL Workbench segítségével pedig az adminisztráció, tervezés és minden más folyamat is könnyen elvégezhető (kivéve, hogy utf-8 legyen (ami már szinte minden programra igaz) a felépített kliens csatorna alapértelmezetten, mert azt csak config fájlból lehet beállítani, a másik 6 működés közbe beállítható környezeti változó nem befolyásolja).

2.1 POP(3) vs IMAP(4)

Én a szervereken, amiket építettem, nem is engedélyeztem a POP3 protokollt(nem is telepítettem a dovecot-pop3 csomagot), ezért ebben a szócikkben nem is foglalkozom a beállításával, az általam fontosnak tartott érveket felsorolom. A POPv3 protokoll első verzióját 1984-ben specifikálták, a 3ast pedig 1988-ban. A IMAP protokoll első verziója 1986-ban készült el (jelenleg a 4. verziót használjuk) és a POP3-nál sokkal modernebb szemléletű. Érdekesség, hogy a RAID-hez hasonlóan a mozaikszó mögötti jelentés változott: Interim Mail Access Protocol(IMAPv1) -> Interactive Mail Access Protocol(IMAPv2) -> Internet Message Access Protocol(IMAP2bis - 1993, amit késöbb IMAPv4-ben szabványosítottak és amit most értünk alatta, látszik, hogy az IMAPv3 zsákutcának bizonyult)

  • IMAP előnyei:
    • A POP3 alapértelmezett mechanizmusa, hogy letörli a levelet, amit letöltött (mint egy array.pop(), de a nevének(Post Office Protocol) ehhez semmi köze), ez több kliensen, webmailen lehetetlenné teszi az összes levelünk olvasását. Persze például a google alkalmaz egy POP3 hacket, egy külön flaget használ, amivel megjelöli a POP3 által letöltött leveleket, és azokat már nem mutatja a kliensnek és figyelmen kívül hagyja a törlési utasításokat. POP3 egyértelműen egy gépen való használatra készült és kis postafiókméretre, mára már egyik sem jellemző.
    • A kliens nem csak a levelek letöltésének idejére kapcsolódhat a szerverhez, hanem folyamatosan kapcsolódhat rá, így minimális késleltetéssel értesülhet új levelek érkezéséről. Ez nem teljesen triviális, hogy előny, mivel így folyamatosan rengeteg kliens csatlakozik a szerverhez, de nem feltétlen jobb, ha a türelmetlen felhasználók 5 percenként új kapcsolatot nyitnak a szerver fele, hogy érkezett-e új levelem?
    • Több kliens is csatlakozhat egyszerre egy adott e-mail fiókhoz. Ez a funkció mára már sokak számára hasznos, mivel elvárják az emberek, hogy ha a telefonjuk folyamatosan várja a leveleiket, akkor ettől függetlenül az asztali gépükre is letölthessék a leveleiket.
    • Részenkénti letöltés. A különböző MIME részeit a levélnek(képek, tömörített fájlok, stb), nem tölti le automatikusan, ez külön kezdeményezhető. Ez a funkció újra előnyös, mivel most már nem a modemes kapcsolat, hanem a telefonok sávszélessége(adatkorlátja) szab határt, nem is beszélve, hogy így a kliens a levelek meta-adatait gyorsan letölti, és egy-egy nagy méretű e-mail nem "blokkolja" az újabbakat míg azt letöltjük (olyan kliensek is amik minden adatot letöltenek offline használatra, először letöltik az összes levél meta-adatát és után külön töltik le a csatolmányokat).
    • Szerver oldali levél állapotok. Ha több kilenst, esetleg webmailt is használunk IMAP segítségével, ha az egyiken elolvassuk/megjelöljük/átmozgatjuk a levelünket ez mindenhol érvénybe fog lépni.
    • Szerver oldali keresés. Ez nyilván komoly teljesítményt foglalhat le kiszolgálói oldalon, ha valaki visszaél vele, de például a telefonom e-mail kliense a legújabb 10-20-stb levelet tárolja a különböző e-mail fiókjaimhoz. Egy webmailnél valahol mindenképpen szerver oldalon kell keresnünk (Ha a kliens oldalon keresnénk, minden adatot át kellene vinnünk a kereséshez, van amikor ez jobb lehet).
    • Levelek biztonsági mentésének feladata nem a felhasználó(/rendszergazda, pl. nem kell mindenkinek 1 klienst használni, szerver oldalon (remélhetőleg) eleve van redundás tárolás és rendszeres backup) feladata.
  • IMAP hátrányai (az extra funkciók ára):
    • A kliensek nem törlik a letöltött leveleiket, magasabb tárigény.
    • Bonyolultabb szerver logika.
    • Szerver oldali kereséses visszaélés, lásd fent.
    • Még mindig nem biztos, hogy elég. Pl: címtár, naptár, etc nem tárolható szerver oldalon.
    • Kétszer kell feltöltenünk az elküldött levelünket (viszont, így minden kliens azt is meg fogja kapni).

3 Működés áttekintése

A levelek fogadásáról és küldéséről a postfix gondoskodik. A levelek elhelyezéséről, tartóstárba írásáról, azonosításáról pedig a dovecot. A működéshez szükséges adatokat 4 MYSQL táblában tárolja, így azok könnyen menedzselhetőek. Amikor a leveleket a postfix megkapja, átadja a különböző szűrő alkalmazásoknak, ezek egyelőre nem részei ennek az írásnak. A levelezőszerverek a leveleket a /var/vmail/ mappába teszik, a leveleket mint vmail(uid: 150) felhasználó teszik be, aki a mail(gid: 8) csoport tagja. Lehetőség van minden fiók számára saját linux felhasználó létrehozására, ezzel biztonságosabbá téve a fiók hozzáférését, ha az IMAP szerverben biztonsági rés lenne.
A felhasználókról külön tároljuk a felhasználónevüket és a domainjüket, amihez az emailcím tartozik, ennek megvannak a maga sajátosságai.

  • előnyök
    • azonosításnál elég a felhasználónév megadása, nem kell a teljes emailcímet megadni
    • ha más alkalmazás használja a felhasználói adatbázist, a felhasználók azonosítása egyszerűbb
  • hátrányok
    • nem tartozhat több domainhez ugyanolyan felhasználónév, vagy ha ezt szeretnénk, akkor elveszítjük az előnyöket

Fájl:mailtop.png

4 Tűzfal/NAT

  • A kliensek(WAN) fele minden kapcsolat TCP
  • "e-mail portok":
    • 25: SMTP port, sok szolgáltató(otthoni) tiltja, átirányítja(van ahol kikapcsolható, pl T-nél webes felületükön ki lehet, vezetékes kapcsolat esetén), ez főleg más SMTP szerverek számára van
    • 465: SSMTP port, titkosított SMTP, külső kliensek számára ez ajánlott
    • 143: IMAP port
    • 585: IMAP4-SSL port, ezen tapasztalat, hogy a m$ outlook nem tudja megemészteni ezekkel a beállításokkal, alapértelmezésben dovecot nem is nyitja meg
    • 993: IMAP4 over SSL port, igazából ez az, amit a dovecoton beállítunk
    • 110: POP3 port(teljesség kedvéért)
    • 995: SPOP3 port(teljesség kedvéért)

5 Egy gyakorlati megvalósítás

5.1 Postfix beállítása

5.1.1 main.cf

Beállítások, amik eltérnek az alapértékektől (teljes fájl a mellékletben).

  • Dovecot SASL autentikáció beállítása:
smtpd_sasl_type = dovecot
#/var/spool/postfix/private/auth - dovecot auth socket
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtpd_sasl_authenticated_header = yes
  • Hálózati paraméterek:
# megjelenítendő hostnév
myhostname = domain1.hu
myorigin = domain1.hu
mydestination = localhost.domain1.hu, localhost
# azok a hálózatok amiket biztonságosnak ítélünk és bizonyos ellenőrzéseket átugrunk ezekről a címekről
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
# minden interfacen fogad leveleket
inet_interfaces = all
# több subnethez is kapcsolódik a server, megadhatjuk az interfacet amin keresztül kapcsolatokat kezdeményez a szerver
default_transport = 10.0.0.24
mynetworks_style = host
  • Levelek elhelyezésére vonatkozó információk:
virtual_mailbox_base = /var/vmail
virtual_uid_maps = static:150
virtual_gid_maps = static:8
  • Szerver használat
#elvárjuk hogy küldjön a kilens HELO-t
smtpd_helo_required = yes
#spammerek idejét pocsékoljuk
#és a smtpd_helo_restrictions elfogad smtpd_recipient_restrictions és smtpd_relay_restrictions elemeket, mivel késöbb is lefuthat az ellenőrzés
smtpd_delay_reject = yes
  • Listák amiken végighald postfix, hogy kitől fogad levelet. A listán végighaladva, ha az egyik feltétel teljesül, akkor elutasítja/továbbengedi a levelet.
    • általános elemek:
      • permit: a listák végén használható, ezzel ha minden más teszten átment elfogadjuk a levelet
      • reject: permithez hasonlóan a listák végére, ezzel elutasítjuk a levelet
      • warn_if_reject: nem különálló elem, reject állítások elé tehető, így "reject_warning" bejegyzés kerül a log fájlba, főleg debuggolás esetén hasznos
      • permit_mynetworks: a mynetworks listában megadott hálózatok/IP címek számára engedélyezi a hozzáférést, ezzel a belső hálózatot/gépeket nem vetjuk alá további ellenőrzésnek(pl webserver, belső levelezés, etc)
      • reject_unauth_pipelining: "Early talker"-ek szűrése, megnézi a szerver hogy az adott SMTP commandnak megfelelő adatokat küldött-e a kliens
      • permit_sasl_authenticated: akik bejelentkeztek azokat továbbengedjük
    • smtpd_client_restrictions: kliens alapú szűrés, csatlakozáskor
      • példa:
        smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client dnsbl.njabl.org
      • reject_rbl_client <domain>: Domain-alapú feketelisták használata
    • smtpd_helo_restrictions: HELO ellenőrzések
      • példa:
        smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, permit
      • check_helo_access(table): egy adatbázis, hogy HELO(EHLO) üzenetnél küldött domain mi lehet
    • smtpd_sender_restrictions: SMTP MAIL FROM utasításon(feladó) hajtja végre
      • példa:
        smtpd_sender_restrictions =  reject_authenticated_sender_login_mismatch, permit_sasl_authenticated, permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit
      • reject_authenticated_sender_login_mismatch: egy gyakran kihagyott, de szerintem az egyik legfontosabb ellenőrzés, a belépett felhasználók nem küldhetnek csak a saját felhasználónevükkel megegyező feladóval címzett levelet (vagy más szabályra illeszkedő). Elég nagy probléma, hogyha bármelyik felhasználónk küldhet a root, administrator, accounting, etc nevében levelet!
      • reject_non_fqdn_sender: visszautasítjuk a levelek ha a feladó domain nem FQDN
      • reject_unknown_sender_domain: visszautasítjuk azokat a leveleket, amik feladóihoz nem mi kézbesítünk és nincs DNS A, MX rekordja vagy ezek hibásak
    • smtpd_recipient_restrictions: SMTP 'RCPT TO' utasításon(címzett) hajtja végre
      • példa:
        smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_pipelining, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
      • reject_non_fqdn_recipient: visszautasítjuk a levelek ha a címzett domain nem FQDN
      • reject_unknown_recipient_domain: visszautasítjuk az a levelet amit nem mi kézbesítünk és nincs DNS A, MX rekordja vagy ezek hibásak
      • reject_unauth_destination: visszautasítjuk a levelet hogyha a domain nem szerepel a transzport listánkban vagy a szerver egyéb azonosítójával
      • check_policy_service inet:127.0.0.1:10023: Postgray ellenőrzés
  • MYSQL felé való átjárás, részletek az adatbázis tábláknál. Ahova több lekérés is tartozik, ott sorban halad végig rajtuk, ha nem talál illeszkedéset.
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf, mysql:/etc/postfix/mysql_virtual_email2email.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
transport_maps = mysql:/etc/postfix/mysql_virtual_transports.cf
smtpd_sender_login_maps = mysql:/etc/postfix/mysql_virtual_email_verify.cf
  • Levelek virusírtónak való átadása:
content_filter = amavis:[127.0.0.1]:10024
  • Levelek fiókokba helyezése dovecotnak való átadása:
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

5.1.2 master.cf

A master.cf a postfix kapcsolatait leíró fájl.

  • beérkező levelek számára az smtp(25) és az ssl(465) port
smtp      inet  n       -       -       -       -       smtpd
smtps     inet  n       -       -       -       -       smtpd
  • tartalom szűrők fele
amavis  unix    -       -       -       -       2       smtp
        -o smtp_data_done_timeout=1200
        -o smtp_send_xforward_command=yes
        -o disable_dns_lookups=yes
        -o max_use=20
127.0.0.1:10025 inet    n       -       -       -       -       smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_delay_reject=no
        -o smtpd_client_restrictions=permit_mynetworks,reject
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o smtpd_data_restrictions=reject_unauth_pipelining
        -o smtpd_end_of_data_restrictions=
        -o mynetworks=127.0.0.0/8
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000
        -o smtpd_client_connection_count_limit=0
        -o smtpd_client_connection_rate_limit=0
        -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
  • dovecot fele a levelek továbbítása
dovecot unix    -       n       n       -       -       pipe
        flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/dovecot-lda -d $(recipient)

5.1.3 Adattárolás és adatbázis kapcsolat

  • Célszerű egy külön táblát és saját felhasználót létrehozni postfixnek és dovecotnak és csak olvasási jogot adni az accountra. A managementet egy külön felhasználóval lehet végezni.
  • Két táblában van 'active' oszlop ezeket a sorokat a lekérések csak 1 érték esetén veszik figyelembe (ezt minden táblánál meg lehetne tenni, de a többinél ennek gyakorlati haszna nem lenne). Ennek a segítségével egy átirányítás vagy felhasználói fiók ideiglenesen is kikapcsolható.
  • Ebben a konfigurációban a kvóta byteokban értendő, 0 esetén a dovecot nem alkalmaz korlátozást.


Adattáblák felépítése:

  • users:
CREATE TABLE `users` (
  `userID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user` varchar(128) NOT NULL,
  `domain` varchar(128) NOT NULL,
  `password` varchar(128) DEFAULT '',
  `active` int(11) NOT NULL DEFAULT '0',
  `quota` int(10) unsigned NOT NULL DEFAULT '10485760',
  PRIMARY KEY (`userID`)
)
  • users példaadatok:
+--------+---------+------------+----------------------------------------------------------+--------+----------+
| userID | user    | domain     | password                                                 | active | quota    |
+--------+---------+------------+----------------------------------------------------------+--------+----------+
|      3 | test    | domain1.hu |apfAlBBFtlYefTNlFF9+RZ3Xdz8og5E/86upbmrCw64tI1Z8cTNXMQ==  |      1 | 10485760 |
+--------+---------+------------+----------------------------------------------------------+--------+----------+
  • domains:
CREATE TABLE `domains` (
  `domainID` int(11) NOT NULL AUTO_INCREMENT,
  `domain` varchar(45) NOT NULL,
  PRIMARY KEY (`domainID`)
)
  • domains példaadatok:
+----------+------------+
| domainID | domain     |
+----------+------------+
|        1 | domain1.hu |
|        2 | domain2.hu |
+----------+------------+
  • forwardings:
CREATE TABLE `forwardings` (
  `forwardingsID` int(11) NOT NULL AUTO_INCREMENT,
  `source` varchar(128) NOT NULL,
  `destination` varchar(128) NOT NULL,
  `active` int(11) NOT NULL DEFAULT '1',
  PRIMARY KEY (`forwardingsID`)
)
  • forwardings példaadatok:
    • 1: minden nem létező címre szóló levelet a lost postafiókba továbbítunk
    • 2-5: a különböző adminisztrációs címeket az admin postafiókba továbbítjuk
+---------------+--------------------------+------------------+--------+
| forwardingsID | source                   | destination      | active |
+---------------+--------------------------+------------------+--------+
|             1 | @domain1.hu              | lost@domain1.hu  |      1 |
|             2 | postmaster@domain1.hu    | admin@domain1.hu |      1 |
|             3 | root@domain1.hu          | admin@domain1.hu |      1 |
|             4 | hostmaster@domain1.hu    | admin@domain1.hu |      1 |
|             5 | administrator@domain1.hu | admin@domain1.hu |      1 |
+---------------+--------------------------+------------------+--------+
  • transport:
CREATE TABLE `transport` (
  `transportID` int(11) NOT NULL AUTO_INCREMENT,
  `domain` varchar(45) DEFAULT NULL,
  `transport` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`transportID`)
)
  • transport példaadatok: mind a két domainünket helyben kiszolgáljuk, nem továbbítjuk (pl. ha másnak az MX tartalék levelezőszervere vagyunk, az ő elsődleges szervere felé továbbítunk)
+-------------+----------------+-----------+
| transportID | domain         | transport |
+-------------+----------------+-----------+
|           1 | domain1.hu     | :         |
|           2 | domain2.hu     | :         |
+-------------+----------------+-----------+

A /etc/postfix/ mappába a következő fájlokra van szükség, amik az adatbázissal kötik össze. Mivel minden fájlnak tartalmazni kell a jelszót, ezeknek a fájloknak a hozzáférésére fokozottan figyeljünk oda!

  • Miden fájl elejére be kell illeszteni az adatbázis kapcsolat adatait, ezek az adatok:
user = <adatbázis felhasználónév - mail>
password = <adatbázis jelszó - ****>
hosts = <adatbázis címe - x.x.x.x>
dbname = <adatábzis tábla neve - mail>
  • mysql_virtual_email2email.cf - virtual_alias_maps: felhasználók azonosítására szolgál
query = SELECT concat(user, '@', domain) FROM users WHERE user='%u' AND domain="%d"
query = SELECT destination FROM forwardings WHERE source='%s' AND active = '1'
query = SELECT domain FROM domains WHERE domain='%s'
  • mysql_virtual_email_verify.cf - smtpd_sender_login_maps: bejelentkezett felhasználó emailcímének lekérdezésére szolgál(a dokumentáció alapján a kérés hibásnak tűnhet, több órás debuggolás után ez a kérés működik, teljes email címmel nem sikerült életre keltenem a funkciót)
query = SELECT user FROM users WHERE user='%u'
  • mysql_virtual_mailbox_maps.cf - virtual_mailbox_maps: a felhasználók fiókjainak a helyét adja meg
query = SELECT CONCAT(domain,'/',user) FROM users WHERE user='%u' AND active = '1'
query = SELECT transport FROM transport WHERE domain='%s'

5.2 Dovecot beállítása

A különböző konfigurációs fájlok előtt a számok a fájlok végrehajtásának sorrendjét garantálják. Az IMAP modult és portot(143-IMAP, 993-IMAPS) nem kell engedélyezni, mivel ha fent van az dovecot-imap csomag magától betölti. Ezekkel a beállításokkal a 143as titkosítatlan IMAP porton keresztül sem engedjük a klienseinknek a titkosítatlan kapcsolatot.

  • /etc/dovecot/conf.d/10-auth.conf - authentikációs beállítások
# azonosítás csak titkosított csatornán
disable_plaintext_auth = yes
# legtöbb levelező ismeri és használja a 'plain' authentikációt, de az outlook csak a 'login' metódust
auth_mechanisms = plain login
# includeoljuk a saját adatbázis fájlunkat
!include auth-sql.conf.ext
  • /etc/dovecot/conf.d/10-mail.conf - levelek
# postafiókok helye
mail_location = maildir:/var/vmail/%d/%n
# levelek írásához/olvasásához használt felhasználó, és csoport
mail_uid = vmail
mail_gid = mail
# ezeknek az értékeknek ebben a konfigurációban nincs gyakorlati jelentősége 
first_valid_uid = 150
last_valid_uid = 150
first_valid_gid = 8
last_valid_gid = 8
# meg kell adni a plugin könyvtárat, ha használni akarunk kvótát
mail_plugin_dir = /usr/lib/dovecot/modules
  • /etc/dovecot/conf.d/10-master.conf - authentikációs socketek beállítása
service auth {
# dovecot saját folyamatai számára az authentikációs unix socket
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    group = mail
  }
# postfix számára az authentikációs unix socket
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
}
  • /etc/dovecot/conf.d/20-imap.conf - imap specifikus beállítások
# engedélyezni kell a kvótát imapon felül
  mail_plugins = $mail_plugins imap_quota
  • /etc/dovecot/conf.d/auth-sql.conf.ext - az alkalmazott DBMS specifikálása:
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
  • /etc/dovecot/conf.d/90-quota.conf - kvóta beállítások
plugin {
  quota = maildir:User quota
  quota_rule = *:bytes=1000000
}
  • /etc/dovecot/dovecot-sql.conf.ext - dovecot mysql lekérései:
driver = mysql
connect = host=<adatbázis címe - x.x.x.x> dbname=<adatbázis felhasználónév - mail> user=<adatábzis tábla neve - mail> password=<adatbázisjelszó - ****>
default_pass_scheme = SSHA256
password_query = SELECT user as user, password, concat('/var/vmail/', domain,'/%n') as userdb_home, concat('maildir:/var/vmail/', domain,'/%n') as userdb_mail, 150 as userdb_uid, 8 as userdb_gid FROM users WHERE user = '%n' AND active ='1'
user_query = SELECT concat('/var/vmail/', domain,'/%n') as home, concat('maildir:/var/vmail/', domain,'/%n') as mail, 150 AS uid, 8 AS gid, concat('*:bytes=', quota) AS quota_rule FROM users WHERE user = '%n' AND active = '1'

6 Mellékletek

  • Egy php class ami a dovecot számára is olvasható formátumban állít elő SSHA256 jelszavakat. A bemeneteket sehol sem ellenőrzi, ez nem is ennek az osztálynak a felelőssége! Elvileg a 8 byte(karakter)-nyi só("salt") az feleslegesen hosszú az SHA256 elegendően jó hash, hogy egyetlen byte is elég legyen, ha valaki spórolni akar az adatázissal akkor rövidebb értéket is lehet választani.
<?php
class Crypt {
    public static $allowedABC = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
    public static $allowed =    '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz{|}~[\]^_!#$%&()*+,-./`:;<=>?';
    public static function authenticate($ssha, $password) {
        $salt = substr(base64_decode($ssha, true), 32);
        if(Crypt::calculatePasswordHash($password, $salt) == $ssha) {
            return true;
        } else {
            return false;
        }
    }
    public static function generatePasswordHash($password) {
        $salt = Crypt::randomCharsFull(8);
        return base64_encode(hash('sha256', $password . $salt, TRUE) . $salt);
    }
    public static function calculatePasswordHash($password, $salt) {
        return base64_encode(hash('sha256', $password . $salt, TRUE) . $salt);
    }
    public static function randomCharsFull($length){
        $string = '';
        $limit = strlen(Crypt::$allowed);
        for($i = 0 ; $i < $length ; $i++) {
            $string .= substr(Crypt::$allowed, mt_rand(0, $limit-1), 1);
        }
        return $string;
    }
    public static function randomCharsAbc($length){
        $string = '';
        $limit = strlen(Crypt::$allowedABC);
        for($i = 0 ; $i < $length ; $i++) {
            $string .= substr(Crypt::$allowedABC, mt_rand(0, $limit-1), 1);
        }
        return $string;
    }
}
?>

2 rövid segédfájl, hogy consoleból is könnyen lehessen jelszót generálni, azért nem közvetlen a php fájlt hívom meg, hogy a console logban ne legyen jelszószivárgás. Php futtatáshoz szükséges a php5-cli csomag (ha webszerveres gépen futtatod valószínűleg fent lesz, más gépeken nem valószínű).

  • mkpwd.php:
<?php
require_once 'Crypt.php';
echo ''.Crypt::generatePasswordHash($argv[1]);
?>
  • pwd.sh:
#!/bin/bash
read -s -p "Type password:" pwd
echo -e "\nPassword SSHA256 hash:"
php mkpwd.php $pwd
echo -e ""
  • működés közben:
lorinc@carpoon:~/php$ ./pwd.sh 
Type password:
Password SSHA256 hash:
zl+M7Qbe0PzF1dprF4yE9iYyEQg03slmVI1cgZ8r6fBSbDsvfT5FPQ==
Személyes eszközök