Mail u sebe doma

[Filip Jirsák]

PTR záznam neřeší bezpečnost. Používá se pro to, že uživatelé domácích/spotřebitelských přípojek obvykle nemohou PTR záznam správně nastavit. Používá se to tedy jako rozlišení domácích přípojek, protože se předpokládá, že na nich nemá být nic, co by e-maily rozesílalo. Předpokládá se tedy, že „mail u sebe doma“ nikdo neprovozuje. Někteří *** to povýšili na vyšší úroveň, takže i když máte správný PTR záznam, kontrolují jeho obsah – takže za spamera považují třeba i toho, jehož PTR záznam obsahuje číslice. Protože takové PTR záznamy opět používají ISP často na domácích přípojkách…

Používá se to jako antispamová ochrana, tedy když email odesíláte (jste tedy v roli SMTP klienta).

Problém se stovkami domén není žádný – jméno serveru nemusí nijak souviset s doménou, ze které se e-mail rozesílá. Takže server se může klidně jmenovat a.smtp.example.com, a přitom bude rozesílat e-maily s odchozí e-mailovou adresou z doméně example.net a seznam.cz a email.cz atd.

[Reklama]

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Já to pro jistotu zopakuju a vyhledal jsem si odkaz v tomto vlákně: (samozřejmě doufám že se myslím IP adresa odesílajícího SMTP serveru a ne samotného uživatele  )

Dodržujte tyto doporučené postupy pro poštovní servery, které odesílají e-maily uživatelům Gmailu:

Ověření záznamu PTR odesílajícího serveru
Důležité: IP adresa odesílatele musí odpovídat IP adrese názvu hostitele uvedené v záznamu PTR. Záznamy PTR se nazývají také reverzní záznamy DNS.

IP adresa odesílatele musí mít záznam PTR. Záznamy PTR ověřují, že název hostitele odesílatele je propojen s jeho IP adresou. Každá IP adresa musí být v záznamu PTR namapována na název hostitele.

A co ti domácí uživatelé, kterým provider dokáže změnit PTR . Těm závidím a závidíš? Nebo takový provider "domácí přípojky" to nesmí změnit (a kdo mu to přikazuje a kdo to hlídá vymáhá a pokutuje)?


Co tedy znamená správný PTR ? Já měl za to, že správný PTR je takový jako "doména emailové schránky odesilatele od kterého přišel mail" . Pak tedy nechápu vyjádření i když máte správný PTR záznam .... jehož PTR obsahuje číslice Tím jsi myslel  opravdu vzácné příklady jako domény gifts4you.com nebo 123autobazar.cz nebo  98-12.brno-venkov.cz?

A kruciální otázka k poslednímu odstavci:
Pokud tedy jméno serveru nemusí nijak souviset s doménou:
1. Není to ve sporu s tím citovaným úryvkem nápovědy google
2. Jak je pak řešena triviální obrana, že někdo z tramtárie posíla poštu jménem @policie.cz . Zkusím si odpovědět sám - přeci SPF záznamem (který "uložil policejní ajťák " "na doménu" policie.cz do TXT políčka  )
3. Ano, takové případy v praxi existují - ten zmíněný email.cz na vlastní doméně a nebo z jiného soudku velké e-shopy, co outsourcují odesílání infomailů na "velké (spammerské) ryby" jako list-manage, ecomail atfuj.
4. K čemu tedy to "šílenství" s správným PTR, když to není ochrana a řeší to lépe SPF nebo DKIM (stačí jedno z toho)

[Filip Jirsák]

Co tedy znamená správný PTR ? Já měl za to, že správný PTR je takový jako "doména emailové schránky odesilatele od kterého přišel mail" .

Obecně se od PTR záznamu vyžaduje jenom to, aby jméno, na který ukazuje, vedlo i na IP adresu, ke kteréten záznam patří. Nebo-li když bude PTR záznam pro adresu 192.168.0.1 ukazovat na jméno mail.example.com, má existovat i A záznam pro mail.example.com, který vede na 192.168.0.1.

S e-mailovou adresou odesílatele ten PTR záznam nijak nesouvisí. Je běžné, že jeden poštovní server (který má jedno jméno) odesílá e-maily pro stovky domén.

