Emailové služby: Základy pro provozování

2.5.2022 13:20 | Přečteno: 3909× | plky | poslední úprava: 29.6.2023 18:24

Stále se setkávám s případy, kdy má někdo problém s provozem vlastního emailového serveru. Kde se tedy dělají základní chyby?

Dnes není rok 2000

Podobně jako ve všem, i v emailových službách probíhá vývoj. Problém je, že toto se občas týká i samotných uživatelů, kteří se tak rychle nedokážou adaptovat na změny jako lidi z IT. Ale není to jen o uživatelích, i někteří správci žijí stále někde v roce 2000.

Nejčastější chyby

Toto je třeba mít pořešeno v samotném základu:

1) Správně nastavené DNS

Je potřeba mít správně nastavené dns. Mít vytvořený A a AAAA, na něj pak navázaný MX záznam:

dig @8.8.8.8 devaine.cz mx
devaine.cz. 900  IN  MX  10 smtp.devaine.cz.

2) Jen jeden PTR

RFC říká, že je akceptován jen jeden rDNS / PTR záznam. Pokud tedy máme k "A" záznamu vytvořeno více PTR, nastane problém. Je tedy třeba mít jen toto:

# MX
dig @8.8.8.8 devaine.cz mx
devaine.cz. 900  IN  MX  10 smtp.devaine.cz.

# A
dig @8.8.8.8 smtp.devaine.cz
smtp.devaine.cz.  900   IN   A   250.600.19.146

# PTR
dig @8.8.8.8 -x 250.600.19.146
146.19.600.250.in-addr.arpa. 900 IN  PTR  smtp.devaine.cz.

Pokud budeme mít více "PTR", tak mailserver vezme první "PTR" v pořadí a když nebude souhlasit s "A", na který směřuje "MX", tak email odmítne, nebo hodí do spamu. Jednou jsem na toto narazil s T-Mobile, kdy jsem po nich chtěl vytvořit pár "A" záznamů a oni k nim automaticky vytvořili i "PTR" a problém byl na světě, protože na té veřejné IP běžely i emaily. Některé testy mailových služeb tento problém neodhalí.

3) SPF, ADSP, DKIM a DMARC je celkem nutnost

Je třeba mít správně nastaveny tyto politiky. Tj. je třeba podepisovat emaily pomocí DKIM, mít správný certifikát zanesený v DNS pod správným txt záznamem.

Pomocí dns TXT ADSP záznamu si správně definujeme, jak se chovat k DKIM.

Pomocí SPF si v txt zánamu nastavíme důvěryhodné servery, ze kterých mohou chodit emaily jménem naší domény. Je třeba brát v potaz limitaci počtu SPF položek v záznamu, resp. to, že SPF má limit na počet DNS lookupů (10). Tento limit je nastaven úmyslně, aby nedošlo k DoS / DDoS. Příklad vhodného nastavení (akceptuj emaily z IP "A" dns záznamu + IP z "MX" dns záznamu, ostatní odmítej):

dig @8.8.8.8 devaine.cz txt
"v=spf1 a mx -all"

Ještě upozorňuji, že u spf záznamu je problém s velkými písmeny. Tj. např. toto může být problém "v=spf1 a MX -all". RFC mluví o case-insensitive, ale zase se mluví o tom, že některá řešení nemají podporu pro uppercase.

Pomocí DMARC si pak zabalíme všechny předchozí politiky do jednoho pravidla. Příklad pravidel:

dig @8.8.8.8 _dmarc.devaine.cz txt
"v=DMARC1;p=reject;sp=reject;adkim=r;aspf=r;pct=100"

Kdo si chce jednoduše zkontrolovat záznamy, je tu třeba skvělý nástroj:
www.dmarcanalyzer.com/spf/checker/

4) Pozor na ipv6

Další chybou bývá, že server má přidělenou ipv6, ale správce to ignoruje. Mailserver pak odesílá emaily přes ipv4 a ipv6 a náhodně se pak nedoručují (což jsou ty, co se odeslaly přes ipv6)

5) Blacklisty a bacha na ipv6

