Teljes virtuális levelezőszerver/postfix kiegészítések
Bevezetés
Ezen a ponton a Postfixnek megfelelően kell működnie, és a felhasználóknak a levelezőklienseken és webmailen keresztül nem szabad gondot okoznia az e-mailek biztonságos küldése és fogadása. A Postfix telepítés finomhangolása növelheti a teljesítményt, egy kicsit biztonságosabbá teheti, és egy kis további redundancia sem árt.
Benyújtás
Bevezetés a benyújtáshoz
A levélkézbesítést gyakran helytelenül a Mail Transfer Agent (MTA) 25-ös portján keresztül végzik. A leveleket valójában az Mail Submission Agent (MSA) 587-es portján kellene benyújtani. A Postfix egyszerre MTA és MSA. Számos előnye van annak, ha a kliens az MSA-hoz kézbesíti a levelet, ahogyan azt a Wikipédián is láthatjuk. A legfontosabb azonban az, hogy a nomád felhasználók még akkor is küldhetnek e-maileket, ha a 25-ös portot egy tűzfal blokkolja, mivel az 587-es port általában nyitottabb. Ezenkívül, ha csak hitelesített felhasználóknak engedjük meg az e-mail küldését, akkor akár meg is kerülhetik a spam szűrőt a kimenő üzeneteik esetében.
Beállítás
A benyújtási port a Postfix master.cf fájljában van engedélyezve. Alapértelmezés szerint megjegyzésként szerepel, beleértve annak beállításait is:
/etc/postfix/master.cfLevélbeküldés a Postfix segítségévelsubmission inet n - n - - smtpd
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
A Postfix újraindítása után a kliens értesül a STARTTLS elérhetőségéről, de ez nem kötelező (állítsa be az értéket smtpd_tls_security_level=encrypt az adatok titkosításának kényszerítéséhez), és minden levelet elutasít, kivéve a hitelesített felhasználókét.
root #/etc/init.d/postfix restartTovábbi beállítások megadhatók és felülbírálhatók, ha szükséges.
Tesztelés
A tesztelést egy levelező klienssel kell elvégezni, az smtp szerver portjaként az 587-es portot használva.
Redundancia
Bevezetés a backup-mx -be
A redundancia érdekében a Postfix a backup mx funkciót kínálja. A backup mx lehetővé teszi, hogy egy másik levelezőszerver kezelje egy domén e-mailjeit, amikor a fő levelezőszerver valamilyen okból nem válaszol. Egy backup mx szerver megpróbálja kézbesíteni az e-maileket az eredeti levelezőszerverre. Ez mind tökéletesen hangzik, azonban a backup mx mára halott. A spam tette tönkre. A jelenlegi probléma a backup mx-el az, hogy a spam miatt az e-mailek rossz irányba pattanhatnak vissza, így a backup mx szerver egy spam blokkoló listára kerülhet. Az ilyen típusú e-maileket Backscatter mail-nek nevezik. Ha egy másodlagos levelezőszervert állítanak be, annak ismernie kell az összes felhasználót az elsődleges doménről, hogy visszapattanó üzenetet küldhessen az ismeretlen felhasználók számára. Ennek egyszerű módja az, hogy az egész adatbázist szinkronizálják az elsődleges és a másodlagos levelezőszerver között. Azonban az a figyelmeztetés merül fel, hogy a backupmx jelző az adatbázis doméntáblájában a másodlagos levelezőszerveren invertálva legyen.
A backup-mx beállítása
Az adatbázis már ismeri a backup doméneket. Ha egy doménnek van backup levelezőszervere, a backupmx mező értéke "1" a domain táblában. A postfix adatbázishoz való csatlakoztatása egy fájlt igényel csatlakozási információval:
/etc/postfix/pgsql/relay_domains.cfÁtjátszó (relay) domének beállítása# relay_domains.cf
user = postfix
password = $password
dbname = postfix
#hosts = localhost
query = SELECT description FROM domain WHERE domain='%s' AND backupmx='1' AND active='1';
Ezt ezt követően be kell állítani a postfixben.
/etc/postfix/main.cfPostfix módosítása az átjátszó (relay) doménekhez# A relay_domains paraméter korlátozza, hogy a rendszer mely célállomásokra továbbítja az e-maileket.
# Részletes információkért tekintse meg a smtpd_recipient_restrictions
# leírását a postconf(5)-ben.
relay_domains = pgsql:/etc/postfix/pgsql/relay_domains.cf
A relay_domains helyes használatához:
/etc/postfix/pgsql/relay_recipient_maps.cfÁtjátszó (relay) címzettek beállítása# relay_recipient_maps.cf
user = postfix
password = $password
dbname = postfix
#hosts = localhost
query = SELECT goto FROM alias WHERE address='%s' AND active='1';
Ezt szintén be kell állítani a postfixben.
/etc/postfix/main.cfPostfix módosítása az átjátszó (relay) címzettekhez# REJECTING UNKNOWN RELAY USERS
#
# A relay_recipient_maps paraméter opcionális keresési táblázatokat határoz meg,
# amelyek tartalmazzák az összes címet a $relay_domains paraméterhez illeszkedő doménekben.
relay_recipient_maps = pgsql:/etc/postfix/pgsql/relay_recipient_maps.cf
A postfix újraindítása után a levelezőszerver most már kevésbé nyílt átjátszóként működik, és csak jóváhagyott doménekhez és jóváhagyott felhasználókhoz továbbítja az e-maileket.
Ne használja a
permit_mx_backup paramétert. Ez halott. A 'backup domének' továbbítása a levelezőszerveren keresztül, az ismert felhasználók listájára, a helyes módja ennek, de csak akkor, ha ugyanazok a felhasználók adminisztrálják őket. Még óvatosabbnak kell lenni egész domének elfogadásakor, hacsak a másik domén nem rendelkezik mindent elfogadó postafiókkal. Ebben az esetben a Backscatter mail problémát okoz, és a levelezőszerver nagy valószínűséggel feketelistára kerül.Kvóták
Bevezetés
A kvóták egy eszközt jelentenek a felhasználók számára a postafiókjuk figyelemmel kísérésére. Ezeket nagyon könnyű visszaélésre használni, ezért nem szabad kizárólag rájuk támaszkodni. Ennek ellenére többnyire jól működhetnek, és visszajelzést nyújthatnak a felhasználónak a használati szokásainak állapotáról. Az IMAP támogatja a kvóták jelentését, így a levelezőkliensek akár közvetlenül is tudják jelenteni ezt a felhasználónak. A Thunderbird ezt egy kiegészítés segítségével végzi, a roundcube pedig alapértelmezetten mutatja.
Beállítás
Az adatbázis támogatja a levelezési kvótákat, azonban a postfixnek szüksége van egy javításra ezeknek a kvótáknak a támogatásához. A vda USE jelölőzászló engedélyezi ezt a javítást a postfix számára, és lehetővé teszi a kvóták használatát.
Először az adatokat kell lekérni az adatbázisból:
/etc/postfix/pgsql/virtual_mailbox_limit_maps.cfKvóták lekérdezése az adatbázisból# virtual_alias_maps.cf
user = postfix
password = $password
dbname = postfix
#hosts = localhost
query = SELECT quota FROM mailbox WHERE local_part='%u' AND domain='%d' AND active='1';
A postfixben néhány dolgot be kell állítani az adatbázis lekérdezése mellett. Például a Lomtár mappát nem szabad beleszámítani az automatikus törlési folyamatba, amikor a Lomtár mappát egy meghatározott idő után törlik. Ezt (és szükségszerűen) a courier-imap segítségével kell megtenni.
/etc/postfix/main.cfPostfix beállítása a kvóták használatára# Support for Postfix VDA quotas
virtual_mailbox_limit_maps = pgsql:/etc/postfix/pgsql/virtual_mailbox_limit_maps.cf
virtual_mailbox_limit_inbox = no
virtual_mailbox_limit_override = yes
virtual_maildir_extended = yes
virtual_overquota_bounce = no
# virtual_maildir_limit_message_maps = hash:/etc/postifx/limit_messages
virtual_maildir_limit_message = "Sorry, the recipients mailbox is currently full. Please try again later."
virtual_trash_count = no
virtual_trash_name = ".Trash"
virtual_maildir_filter = no
A postgresql kézikönyv szerint a bigint (a kvóta) maximális értéke 9223372036854775807 lehet. Azonban csak 9223372036854774784 használható sikeresen. Ha valamilyen okból azonban 8 exabájt szükséges kvótaként, valószínűleg bölcsebb döntés lenne egyszerűen kikapcsolni a kvótát úgy, hogy a kvótát 0 bájtra állítják.
Ha a VDA kvóták be vannak állítva, ajánlott letiltani a postfix belső postafiók méretkorlátját.
/etc/postfix/main.cfEngedélyezett üzenetméret korlátjának a módosítása# Disable postfix mailbox size check
mailbox_size_limit = 0
Tesztelés
A Roundcube alapértelmezés szerint megjeleníti a lemezhasználatot, és fölé húzva részletes információkat jelenít meg. A Thunderbird rendelkezik egy Display quota kiegészítővel. Mindkettő és mások megfelelő működéséhez szükség van egy maildirsize fájlra. Ez a fájl létrehozásra és frissítésre kerül minden alkalommal, amikor a postfix kézbesít egy üzenetet, vagy amikor a courier-imap változtatásokat hajt végre. A fájl minden virtuális felhasználó gyökérlevelezési mappájában található, amely például /var/vmail/example.com/testuser/maildirsize lenne a testuser esetén a example.com alatt. Ennek megfelelően egy üzenet küldése a testuser@example.com címre létrehozza ezt a fájlt a felhasználó levelezési mappájában.
user $sendmail testuser@example.comSubject: Testmail to create quota file. No content! .
Általában nincs szükség arra, hogy manuálisan küldjünk el egy e-mail üzenetet a maildirsize fájl létrehozásához, mivel elegendő e-mail kerül kézbesítésre, ami így létrehozza a fájlt, beleértve a postfixadmin által létrehozott üdvözlő e-mailt is. Ennek ellenére a postfixadmin rendelkezik azzal a képességgel, hogy üzenetet sugározzon, amit erre a célra lehet használni.
HELO korlátozások
A hackerek, spammerek és mások információkat szerezhetnek a levelezőszervertől a HELO és EHLO parancsok használatával. A spammerek általában hamis információkat adnak meg a HELO köszöntésben, ezért az olyan szerverek, amelyek nem azonosítják megfelelően magukat, kapcsolódásának korlátozása és elutasítása csak előnyös lehet. A Postfix a smtpd_helo_restrictions változót kínálja annak beállításához, hogyan reagáljon a kapcsolódásokra. A korlátozások alapos átgondolása azonban elengedhetetlen. A szerver túl szoros lezárása azzal járhat, hogy üzeneteket elutasítanak, mert a másik szerver egyszerűen rosszul van beállítva. Egy gyors áttekintés az elérhető opciókról.
smtpd_helo_restrictions
|
Leírás |
|---|---|
reject_invalid_hostname
|
REJECT ha a HELO köszöntés nem egy DN vagy egy IP |
reject_non_fqdn_hostname
|
REJECT ha a HELO köszöntés nem egy FQDN vagy egy IP |
reject_unknown_hostname
|
REJECT ha a HELO host nem rendelkezik A vagy MX rekorddal a DNS -ben |
permit_naked_ip_address
|
PERMIT ha a HELO köszöntés egy IP |
A következő táblázat áttekintést nyújt arról, hogyan kerülnek elutasításra az üzenetek a különböző korlátozások miatt. Az X azt jelenti, hogy az üzenet elutasításra kerül, a ? azt jelenti, hogy a domén megfelelő DNS-beállításaitól függ, és az O azt jelenti, hogy az üzenet normál módon kézbesítésre kerül.
| bogus | példa | example.com | 192.0.23.58 | |
|---|---|---|---|---|
reject_invalid_hostname |
X | O | O | O |
reject_non_fqdn_hostname |
X | X | O | O |
reject_unknown_hostname |
X | X | ? | X |
Figyelje meg, hogy a
reject_unknown_hostname nemcsak hamis FQDN-eket utasít el, hanem IP-címeket is. A korlátozási lista elejére helyezve a permit_nakid_ip_address opciót, kizárólag IP-címeket engedélyezhet.Egy megfelelően beállított hálózaton az alábbi beállítások szorosak lesznek, de működőképesek.
/etc/postfix/main.cfHELO korlátozások# HELO korlátozások
smtpd_helo_restrictions = permit_sasl_authenticated, reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname
smtpd_helo_required = yes
A belső szerverek vagy belső levelező kliensek problémába ütközhetnek üzenetküldéskor, ha nincs érvényes host számítógépnév beállításuk. Ezért a helyi host számítógépnevet megfelelően kell beállítani a belső DNS-szervereken, hogy érvényes host számítógépnevekké váljanak. Ha a belső szerverek vagy kliensek nem rendelkeznek megfelelő host számítógépnevekkel, akkor egy biztonságos korlátozási lista a következő lehet:
smtpd_helo_restrictions = permit_naked_ip_address, reject_invalid_hostname. Ha szigorúbb ellenőrzésre van szükség, és a megfelelő belső host számítógépnevek beállítása nem lehetséges, egy másik lehetőség a mynetworks engedélyezése, amely a korlátozási listát a következőre módosítja: smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_unknown_hostname, reject_non_fqdn_hostname, majd vagy a mynetworks kiterjesztése a belső rendszerekkel vagy a belső hálózattal.Helyi felhasználónevek begyűjtésének megtagadása
Általában a Postfix vagy más általános MTÁ-k lehetővé teszik annak ellenőrzését, hogy egy postafiók létezik-e vagy sem. Ez a parancs hasznos lehetett a levelezés kezdeti időszakában, de manapság szinte kizárólag azok használják, akik tömeges levelezési listákat tartanak fenn, és ellenőrzik, hogy a fiókok még érvényesek-e. Ez a parancs letiltható a Postfix által.
/etc/postfix/main.cfEllenőrzés letiltása# Ne válaszoljon a VRFY parancsra.
disable_vrfy_command = yes
A Postfix újraindítása után a telnet a 25-ös portra már nem fogja megjeleníteni a 250-VRFY választ.
SMTPD Banner
Egy másik gyakran visszaélt funkció az SMTP fejléc. Néhány ország megköveteli a küldőktől, hogy tiszteletben tartsák a 'NO UCE' üdvözlő üzenetet (Nem kívánt kereskedelmi e-mail). Továbbá bölcs dolog nem közölni külső felekkel, hogy milyen MTA-t használnak vagy annak melyik verzióját. A Postfix lehetőséget nyújt az SMTP fejléc egyszerű módosítására. Keresse meg a smtpd_banner szekciót a main.cf fájlban:
/etc/postfix/main.cfSMTPD Banner cseréje# SHOW SOFTWARE VERSION OR NOT
smtpd_banner = $myhostname ESMTP NO UCE
A NO UCE technikailag egy megjegyzés. Az ESMTP-nek minden megjegyzés előtt kell szerepelnie.
Üzenet mérete
Évek óta az MTA-k között az alapértelmezett üzenetméret 10 MiB volt. A Google a Gmail szolgáltatásával 20 MiB-re emelte a szintet üzenetenként. Ha a sávszélesség nem jelent problémát, ez könnyen megvalósítható a Postfix segítségével.
/etc/postfix/main.cfEngedélyezett üzenetméret-korlát megváltoztatása# Increase maximum message size
message_size_limit = 20971520
Postfix teljesítmény
Biff
A kompatibilitási okok miatt a Postfix helyi levelezési értesítése alapértelmezetten engedélyezve van. Sok felhasználó esetén ez teljesítménycsökkenést okozhat, és mivel nincsenek helyi felhasználók, akik a biff parancsot használnák, ez biztonságosan letiltható.
/etc/postfix/main.cfA biff letiltása# Disable biff notifications
biff = no
Folyamatok
Bármely Postfix-alkalmazás egyidejű folyamatainak száma 50-re van korlátozva. Nagy terhelésű környezetekben az első akadály gyakran az aktív szolgáltatások számában jelentkezik. Kisebb rendszereknél nem szükséges aggódni emiatt a beállítás miatt.
/etc/postfix/main.cfPostfix-folyamatok számainak a növelése# Engedélyezett folyamatok számának a növelése.
default_process_limit = 75
Mielőtt növelné a folyamatok számát, gondosan meg kell vizsgálni, hogy a szerver képes-e kezelni a megnövekedett terhelést. A ps aux és top parancsok nagy segítséget nyújthatnak ebben. Meg kell vizsgálni az egyes folyamatok által használt memória százalékos arányát. Például, ha a Postfix folyamatonkénti memóriahasználata eléri a 2%-ot az 50-es folyamatkorlát mellett, a korlát 100-ra történő növelése azt jelentené, hogy a szükséges memória megduplázódik. Végül is, 2% * 50 folyamat az elérhető memória 100%-át tenné ki. Ha a szerveren más, memóriát használó folyamatok is futnak, akkor a Postfix által használt memória mennyiségének kevesebbnek kell lennie. Ugyanez mondható el a CPU-használatról is. Ha a CPU-használat 70% közelében van, akkor főként levélkézbesítéssel foglalkozik, és a Postfix az egyetlen szolgáltatás a szerveren, gyorsabb CPU-t vagy fürtözött beállítást kellene fontolóra venni. Ha más szolgáltatások is futnak a szerveren, amelyek nagyobb mennyiségű CPU-időt igényelnek, akkor azokat át lehet helyezni más, kevésbé terhelt szerverekre.
DNS felderítés
Az átbocsátási sebesség korlátozásának gyakori oka a DNS felderítések használata. Ezek lassúak lehetnek, és gyakran már jóval azelőtt problémát okozhatnak, hogy a folyamatok, a CPU vagy a memória telítődnének. Legalább egy felderítésre van szükség üzenetenként, például a kiszolgáló MX rekordjának megtalálásához. Egy helyi gyorsítótárazó DNS-kiszolgáló jelentős segítséget nyújthat, és a net-dns/dnsmasq vagy akár egy teljes net-dns/bind beállítás használata javasolt.
Levéltárolás
A Postfix több sor-mappát tart karban a /var/spool/postfix könyvtárban. Különböző Postfix alkalmazások ezen sorokon keresztül továbbítják az üzeneteket egymásnak. Ezeknek a könyvtáraknak egy külön lemezre, RAID-tömbre vagy SSD-re helyezése jelentősen javíthatja az általános teljesítményt. Emellett annak biztosítása, hogy az adott partíció noatime opcióval legyen megjelölve, nagyban segíti a lemezhozzáférést. A Postfix nem használ elérési időbélyegeket.
Több levelezőszerver
Ha egy szerver nem elegendő, akkor több levelezőszerver oszthatja meg a terhelést. Emellett a több szerver redundanciát is kínál, így érdemes megfontolni a használatukat. A terhelés több levelezőszerver között történő elosztása hatékonyan megvalósítható DNS round-robin használatával. Két lehetőség áll rendelkezésre: Vagy több A bejegyzést rendelünk a levelezőszerverhez, vagy - tisztább megoldásként - több MX bejegyzést, amelyek lehetővé teszik a prioritás meghatározását.