jehož PTR obsahuje číslice[/i][/b] Tím jsi myslel  opravdu vzácné příklady jako domény gifts4you.com nebo 123autobazar.cz nebo  98-12.brno-venkov.cz?

Cílí to především na to poslední, ale bůhví, jak to mají tihle vynálezci nastavené. Obvykle se řídí heslem „když se kácí les, létají kusy lesa“ a detaily svého nastavení obvykle tají s odůvodněním, že „přece nebudou napovídat spamerům“. Já bych tedy určitě nedával číslici do názvu zařízení (poslední doménové jméno). A pokud si pro vázev serveru můžete vybrat více domén a některá z nich obshuje číslici, pokud můžete, vyhněte se jí. Pro jistotu. Také je dobré vybrat starší doménu, to také může mít vliv.

Pokud tedy jméno serveru nemusí nijak souviset s doménou:

Přesně tak, nemusí a velice často nesouvisí.

1. Není to ve sporu s tím citovaným úryvkem nápovědy google

V čem je to podle vás v rozporu? Tam se o doméně e-mailové adresy nic nepíše.

2. Jak je pak řešena triviální obrana, že někdo z tramtárie posíla poštu jménem @policie.cz . Zkusím si odpovědět sám - přeci SPF záznamem (který "uložil policejní ajťák " "na doménu" policie.cz do TXT políčka  )

Ano, SPF a/nebo DKIM. PTR s tím nijak nesouvisí.

4. K čemu tedy to "šílenství" s správným PTR, když to není ochrana a řeší to lépe SPF nebo DKIM (stačí jedno z toho)

To je dotaz na ty, kdo tu kontrolu PTR záznamů na svých poštovních serverech dělají. Já jsem to vždy považoval za nesmysl.

Jak už jsem psal, někteří správci poštovních serverů bojují se spamem tak usilovně, že je nezajímají žádné ztráty regulérních e-mailů – a vymýšlejí nejrůznější obskurní pravidla, která podle nich správný odesílatel musí splnit. Tak proč ne PTR záznamy? Zejména když každé zařízení připojené do internetu by mělo mít (ne musí, ale koho to zajímá, že) PTR záznam se jménem a to jméno by se logicky mělo překládat zpět na IP adresu toho zařízení. To, že stejné standardy říkají „buď striktní v tom, co odesíláš, a buď benevolentní v tom, co přijímáš“, už ti správci obvykle nevidí.

[messagebus]

Plny souhlas s „buď striktní v tom, co odesíláš, a buď benevolentní v tom, co přijímáš“. Ja jsem treba extremne benevolentni v tom, co prijimam. Neprijimam velmi malo veci - napriklad neprijimam zadnou komunikaci od vozraleho, pobliteho a pochcaneho bezdomovce, coz je v smtp svete server bez spravne resolvujiciho PTR zaznamu Je to proste stejne jako v realnem zivote. Chces-li s nekym normalnim mluvit, musis dodrzet nejaky minimalni kulturni standard.

Jinak vyznam neexistence PTR nahradit SPF ani DKMI nejde. SPF a DKIM si lehce nastavi kazdy, kdo si koupi libovolnou domenu. Zatimco nastavit PTR zaznam u napadeneho pocitace nejakeho duchodce uz je ukol uplne jineho radu.

[_mbily]

Zřejmě patřím k do tábora oněch "usilovných bojovníků se spamem". Pro mne je nastavení A/AAAA/PTR záznamů prvním krokem k rozpoznání toho, zda to správce dotyčného stroje myslí s provozováním poštovního serveru vážně. Něco jako prokázání základní úrovně kvalifikace. Kdo tímto testem neprojde, s tím se nebavím. Může se mu to nelíbit, může s tím i nesouhlasit, ale to je asi tak všechno. U serveru se správně nastavenými DNS záznamy je naděje, že mne nebude zahlcovat tunami spamu a phishingu generovanými nějakými breberkami. A na filtraci tohoto spamu nebudu muset obětovat příliš mnoho výkonu mého serveru.

[Reklama]

[Filip Jirsák]