Je potřeba monitorovat blacklisty a kontrolovat, zda na nich náš server není. Opět, pokud máme ipv6, tak nezapomenout kontrolovat i ipv6 adresu. Další problém je, že některé blacklisty dávají na blacklist né konkrétní ipv6 adresu, ale celý segment, do kterého adresa patří. Příklad pár blacklistů:

• mxtoolbox.com
• dnsbl.info
• ip-blacklist-checker

Dále je dobré zmínit, že není problém si zajistit kontrolu blacklistů automaticky. Buď vlastním skriptem, nebo lze využít služby třetích stran, které jsou za některých podmínek zdarma a jakmile se někde objevíte, budou vás o tom informovat.

6) Oddělené mailové služby od ostatního provozu

Pokud se provozuje mailserver v rámci firmy, měla by být jeho veřejná IP jiná, než ta, přes kterou přistupují uživatelé ze stanic na internet. Je to kvůli tomu, že na blacklisty se dá dostat nejen spamováním, ale i nějakými jinými typy útoků (zavirovaná stanice třeba hodí dotazy někam na http/https, což může danou IP dostat na blacklist také).

7) Bacha na generování NDR (Non-Delivery Notifications)

Generování zpráv o nedoručitelnosti při každém problému s doručením je chyba. Toho využívají spameři. Je třeba např. emaily na neexistující adresáty odmítat na úrovni smtp komunikace a né generovat NDR zprávy, ty posílat v odpovědích a generovat tak provoz a vlastně spam útok. Jinými slovy, nevypínat NDR, ale pořádně si ošetřit příchozí komunikaci.

8) Více smtp serverů / více MX

Bacha na to, někdo provozuje více smtp serverů, třeba dva. Jeden považuje za primární, druhý za záložní. Priority má v DNS nastaveny správně, primární má prioritu 10, záložní 20. Problém je, že priorita nebývá reálně akceptována a stává se, že vám budou přistávat maily na oba servery. Je tedy třeba myslet na to, že všechny fce a vše okolo by mělo být nastaveno u všech serverů správně a nemyslet si, že na záložní server něco nasadím "až někdy".

9) Automatické přesměrování emailů na jiný mailserver

Přesměrování emailů je v dnešní době nefunkční věc, protože SPF, DKIM, DMARC apod. Pokud "franta@seznam.cz" pošle email na "lukas@devaine.cz", a ten bude mít nastaveno přesměrování na "lukastralalalalalal@gmail.com", tak na gmail dorazí email, který se bude tvářit jako od "franta@seznam.cz", ale nepřijde od seznam serveru, ale z jiného. To bude vyhodnoceno jako spam. Při opakování se může "lukas@devaine.cz" dostat na blacklist, nebo pak i rovnou celý server, kde má schránku. Někdo může říci, že existuje rozdíl mezi přesměrováním a přeposíláním. To je otázkou, jak je konkrétní věc implementována, zda je správně udělán překlad (ve smyslu do češtiny apod.) v té a oné službě apod. Tj. zda se v mnoha případech pod "přeposílání" neskrývá ve skutečnosti "přesměrování". Gmail, ale i další služby umožňují vybírat emaily ze vzdálené schránky. Místo tedy řešení nějakého přeposílání/přesměrování, je 100x lepší si nastavit vybírání. Ano, vybírání není okamžité, ale provádí se v nějakých intervalech. Pořád ale lepší, než se vystavovat možnému umístění na blacklist, nebo nedoručení emailu.
Argumenty typu: "Ale ono to fungovalo.", jsou mimo. Prostě ne, nedělat to.

10) Otestujte si emailové služby pomocí třetí strany

Takovým základem je třeba použít službu jako mail-tester.com. Prostě vám služba vygeneruje unikátní emailovou adresu, na kterou zašlete email. Poté vám to tato služba vyhodnotí a řekne, co máte špatně. Bacha, neodhalí vše, ale pro první nástřel a rychlý základní přehled je to velmi dobré.

11) Uživateli se občas nedoručí emaily, které poslal

Občas stále narážím na nevhodně nastaveného klienta. Né u nás, ale v logách to vidím na těch odesílatelích druhých stran, co k nám posílají emaily. smtp servery ISP jsou dávno tabu. Může se stát, že uživatel z telefonu i notebooku posílá emaily bez problémů, ale pak má třeba přidaný účet ještě doma a tam mu to nejde, protože si nastavil odchozí server podle doporučení ISP. Má více zařízení, jedno špatně nastaveno, pracuje na více zařízení relativně najednou atd. Je tedy potřeba dobře koukat do logů a správně je vyhodnocovat a myslet na to, že uživatel je schopný všeho.

12) Gmail mi odmítá emaily a nevím proč

V první fázi si opravdu zkontrolujte všechny předešlé kroky a nastavení. Dále si ověřte v logách mailserveru, zda opravdu nějaký váš uživatel nějak nespamuje, nerozesílá nějak nevhodně hromadné emaily apod.

U Gmailu se můžete zdůvěryhodnit přes jejich Postmaster Tools. Ve zkratce jde o to, že si pro vaší domény vygenerujete u Google dns záznam, který si pak vložíte do svého dns k doméně a Google si tak ověří, že jste trochu důvěryhodní. Není to žádná spása, ale dá vám to nějaké plusové body.

V poslední fázi můžete zkusit kontaktovat Google přes tento web form: Sender Contact Form

Messages missing a valid messageId header are not
Touto hláškou může gmail odmítat emaily. Je to kvůli tomu, že od 11/2022 zavedl google nutnost, že nové emailové komunikace musí mít zavedený SPF a DKIM politiky.
Podrobnější info viz: Help prevent spoofing and spam with DKIM.

13) Microsoft mi odmítá emaily

Opět, zkontrolujte si všechny předešlé kroky. Pokud na nic nepřijdete, máte možnost se obrátit na MS přes tento form: Support Request.

14) Rozesílání newsletterů

Lidi mají pocit, že o jejich newsletter někdo stojí. Většinou tomu tak není a je to považováno za spam. To pak může být problém. Newslettery by mělo jít zrušit, nějak spravovat, vyhodnocovat atd. Není tedy vůbec vhodné k tomu používat běžného emailového klienta. Rozjeďte bokem, na jiné IP, nějaký systém, jako např. phplist a provozujte to na oddělené IP, se všemi vlastnostmi (SPF, DKIM, DMARC apod.). Snažte se to co nejvíce oddělit od produkce, aby když nastane problém, tak to ovlivnilo jen rozesílání novinek.

15) Zdůvěryhodňovací servery

Ještě existují služby třetích stran, které se snaží vytvořit whitelist důvěryhodných serverů. Dříve to možná nějaký smysl mělo, ale myslím si, že již nejsou tak aktuální a tak využívané. Příkladem budiž třeba dnswl.org. Osobně nikde nepoužívám, dřív jsem nad tím přemýšlel, ale dnes už to nemá smysl.

16) Greylisting

Toto funguje tak, že se odmítne první email a čeká na jeho opětovné doručení. Tím se dá velmi jednoduše eliminovat určitý druh spamu (tj., že druhá strana není nějaký infikovaný počítač, ale regulérní mailserver). Problém je ono zpoždění. Většinou se důvěryhodnost (greylist) počítá jako kombinace "odesílatel + adresát + server odesílatele". Pokud dojde k počátečnímu ověření, tak další emaily nejsou již zpožďovány. Greylist si lze vést i vlastní, statický, k eliminaci některých zpoždění se servery, o kterých víme, že jsou ok.
Dřív nebyl cloud, dřív měl každý jeden server atd. Dávalo to smysl. Dnes je spousta cloudových služeb, spousta firem už začíná mít více jak jeden server. Když tedy Greylisting poprvé odmítne email, tak ho začne v dalším pokusu doručovat většinou jiný server z cloudu. Když má cloud třeba 1000 serverů, tak se může stát, že email se nezpozdí o 10min, ale třeba o 3 dny, nebo se vůbec nedoručí. To je důvod, proč se od tohoto řešení čím dál více ustupuje. Ono i v dnešní době se trochu jinak spamuje, takže technika greylistu už je zastaralá a přestává dávat smysl i z tohoto pohledu.

Opatrně tedy s nastavováním a provozováním Greylistingu.

Má smysl v dnešní době provozovat vlastní smtp?