Oba dva jste napsali jenom o tom, kolik omezíte spamu, ale nenapsali jste, kolik omezíte regulérní pošty. Pokud by vás ale opravdu zajímalo jen omezení spamu a omezení regulérních e-mailů neřešíte, pak je nejlepší poštovní server úplně vypnout – tím zastavíte 100 % spamu.

[_mbily]

Oba dva jste napsali jenom o tom, kolik omezíte spamu, ale nenapsali jste, kolik omezíte regulérní pošty.

V dlouhodobém průměru nula nula nic.

Snad takový správce umí ve svém mailboxu najít příslušnou nedoručenku. A zeptat se (z jiné mailové adresy), jaký s ním asi tak mám problém. Na to samozřejmě reaguju a slušně odepíšu. No a on je buď schopen problém odstranit, nebo své regulérní maily společně s ostatními členy rodiny či jiného gangu bude muset posílat od různých seznamů, gmailů a jim podobných. Nevidím v tom problém.

[Filip Jirsák]

V dlouhodobém průměru nula nula nic.

Snad takový správce umí ve svém mailboxu najít příslušnou nedoručenku. A zeptat se (z jiné mailové adresy), jaký s ním asi tak mám problém. Na to samozřejmě reaguju a slušně odepíšu. No a on je buď schopen problém odstranit, nebo své regulérní maily společně s ostatními členy rodiny či jiného gangu bude muset posílat od různých seznamů, gmailů a jim podobných. Nevidím v tom problém.

To ovšem znamená, že e-maily odmítáte tak, že se o tom odesílatel může dozvědět. Což není samozřejmé. Pak je samozřejmě otázka, zda se ta nedoručenka k odesílateli skutečně dostane, a také zda bude vědět, co s ní, a zda to bude chtít řešit.

Jinak reálně dnes asi nikdo poštovní server s chybně nastaveným PTR záznamem neprovozuje, protože už to požaduje tolik serverů, že by pořád řešil jen neodeslané e-maily. Zajímavější tohle bylo někdy před patnácti lety, kdy to začínalo.

Na druhou stranu, dnes už s tím zase mnoho ISP počítá a rovnou mají PTR nastavené správně, případně to umožňují změnit.

[_mbily]

To ovšem znamená, že e-maily odmítáte tak, že se o tom odesílatel může dozvědět.

Můžu odmítat různým způsobem. Na správně nastaveném serveru odesilatele se o tom uživatel dozví v (dejme tomu) obou dvou možných situacích. Buď mail odmítnu ve fázi navázaného smtp spojení. Tím se o problému odesílající server, jeho postmaster i odesilatel mohou dozvědět prakticky v reálném čase. Pokud bych vůbec nedovolil navázat smtp spojení, tak by totéž mělo nastat po cca 3-5 dnech. Tj. za dobu, po kterou mail u odesilatele stál ve frontě a byly činěny pokusy ho odeslat, navázat smtp spojení s protistranou.

Samozřejmě záleží na tom, zda na odesílajícím serveru se na chybové události nějak reaguje, jak je v případě postfixu nastaveno notify_classes, zda ty nedoručenky vůbec někdo čte apod.

Pro ilustraci, k celkovému počtu 12500 mailů přijímaných za včerejší neděli jednou z "mých" přijímacích bran (a připuštěných až k rozhodnutí spam/ham) je potřeba připočíst dalších zhruba 31000 mailů zamítnutých na nižší úrovni postfixem právě kvůli problémům s PTR záznamem. Jsem ale lidumil a zamítám je s kódem 4xx.  Takže ve skutečnosti jich je znatelně méně, započítávají se zde i opakované pokusy. (Lze jistě diskutovat, zda v této situaci odmítat s kódem 4xx je lepší nebo horší než s 5xx)

[Filip Jirsák]

Můžu odmítat různým způsobem. Na správně nastaveném serveru odesilatele se o tom uživatel dozví v (dejme tomu) obou dvou možných situacích. Buď mail odmítnu ve fázi navázaného smtp spojení. Tím se o problému odesílající server, jeho postmaster i odesilatel mohou dozvědět prakticky v reálném čase. Pokud bych vůbec nedovolil navázat smtp spojení, tak by totéž mělo nastat po cca 3-5 dnech. Tj. za dobu, po kterou mail u odesilatele stál ve frontě a byly činěny pokusy ho odeslat, navázat smtp spojení s protistranou.