Samozřejmě. Někdo tvrdí, že už to nejde, že je problém s doručováním velkým firmám apod. Já si to nemyslím a podle mých zkušeností jsem ještě nenarazil na problém, který by tomu bránil. Provozuji pár firmám webhostingy (jsou tam i nějaké úřady) a no problemo. Pak mám jednoho paranoidního známého, kterého jsem musel z běžných mailových hostingů stáhnout a platí si VM, kterou mu spravuji. Celé je to kvůli tomu, že jakmile dostane nějaký divný email, nebo se nějaký email nedoručí, nebo něco, tak potřebuje nutně vědět, co se stalo. Když maily provozuje někdo jiný, tak nastává nekonečné kolečko požadavku na support a člověk dělá nekonečného prostředníka. Takto mám odpověď hned, bez starostí, bez čekání, kouknu a vidím. Mohu mu jednoduše potvrdit, že server adresáta email přijal a on je relativně z obliga atd. Důvody pro vlastní provoz mohou být samozřejmě různé. Já jen tvrdím, že v tom stále není žádný problém.

Závěr

Tento základ je opravdu dobré dodržovat a člověk se pak vyhne zbytečným problémům. Samozřejmě stále platí: "Nikomu nevěř", a to platí jak pro uživatele, tak i pro správce. Každý dělá chyby, takže když je problém, nikomu nevěř, ověř si to sám, ať je jistota.

Ještě dodám, že vždy se mi podařilo odhalit a opravit problém. Setkal jsem se jak s odmítáním emailů od Gmailu, MS i jiných (třeba německý kundenserver byl dost restriktivní) a vždy to šlo vyřešit a většinou k té blokaci byl nějaký důvod a nebyl to omyl. Píši většinou, protože někdy to nešlo z pohledu serveru zákazníka dohledat / ověřit, proč k tomu nastalo (chybějící logy apod.).

Na závěr dodám takovou třešničku. Máte firmu, máte všechno vyladěný, všechny pravidla, co je spam, jde v 95% do spamu, co je regulérní, to projde atd. Nu a pak firma začne expandovat/řešit východ. Komunikace s Čínou je super (všechno se tváří jako 500% spam), komunikace s Ruskem je na tom podobně. Ostatně, stačila i menší expanze do Polska a tam to byla také menší divočina. Osobně nechápu, jak třeba ta Čína řeší spam. Nabyl jsem dojmu, že nijak, resp. asi lidskými zdroji.

Zdar Max

       

Komentáře

[Mailerka]

Nejaka prakticka zkusenost a postrehy z provozu https://github.com/docker-mailserver/docker-mailserver, popr. https://github.com/mail-in-a-box/mailinabox?

[Max]

Nějak si nedovedu dnešní provoz představit bez nějakého web ksichtu (né kvůli správci, ale kvůli uživatelům). OSS světu dnes vládne ISPConfig, ale ten asi není připraven na takové rozházení služeb do kontejnerů. Takže kdo to reálně používá?
Jinak občas sleduji projekt devilbox.org, který je podle mě dost daleko v tom, mít všechno fakt rozházený do kontejnerů a plně oddělený od sebe.
Zdar Max

[hydrandt]

Pouzivam uz par let mailcow a za me super.

[JiK]

Uplne se v tom neorientuju, ale prijde mi, ze dnes neni k dispozici jednoduche reseni idealne treba docker, ktere by umoznilo protozovat mail a okolni podprurne veci na vlastni domene? ani levne placene ani free?

[Max]

iRedMail nebo ISPConfig ti to přednastaví. Ale přednastaví ti to na úrovni serveru. Doménu, klíče a další věci si musíš nastavit sám, to je myslím jasné, když je to mimo server u nějakého správce domény / dns.
A pak sám musíš řešit případné problémy.
Zdar Max

[Max]

Ještě dodám, že vždy musíš vědět, co děláš. A každá aplikace, co ti něco ulehčuje, vyžaduje hlubší znalosti.
Docker ti přidává jen další vrstvu. Kromě znalosti jednotlivých služeb tedy musíš znát navíc i docker, aby jsi byl schopný řešil problémy, který jsou na docker vázány.
Podobně ISPConfig. Aby jsi ho byl schopný používat, musíš znát nejen služby, které konfiguruje, ale i samotný ISPconfig.
Kubernetes to samé. Když konfiguruješ ingress, tak musíš znát syntaxy Ngixn a navíc znát i syntaxy Kubernetu, který ten Nginx generuje.
A tak bych mohl pokračovat. Každá přidaná vrstva nad core aplikací vyžaduje hlubší a hlubší znalosti.
Ty vrstvy nad tím, nebo pod tím, ti sice zesložiťují práci a vyžadují po tobě hlubší znalosti, ale zase ti na oplátku nabídnou třeba klikátko pro klienty, nebo plnou automatizaci.
Je to tedy něco za něco a je na tobě, zda ti ta přidaná vrstva ve finále práci ulehčí / nebo ti to pomůže, nebo ne.
Zdar Max

[Pepan]

Tak, tak. A nejlepší jsou takoví co nechtějí ty vrstvy pod tím řešit ani jim rozumět, nainstalují si super-duper-mail-server.docker a pak brečí v blogu, že provozovat dnes mailserver na vlastní triko nejde.

[_]

a pak sou taci, co pouziji gmail, a nemusi resit nic

[xxx]

A do jaky hloubky by tomu meli rozumnet? Protoze by me fakt zajimalo, co si Max, nebo ty, predstavujete jako normlani znalosti, pro rozjeti zakladni sluzby jak jo E-Mail (vcetne webksichtu, spravy uzivatelu, etc.)? Ja to treba vidim jako kralyk, protoze prokousavat se (zdokumentovanym) nastavenim bych jeste dal, ale resit nejakou na empirie postavenou magii, kdy to jeste funguje, a kdy uz ne, tak na to se muzu vybodnout. A pordit si GApps.

Za par let se pak tradicionalisti budou divit, proc tady existuje par propojenych megacloudu, kteri milostive poskytuji (zatim) nejakou SMTP gateway do jejich systemu, ktery uz vnitrne ale pobezi na jinych protokolech. Pricemz jedina obrana tradicionalistu proti tomuto scenari je, ze se to lidi maji naucit vsechno nastavit.

[Max]

Do té hloubky, aby věděli, jak to funguje, protože pak lze řešit problémy, které nastávají. Pokud máš pocit, že mailové služby jsou primitivní záležitost, tak proč tě šokuje nutnost znalostí?

Každopádně těžko říci, do jaké úrovně je cloud výsledkem složitosti, ale určitě je výsledkem absence lidí. V IT dlouhodobě lidí chybí a budou chybět víc a víc. Je to kvůli tomu, že automatizace a další věci naskakují takovým tempem, že společnost nedokáže vytvářet odpovídající počet lidí, kteří by to pokryli. Ono když si vezmeš cenu licencí a další věci, tak pak přijdeš na to, že místo placení si lokálních serverů a lokálního člověka dáváš ty stejné prachy, spíše více, někomu jinému.
Zdar Max

[xxx]

Ja jsem nenapsal, ze mailove sluzby jsou primitivni zalezitost. Ja jsem napsal, ze E-Mail je zakladni sluzba. Coz ma nejake implikace ohledne toho, kdo ji bude poskytovat, a jake lze mit ocekavani na takove poskytovatele.

A absence lidi je dusledkem ceho? Ze by te slozitosti, pro jejiz prekonani je potreba znalstni investice, ktera je stejna pro spravu 1, 10, 100 a mozna i nizsich 1000 uctu?

[David Heidelberg]

Osobně zvažuju Mailu nebo velkou migraci na Apache James (má i JMAP)

[Max]

Jen za zajímavosti, jaké důvodu k tomu máš? Nebo resp. co máš teď, že chceš přejít?
Zdar Max

[zvedavec]

Mozna prave ten JMAP? Drzet krok s dobou - nebo bych mel napsat "o krok napred pred konkurenci"?

[David Heidelberg]

Spíš utéct minulosti. Od doby telefonů, LTE + WiFi atd. je IMAP zlo. JMAP je jediný ne-proprietární protokol (a k tomu ještě poměrně rozumně navržený). Zbytek poskytovatelů mají svoje protokoly, protože IMAP/SMTP na komunikaci s koncovými zařízeními 'nikdo' nepoužívá.

[trekker.dk]

Od doby telefonů, LTE + WiFi atd. je IMAP zlo.