Pak ještě existuje třetí způsob, který vy třeba nepoužíváte, ale jiní ano – e-mail jakoby přijmete k doručení a pak ho zahodíte.

Samozřejmě záleží na tom, zda na odesílajícím serveru se na chybové události nějak reaguje, jak je v případě postfixu nastaveno notify_classes, zda ty nedoručenky vůbec někdo čte apod.

Také může být problém, pokud se na straně odesílatele e-mail hned nedoručuje adresátovi, ale předává se přes několik serverů. Pak může být problém zpět vracet jenom ty nedoručenky, u kterých máme jistotu, kdo byl odesílatelem.

Pro ilustraci, k celkovému počtu 12500 mailů přijímaných za včerejší neděli jednou z "mých" přijímacích bran (a připuštěných až k rozhodnutí spam/ham) je potřeba připočíst dalších zhruba 31000 mailů zamítnutých na nižší úrovni postfixem právě kvůli problémům s PTR záznamem.

Takže ale nevíte, kolik z těch 31000 zamítnutých e-mailů byl regulérní e-mail.

Jak jsem psal, pokud se chcete chlubit jenom tím, kolik spamu zastavíte, pak je nejlepší odmítat všechny e-maily. Odpověď „z 43500 pokusů o doručení e-mailu server 31000 pokusů rovnou zamítl, poměr spam/ham u zamítnutých e-mailů neznám, ale jsem přesvědčený, že hamu je tam velmi málo, protože se ke mně za 5 let nedostala žádná informace o problémech s doručením“ považuji za férovou – prostě něco nevíte, ale máte dobrý důvod si myslet, že moc hamu neodmítáte. Pokud ale někdo napíše jenom „odmítám e-maily z klientů s chybným PTR záznamem a zbavím se tak spousty spamu“, svědčí to akorát o tom, že dotyčný moc nepřemýšlí o tom, co dělá, a kdyby se mu ztrácela pětina e-mailů, nejspíš to ani nezjistí.

Jen aby bylo jasno. Já netvrdím, že se má někdo pokoušet provozovat SMTP klienta na zařízení se špatně nastaveným PTR záznamem. Sice je ta kontrola principiálně špatně, ale dneska je holt nutné počítat s tím, že to kontroluje prakticky každý. Takže pokud někdo chce z nějakého zařízení rozesílat e-maily, ať pro tu IP adresu zajistí správný PTR záznam. A provozovatelé SMTP serevrů by si na oplátku mohli zkontrolovat, jak bude jejich řešení fungovat, až začnou e-maily přijímat přes IPv6.

[messagebus]

Oba dva jste napsali jenom o tom, kolik omezíte spamu, ale nenapsali jste, kolik omezíte regulérní pošty. Pokud by vás ale opravdu zajímalo jen omezení spamu a omezení regulérních e-mailů neřešíte, pak je nejlepší poštovní server úplně vypnout – tím zastavíte 100 % spamu.

No jeje! A tech genialnich napadu od bezdomovcu, se kterejma se taky nebavim, myslite, ze tech bylo taky hodne?

[davidb]

mailserver mam zatim porad doma po presunu z dedikovaneho serveru, PTR mi nastavil provider internetu na fqdn VPS, mikrotik NATuje 25, 143, 993, 587 a 465 tusim, dovnitr na proxmox s tim danym virtualem, pokud nebude mit provider vypadek 5-7 dnu tak by se prichozi posta nemela nikam ztratit (s takovym vypadkem internetu by byl tento provider uz stejne minulosti, minus jeho predni zuby)
idealni by bylo mit jeste nekde nejaky virtual jako backup mx a taky to prestehovat nekam ven (mimo cloudy tam je posta blokovana a spravovat to je stupidni prace v kazdem smeru)

potom se da pouzit proxmox mail gateway jako "prostrednik" (nastaven v MX zaznamech jako postovni server) filtrujici spamy, viry, greylisting atd. a odtud to smerovat na ruzne dalsi mailservery apod. varianty, ale to jsou zase jine pribehy...

[Michal ZOBEC]