Proč? Zrovna na LTE a wifi (relativně rychlé a spolehlivé připojení s nízkou latencí) by to mělo fungovat dobře, ne?

[David Heidelberg]

viz. FAQ https://jmap.io/index.html

[plostenka]

JMAP je jediný ne-proprietární protokol.

Co je proprietarniho na RFC?

[David Heidelberg]

nic. Každopádně zkoušel jsem hledat článek o revizi 2, nikde nic. Odhaduji, že podpora serverů i klientů bude polovičatá. Pokud máš nějaký lidský souhrn, o čem je rev2, rád si to přečtu.

[Max]

ActiveSync má otevřenou specifikaci a je podporován snad na všem (jak klient, tak backendová řešení). Takže v čem je problém u ActiveSyncu?
Zdar Max

[David Heidelberg]

upřímně nevím. Je tam nějaký háček? Proč běžné OSS řešení ActiveSync nepoužívají?

[Max]

Běžné OSS řešení ActiveSync používají. IMAP = pouze emaily, pro kontakty je CarDAV, pro kalendáře je CalDAV atd. ActiveSync zastřešuje vše. Tomu se pak říká groupware řešení. OSS implementací je několik, SOGo je třeba jednoduchý a velmi dobrý open source groupware bez omezení, další je Horde, Zimbra, pak Zarafa / Kopano atd.
Pokud bych si měl vybrat, jaký groupware provozovat, tak SOGo (preferuji kvůli napojení na standardní služby jako postfix, dovecot apod.) nebo Horde. Pokud by to bylo firemní prostředí, které je zatížené na MS Outlook, tak bych pak řešil něco, co má vhodný addin do outlooku (CalDavSync je nedostatečné řešení, potřebuješ něco na sdílení a celkové propojení).

ActiveSync byl dříve zatížen licenčně, což MS nakonec zrušil a vydal specifikaci. V současné době je zatížen sw patenty, což už dnes bývá sporné.
Jen upozorňuji, že můj názor na celou problematiku je čistě profesní, je to rozšířené, implementací už existuje hodně atd. Idál by byl, kdyby ten protokol nebyl patenty zatížen vůbec, ale bohužel.
Ještě je třeba upozornit, že není ActiveSync a ActiveSync. To, přes co komunikuje moderní MS Outlook je také ActiveSync protokol, ale proprietární. To, o čem se bavíme my, je to, co je v mobilech, tabletech apod., viz wiki.
Zdar Max

[David Heidelberg]

díky za shrnutí

[David Heidelberg]

protože mi běží mailserver na Gentoo, a aktualizovat to je zlo. Dokud jsem si s Gentoo hrál každý den, tak pohoda, ale teď když už jsem všechno přemigroval na Debian, jen partička dovecot+postfix zůstala.

[motyq]

S úspěchem používám poste.io - vyrabějí to nějací češi. Free i placená verze, je to docker kontejner a umí to všechno. Vcelku časté aktualizace - když nic jiného (bug nebo feature) tak aspoň vyjde nová verze s čerstvými verzemi použitých komponent. Jen mi přijde svérázná ta jejich cenová politika placené verze...

Dřív jsem si provozoval vlastní postfix, dovecot a nebylo to ono. A jelikož jsem líný, tak jsem postupně zkoušel až našel tohle.

(btw: nejsem nijak spojen s poste.io)

[trekker.dk]

9) ... na gmail dorazí email, který se bude tvářit jako od "franta@seznam.cz", ale nepřijde od seznam serveru, ale z jiného. To bude vyhodnoceno jako spam.

Špatný příklad IMO. Seznam nemá restriktivní SPF, takže není důvod takový mail označit jako spam. Plus by bylo hezké zmínit SRS. Rada "prostě to nedělejte" je bohužel k ničemu, pokud spravujete schránky zákazníkům a ne uživatelům.

12) Gmail mi odmítá emaily a nevím proč

To neví nikdo, nechávají si to pro sebe. Ale třeba čerstvě spuštěný mailserver na nové IP adrese má smolíka. Jo a ještě jedna chyba - neodmítá, to by ještě bylo dobrý, ale v tichosti zahazuje do spamu.

16) Greylisting