Jenomže s tím jsem se setkal i na Office 365 i u Google. Na vlastním poštovním serveru mám alespoň ty logy. U těchto služeb nemám nic.

minimalne u google workspace ty logy mas.

a u Microsoft 365 taky

[Michal ZOBEC]

už tu toho napsalo hodně lidí, přečetl jsem si prvních 6 stran diskuze, dál už jsem to vzdal.

já se přikláním spíš ke kolegům, kteří nedoporučují starat se o vlastní poštovní server. já jsem s tím taky začal někdy v roce 2005. měl jsem kompletní server včetně domény, založený na windows sbs 2003, později na 2008, následně samostatných produktů windows server 2012 a exchange server 2013 a nově Microsoft 365/Exchange Online.

pro začátek to byla dobrá škola, získal jsem tak praxi řešením problémů u sebe a následně pak i u zákazníků. nicméně časem už to je občas opruz když máte potíže s doručováním pošty. jak píšou ostatní, zdrojem problémů může být mnoho různých potíží, jak označení za spam, třeba i neoprávněně, což se mi tak nestávalo často, jako spíše různé provozní/technické potíže a zejména nejčastěji potíže se změnami IP adres nebo PTR záznamu ...

email je rozhodně kritická služba a je nesmysl tvrdit opak. přepokládám že si chceš zřídit mail proto abys jej používal, musíš se pak rozhodnout jestli máš čas případně i řešit potíže, které ti můžou někdy trvat i hodiny. to je to co mě časem utvrdilo v tom, že ač nerad, přemístil jsem poštu do cloudu. když se něco stane, stará se microsoft a ne já.

kdysi jsem měl hodně času, a mohl si hrát s kdekým/kdečím, teď ale se potřebuji soustředit na svou práci a ne zničeho nic všeho nechat a řešit proč nefunguje pošta ...

pokud nejsi spokojen se stávajícím isp, doporučuji přejít na microsoft 365, nebo google workspace. obě služby jsou léty prověřené a stabilní.

[RDa]

už tu toho napsalo hodně lidí, přečetl jsem si prvních 6 stran diskuze, dál už jsem to vzdal.

já se přikláním spíš ke kolegům, kteří nedoporučují starat se o vlastní poštovní server. já jsem s tím taky začal někdy v roce 2005. měl jsem kompletní server včetně domény, založený na windows sbs 2003, později na 2008, následně samostatných produktů windows server 2012 a exchange server 2013 a nově Microsoft 365/Exchange Online.

pro začátek to byla dobrá škola, získal jsem tak praxi řešením problémů u sebe a následně pak i u zákazníků. nicméně časem už to je občas opruz když máte potíže s doručováním pošty. jak píšou ostatní, zdrojem problémů může být mnoho různých potíží, jak označení za spam, třeba i neoprávněně, což se mi tak nestávalo často, jako spíše různé provozní/technické potíže a zejména nejčastěji potíže se změnami IP adres nebo PTR záznamu ...

email je rozhodně kritická služba a je nesmysl tvrdit opak. přepokládám že si chceš zřídit mail proto abys jej používal, musíš se pak rozhodnout jestli máš čas případně i řešit potíže, které ti můžou někdy trvat i hodiny. to je to co mě časem utvrdilo v tom, že ač nerad, přemístil jsem poštu do cloudu. když se něco stane, stará se microsoft a ne já.

kdysi jsem měl hodně času, a mohl si hrát s kdekým/kdečím, teď ale se potřebuji soustředit na svou práci a ne zničeho nic všeho nechat a řešit proč nefunguje pošta ...

pokud nejsi spokojen se stávajícím isp, doporučuji přejít na microsoft 365, nebo google workspace. obě služby jsou léty prověřené a stabilní.

Jiste pane predsedo, a ted zpatky do chliva - protoze jenom prase udela datum jako 32 bit a musi to byt fest divocak, aby to meli jako signed, protoze tri kralove se jiste domlouvali na navsteve betlema skrze mejly... :-)

https://www.root.cz/zpravicky/rok-2022-zpusobil-chybu-v-serveru-microsoft-exchange/

(soudny clovek nezvoli MS platformu pro maily, takze vsechno spatne, uz od doby co jste sahl na pocitac)