Plus existují servery, které první opakovaný pokus udělají po 2 sekundách a druhý opakovaný pokus po 3 hodinách.

Osobně nechápu, jak třeba ta Čína řeší spam.

AFAIK v Asii tak nějak obecně považují spam za normální věc, která není nijak negativní. Existovaly RBL, které blokovaly IP adresy pro Jižní Koreu, protože odtud se spamovalo ve velkém. Prostě letáková kampaň, akorát levnější a pro jistotu do celého světa. O indických mailech od PM Modiho (https://en.wikipedia.org/wiki/Narendra_Modi) ani nemluvě.

[Pepan]

Ad 9) navíc Seznam používá SRS.

[Max]

To, že seznam používá srs, je k ničemu, když v tom příkladu ten email nepřeposílá seznam :)
Zdar Max

[Max]

V bodě 9) to ale není jen o SPF, ale třeba i chybném dkim.

16) souhlas, i špatné nastavení intervalu pro další pokus o doručení nemusí být ideálně nastaven.

ad SRS) Uživatel neví, zda server podporuje SRS, on ani neví, co to SRS je a většina serverů jej nemá nastaveno. Setkávám se s tím dost často, že uživatel někomu pošle email a přijde mu NDR od někoho jiného.
Zdar Max

[trekker.dk]

V bodě 9) to ale není jen o SPF, ale třeba i chybném dkim.

Na to zas existuje ARC (ale to je všechno, co o tom vim)

[MP]

ad 12] Skutecne ma novy mailserver u googlu smolika? Tomu se mi nechce verit, to by neslo udelat dnes zadny novy mailserver

ad 16] nejlepsi zkusenost mam s polaky. jejich greylisting odmita pro jistotu i opakovane zaslani mailu. tatari.

[henk]

12) Asi jo, před časem firma koupila nové IPv4 rozsahy a pošta z nich nechodila. Nikde žádné info, nikde nic na blacklistu, ticho po pěšině. Nakonec nás zachránil "kamarád kamaráda kamaráda" co měl alespoň nějaký kontakt na Google. Nevím, co bysme jinak dělali ...

[Max]

Je možné, že původní majitel ipv4 byl třeba spammer, nebo něco a dostal to tak krásně daleko, že ty ip mely šíleně špatnou reputaci. Každopádně kontaktovat i ten Google je možné, viz kontaktní formulář v zápisku.
Zdar Max

[trekker.dk]

Je možné, že původní majitel ipv4 byl třeba spammer

Stane se vám to, i když dostanete fungl nový IP blok přidělený od RIPE. Teda ten dneska už nedostanete, ale princip asi platí furt - IP adresy, které Google neviděl, považuje za nedůvěryhodné, dokud z nich nepřijde dost mailů, u kterých si příjemci stěžují, že jim zprávy padají do spamu.

V době, kdy ještě šlo dostat nový IP blok, Google AFAIK kontaktovat nešlo

[MP]

No to mam radost...zrovna dotahujeme testovani novych mailserveru na novych ip...

[Mayhem]

Super clanek, dekuji.

Btw jak resite situaci, kdy se vam IP smtp serveru dostane na blacklist? Vim, ze u nich jde zadat o brzke vyrazeni, nebo pripadne jen pockat, nez uplyne lhuta. Co ale delat v tu dobu, co je clovek na blacklistu? Mit vice IP adres a rotovat je? Toto mi vzdy prislo frustrujici.

[Max]

Dřív jsme to vyčekali, protože reálně se to týkalo jen menší části komunikace (né všechny mailservery hned blokují příchozí komunikaci na základě členství v blacklistu). Nu a spoustu let se nám to už nestalo, protože lepší a lepší techniky pro zabepečení i eliminovaly související problémy. Provoz mail server na oddělené IP hodně ušetřil, lepší politiky na mailové gw totálně eliminovaly proklouznutí škodlivého sw přes maily. Lepší nastavení na proxy serveru také + nějaká prevence nastavení na AV a vesměs si nepamatuji za posledních hafec let nějaký incident (spamování, zavirovaná stanice, ransomware apod.).
Zdar Max

[Mayhem]

Super, dekuji za zkusenosti.

[MMMMMMMMM]

Já mám v internetu VPS, které jsem asi dvakrát použil jako relay pro firemní poštovní server, když se tento dostal na blacklist (kvůli prolomenému heslu k účtu). Show must go on.

[kralyk z abclinuxu]

Má smysl v dnešní době provozovat vlastní smtp?

Měl jsem původně v úmyslu nahodit si vlastní, ale postupně jsem vyhodnotil, že to smysl nemá (pro jednotlivce, firma je smaozřejmě něco jiného). Důvodem je hlavně bod 6, tj. že by mailový provoz měl být oddělenný od ostatního, s čimž naprosto souhlasim. Tzn. musel bych zřídit separátní hosting pouze pro e-mail a nemohl bych ho použít už na nic jiného. Jednotlivci mají typicky tendenci tohle pravidlo porušovat, protože když má člověk server (ať už vlastní nebo hostovaný u někoho) na kterým má mail, hrozně to svádí si tam hodit ještě třeba nějakou storage na data nebo webovky/blogísek nebo VCS a podobně, čímž se kombinuje provoz, přivádí to na ten server pozornost a podstatně se zvětšuje attack surface. Plus si to samozřejmě člověk musí všechno spravovat a neustále si po sobě kontrolovat, že to opravdu dělá dobře a někde na něco nezapomněl - přijde mi to jako docela stres, pokud se tomu člověk nevěnuje primárně / nepracuje jako admin těchto věcí.

Naštěstí existuje ProtonMail, což je pro mě docela spása Mam u nich placenou verzi na vlastní doméně - vyhodnotil jsem, že dokonce ani mailovou doménu nechci přepoužívat pro další věci. Místo toho, abych si to nějak pytlíkoval sám a trávil tim čas, raději podpořim tento projekt a uštřim si trable. Mají to zpracované pěkně, pro nastavení vlastní domény mají průvodce, který člověku říká, jak nastavit všechny ty potřebné DNS záznamy od AAAA až po ZZ-Top, a zároveň to testuje a postupně "odfajfkovává" ty, které už jsou nastaveny správně.

[Provozovatelka emailu]

No takhle s tim pruvodcem a odfajfkovavanim funguje prave ten mail-in-a-box (MiaB) zmineny v prvnim prispevku.

[alkoholik]

Ad 9) koukam, ze Max jeste neobjevil Authenticated Received Chain (ARC). Postfix s OpenARC forwarduje na GMail naprosto bez problemu.

[Max]

Já to myslel obecně podle toho, jak co má kdo nastaveno, resp. skoro nikdo nemá a většinou vrcholem konfigurace je nastavený SPF.
Zdar Max

[X]

Bude i pokracovani = nasazeni antispamu? Uz se v tom aktualne tolik neorinetuji. Znam spamassasin, rspamd, clamav. Jeste neco nevejsiho? Aktualni trendy? etc.

[Max]

Cílem bylo upozornit na naprosté základy. Nevím, zda chci sepisovat kompletní step2step howto, jak nastavit vlastní mailserver.
Zdar Max

[X]

Ok.

[Petr Fiedler]

Nevím, zda chci sepisovat kompletní step2step howto, jak nastavit vlastní mailserver.

No to bys právě mohl

Jinak super zápis, díky.

[Max]

Včera, velká firma, poskytuje cloudové služby, má nevalidní spf záznam, protože překročila počet dns lokupů a pak je problém, protože SPF je nevalidní. DMARC mají vypnutý, takže ten to nijak neovlivní, ale kdyby byl aktivní, byl by asi o problém navíc.
Zdar Max

[trekker.dk]

protože překročila počet dns lokupů

naprosto běžnej jev

[trekker.dk]

a některé validátory to ignorují

[Max]

Tak nic, prostě si to neopraví. Dlabou na to. Tomuto přístupu nerozumím.
Zdar Max

[tttttttt]

Přeposílání by měl řešit ARC. Má někdo zkušenost, jestli to velké servery akceptují?

[Mentor]

Co to je "né", Maxi? :)

[Cejvik]

Pro začátečníky co sem přivál vítr si tu odložím:
https://zentyal.com/ - Easy Linux alternative to Windows Server
https://www.nethserver.org/ - Small Business Linux Server Made Easy