Názory k článku Stavíme vlastní e-mailový server: nastavení serveru, spam a IMAP
-
Ondro (neregistrovaný)
Ja by som skor napisal, ze co vse okolo musi bezet aby email nedosel :)
Email ti dojde alebo ho prijemca dostane aj ked vecsinu veci z toho nenastavis. Ak si otestujes x mail serverov, tak na kazdom nieco z clanku bude chybat alebo nieco nebude podporovat.
Vela email serverov ako nosnu vec pre dorucenie/nedorucenie beru rozne black listy (aj spravny reverzny zaznam) a nezaujima ich SPF, DKIM a neviem co.
Tento navod mi vobec nepripada ako navod na domaci email server.
Domaci pouzivatel sa stratil uz v prvom diely tohto serialu a znechuteny to vzdal uz minulom diely. Pre takeho uzivatela by to chcelo viacej vysvetlovania, odporucani,...Serial ako taky je dobry, aj ako ukazka/alternativa dalsieho sposobu postavenia email servera. Samozrejme diskusia k nemu je mozno este prinosnejsia.
-
Nebudeme si nic nalhávat, když na to někdo nemá, tak je dobře, že to znechuceně vzdal. Napůl nastavených serverů se po internetu válí dost, kolikrát se člověk diví, co jsou schopný provozovat firmy, klidně i velký... Snažil jsem se to popsat nějak rozumně, místy jsem podrobnosti přidával, místy ubíral... těžko se na to kouká z pohledu někoho, kdo ví co dělá a proč. Jestli je někde nějaká opravdu velká díra, kde vůbec není jasné o co jde, stačí říct, pokusím se alespoň v diskuzi doplnit.
-
MP (neregistrovaný)
U toho nastaveni databaze (uzivatele, domeny atd) je rozhodne dobre pouzit proxy, viz "proxy:", "proxy_read_maps".
Jinak ohledne toho SPF. Pokud ma clovek mnoho mnoho internich serveru posilajici emaily aniz by mely MX zaznam (typicky crony, atd), co je dnes lepsi cesta?
1] DKIM+DMARC (nebudeme uvadet vsechny IP v TXT SPF ze...)
2] ucet per server na mailserveru
3] jina moznost? -
Něco mezi 2 a 3. Nastavovat každému serveru, který může poslat nějaký log, cron, monitoring, atd. dkim a dmarc je zbytečnost. V mnoha případech je taky zbytečné jim zřizovat účty, na podobné maily se většinou neodpovídá, takže je stačí nastrkat do mynetworks v postfixu a ať si odesílají přes běžný firemní mailserver.
-
K tomu vypisu konfigurace dovecotu - neni nutne grepovat, zkuste prikaz doveconf.
Ke clamavu - rozhodne pridejte signatury 3. stran:
https://github.com/extremeshok/clamav-unofficial-sigsJinak chvalim, tyhle clanky uz na rootu dlouho chybi.
-
Doveconf je fajn, ale nelze tím dosáhnout toho samého, jako tím grepem - zobrazit obsah jednoho souboru bez zbytečností.
Co se týče toho clamavu, já se principiálně podobným úpravám vyhýbám, hlavně kvůli zkušenostem se Spamassassinem, kde spousta slibných alternativních update zdrojů skončila ze dne na den, ale pokud s tím máte dobré zkušenosti a je to dlouhodobě stabilní "služba", proč ne. Můžete prosím trochu popsat, jaké s tím máte zkušenosti? Jinak děkuji za doplnění. -
Vas duvod grepu chapu, ja chtel spis poukazat na to, ze se da konfigurace snadno zobrazit.
Clamav bohuzel se signaturami docela zaostava. Asi pred rokem nebyl schopen zachytit temer nic z rodiny cryptolockeru.
Ten odkazovany skript je nutne projit, jsou v nem komentare, do kterych sluzeb a jak se zaregistrovat, kde ziskat token apod. I z tech free ziskate statisice az miliony dalsich signatur. Trochu stoupne i zatez serveru (clamav si pak vezme asi 1.5GB RAM):
33674 clamav 4 20 0 1287M 1122M uwait 0 24.8H 0.00% clamdJeden z updatu je napr. https://www.securiteinfo.com/services/anti-spam-anti-virus/improve-detection-rate-of-zero-day-malwares-for-clamav.shtml
Ten si ho dokonce platim. Je tam par pravidel, s kterymi nesouhlasim a na ty je whitelist:
cat /var/db/clamav/local_whitelist.ign2
SecuriteInfo.com.Spam-661
PUA.Win.Trojan.EmbeddedPDF-1
SecuriteInfo.com.Spam-2945Protoze nepouzivam amavis (ta konfigurace mi nikdy nesedela, logy od toho pro me necitelne), tak mam jeste v v tom skriptu pustena pravidla foxhole. Ta resi dvojite pripony (typicky nejaky js, wsf v zipech apod.).
Mam to nasazene na mailovem serveru, kde jsou stovky schranek, zaroven to dela backup MX pro dalsi desitky domen a nemam s tim problem. Jen ten whitelist je nutny, jedno z tech pravidel napr. oznacovalo za vir/spam emaily vytvorene v outlook expressu (jeste narazim na uzivatele, kteri tohoto klienta opravdu pouzivaji).
-
j (neregistrovaný)
"nastavíme Postfix, aby OpenDKIM používal ke kontrole ..."
Tadys opomenul jedno pomerne podstatny faktum. Pokud se cokoli na postfix napoji v rezimu milter, tak kdyz to zbuchne nebo z nejakyho duvodu nefunguje, tak to postfixu nevadi a maily doruci i bez toho, coz neni vzdy uplne zadany chovani.
Jinak bych tu zminil, ze pokud nekdo pouziva amavis, tak ten umi zaridit jak kontrolu tak i vlastni podepisovani.
-
No ono to nemá co padat a když to spadne, je potřeba to zvednout ;) Osobně s tím nemám žádnou špatnou zkušenost, jediný, co mi kdy dělalo potíže, protože to padalo, tak byl před lety postgrey.
Co se týče Amavisu, tak podepisovat umí, ale když jsem se tím zabýval cca 2 roky zpátky, tak mi z neznámého důvodu v některých případech generoval nevalidní podpisy, většinou pokud se dala nějaká větší příloha. Moc jsem se tím nezabýval, ale možná to stojí za to, otestovat to znova a případně se zbavit jedné služby.
-
Pali (neregistrovaný)
SPF + DMARC dokopy znemožnujú posielať emaily do mailinglistov. Konkrétne "v=spf1 mx -all" a "v=DMARC1; p=reject;". To sa v texte nepíše a pred takýmto nastavením by mali byť všetci, čo chcú posielať emaily do mailinglistov, byť varovaný.
Najlepší spôsob je SFP + DMARC nepoužívať. Listmastri Debianu už premýšľali nad tým, že z dôvodu ochrany Debian list serverov aby neboli pridané na blacklist začnú odmietať emaily z mailových adries, ktorých správci si nastavili DMARC na p=reject. Časom to nastane a ľudia budú mať na výber či skrotia svôjho admina SMTP/DNS servera aby DMARC vypol alebo si budú musieť zaobstarať inú mailovú adresu kompatibilnú s mailinglistami.
A len tak mimochodom, DMARC je nekompatibilný s RFC5322 pre hlavičku Sender. A SPF je nekompatibilné s .forward.
-
Toto je řešitelné na straně mailinglistu - přepsat hlavičky a odstranit podpis, případně klidně podepsat znovu validně. To, že ty technologie něco rozbíjí, to je obecně známé, ale stav, kdy mohl KDOKOLIV pod JAKOUKOLIV adresou odeslat COKOLIV, aniž by byla nějaká možnost kontroly, je mnohem horší. Pokud někdo v Debianu přemýšlí takhle, tak se ani nedivím, že je Debian v tom stavu, v jakém je.
-
Pali (neregistrovaný)
> Toto je řešitelné na straně mailinglistu
Ako rozumne? Rád sa priučím. Ale keď som čítal SPF a DMARC ako sú definované, tak si myslím, že to nejde. A to kvôli tomu, že rozporujú hlavičku Sender (RFC2822/RFC5322), ktorá by to mohla ešte zachrániť.
> přepsat hlavičky a odstranit podpis
Nefunguje! Podľa p=reject email bez podpisu je nevalidný, prijímateľ ho má zahodiť.
> případně klidně podepsat znovu validně.
Nefunguje! Podľa DMARC podpis musí byť vystavený kľúčom z domény emailovej adresy uvedenej v hlavičke From. A mailing list server rozhodne nemá privátny kľúč ku jednotlivým prispievateľom do konferencie.
Tu si ale autori DMARC štandardu splietli dojmy s pojmami. K účelu, kto je preposielateľ emailu slúži hlavička Sender a ak by sa používala ona namiesto From, tak mailing list server by si mohol pridať vlasnú hlavičku Sender a podpísať to svojím DKIM podpisom. Nič také ale DMARC neumožnuje.
Zato DKIM ráta s tým, že podpis si môže pridať po ceste aj ďalší server.
> To, že ty technologie něco rozbíjí, to je obecně známé, ale stav, kdy mohl KDOKOLIV pod JAKOUKOLIV adresou odeslat COKOLIV, aniž by byla nějaká možnost kontroly, je mnohem horší.
Nie. Horšie je ak príde niekto s technológiu, ktorá je zároveň:
1) nefunkčná
2) vynútená pre užívateľov, bez možnosti vypnúť
3) spôsobí zahodenie validných emailov (také čo nie sú spam/podvrh)
4) pred spamom/podvrhom aj tak nechráníA to žiaľ pre DMARC platí.
> Pokud někdo v Debianu přemýšlí takhle...
A čo navrhujete?
Ak prijímateľ emailu dostane email s chýbajúcim alebo nevadidným DKIM podpisom a odosielateľova adresa má v DNS uvedené p=reject, potom prijímateľ musí taký email neprijať. V horšiom prípade ešte zaradí SMTP server z ktorého prišiel taký email na spam/black list. Tzn, server mailing listu. Prípadne pošle späť bounce (opäť mailing listu).
V tomto prípade ak niekto nechce skončiť na black liste a chce ochrániť svoje server, tak zakáže ľuďom čo toto spôsobujú posielať príspevky do mailing listu. Rovnako môže mailing listový server kvôli jednému mailu vyfasovať tisícku bouncov...
Na druhú stranu DMARC absolútne nič nerieši. Akonáhle pridám nejakú suffix do emailovej adresy v hlavičke From, tak DMARC kontrola prejde. A v prípade, že tam dám nebodaj ešte validnú doménu (bez zmeny phrase vo From), tak to môže mať ešte aj validný DKIM podpis. Prijímateľ, ktorý vidí v svojom UI iba phrase z From hlavičky si ničoho nevšimne, že ide o podvrh.
Tzn, celý DMARC iba skomplikoval/znemožnil mailing listy ale podvrhnuté emaily nejak nevyriešil.
Načo teda takúto technológiu nasadzovať? (Čakám validné argumenty, nie typu "lebo to nasadil veľký Yahoo").
Btw, mailing listy sa riešia práve týmto spôsobom, list server nahrazí adresu vo From za nejakú nevadlinú, prípadne za svoju. Čím zmenmožní zistenie, kto je skutočný odosielateľ emailu (pritom RFC5322 počíta s tým, viď existencia Sender hlavičky). Prípadne vytvorí nový email a ten pôvodný priloží ako prílohu. Oboje je humus pre prijímateľov -- členov mailing listov.
Takže ak máte nejaký lepší nápad sem s ním!
Ja to žiaľ vidím tak, že každý sa snaží nanútiť SPF+DMARC bez toho aby pochopil a vysvltil prečo to robí a prečo je to skutočne prínos (a pre koho).
-
No já bych si to představoval ideálně takhle... Mailinglist často e-mail upravuje, nejen příjemce, ale přidává třeba header, nebo footer, proto prostě zpráva od něj odeslaná MUSÍ být odeslaná od něj a to se vším všudy.
- zprávu normálně přijme na adrese nejaky_list@vlastni_domena.neco, provede testy na co chce, SPAM, viry, klidně zkontroluje SPF, DKIM, DMARC, prostě dle libosti
- ze zprávy uřízne VŠECHNY hlavičky
- přidá patičku s unregister linkem, cokoliv, co se hodí
- zprávu znovu poskládá jako novou s původním předmětem, from jako Registrovaný Uživatel <nejaky_list@vlastni_domena.neco>, přičemž jméno uživatele si dohledá podle původní adresy odesílatele v databázi registrovaných uživatelů (pokud není registrovaný, mail zahazuje)
- klidně může podepsat VLASTNÍM DKIMem, může mít vlastní validní SPF a DMARC
- zpráva odchází všem registrovaným v daném mailing listu
-
Pali (neregistrovaný)
Má to tieto problémy:
1) Prijímatelia tohto mailing listu neuvidia adresu skutočného odosielateľa toho emailu v hlavičke From.
2) Rozpor s RFC5322, ktorý je relevantný pre každú vytvorenú emailovú správu (resp. staršie RFC). Stráca sa tu informácia kto je pôvodný autor emailu a kto jeho preposielateľ. Podľa RFC5322, by sa mal pôvodný autor emailu uviesť v hlavičke From a ten kto ten email ďalej posiela (tzn. mailiglistový server) v hlavičke Sender. Vaše riešenie do From vypĺňa adresu, ktorá má byť v Sender.
3) Odosielateľ každého emailu je identifikovaný emailovou adresu, nie menom/phrase (čo je naviac nepovinné). Navrhnuté riešenie ale s emailovou adresou odosielateľa nepočíta (je tam iba meno "Registrovaný užívateľ").
4) Nefunguje s verejnými mailing listami, kde môže prispievať hocikto bez registrácie.
Bod 4) vidím ako najväčší problém.
-
ad 1) V pořádku. Neexistuje žádný důvod, proč někde hromadit skutečné adresy a přímo je nabízet k vyspamování. Autor se podepsal svým jménem (přezdívkou), je možné s ním v rámci mailing listu komunikovat a nevidím jediný důvod, proč by měl řvát do světa svoji adresu. Pokud ji sdělit chce, může ji uvést do těla zprávy.
ad 2) To samý, co 1
ad 3) To samý, co 1 a 2
ad 4) Veřejný mailing list, kde může kdokoliv neregistrovaný vyspamovat klidně tisíce registrovaných uživatelů je prasečina
Možná to není zcela dle původních záměrů mailing listů, ale doba je prostě taková. Je to velmi malá daň za to, co nabízí SPF a DKIM. Věčná škoda je, že se neujalo místo DMARC raději ADSP, které může být ještě restriktivnější. -
Pali (neregistrovaný)
ad 1) V prípade, že sa nepodpísal, tak mu nie je možné zaslať súkromnú správu, ktorú by nikto ďalší neprečítal. Ok, chápem, že to pre niekoho môže byť cieľom. Ale kopa ľudí do tela emailu svoju adresu nevádza, lebo je uvedená vo From (emailový štandard to vyžaduje).
Naviac k 1) prijímateľom to znemožní hľadať/filtrovať maily podľa emailových adries (čo funguje na všetky ostatné emaily).
ad 4) Väčšina open source projektov funguje práve s verejnými mailing listami. A takmer nikto sa nesťažuje ako vy, že by to bola prasačina. Nevynímajúc linuxový kernel, ktorý používa ohromné množstvo mailing listov.
Argument voči spamu je irelevantný nakoľko tieto projekty majú verejné gitové repozitáre, kde sú jednotlivé patche/commity identifikované práve platnými mailovými adresami.
-
Martin Mareš (neregistrovaný)
SPF naprosto zásadním způsobem rozbíjí forwardování pošty, které je standardní součástí SMTP od nepaměti. A opravit to z principu nelze, takže SPF je zralé tak akorát na zahození.
Co nabízí SPF a DKIM? Dohromady nic moc zajímavého. Spousta spammerů se naučila své spamy podepisovat, takže v poště, která mi běžně chodí, je pravděpodobnost spamovitosti u podepsaného mailu vve skutečnosti o něco vyšší než u nepodepsaného. Slušný statistický filtr se to samozřejmě naučí, takže pokud chci, aby mé maily lidem přišly, nejspíš je výhodnější je pomocí DKIM nepodepisovat :-) A pokud chci, aby příjemce mohl ověřit, že můj mail je autentický, podepíši ho raději pomocí S/MIME nebo PGP.
Takže si osobně myslím, že SPF a DKIM jsou především humbuk prosazovaný lidmi, kteří o fungování mailových protokolů a filtrování spamu vědí pramálo.
-
Filip JirsákStříbrný podporovatelSFP rozbíjí jedině rozbité forwardování pošty. Pokud server při forwardování změní obálkového odesílatele (což udělat musí, pokud má být v obálkové hlavičce e-mail, kam posílat případné chyby), SFP funguje správně. Při hromadném rozesílání e-mailů se to tak dělá odjakživa (např. e-mailové konference), při individuálním přeposílání se na to leta kašlalo, protože to nikomu nevadilo – SFP holt vyžaduje, aby to bylo nastavené správně.
-
j (neregistrovaný)
Nikde, ale nekterym trotlum to nevysvetlis ...
Jinak odstranit vsechny hlavicky neni dobrej napad ... ;D, pak by ti nefungovalo treba razeni odpovedi.
Podstatny je to, aby se konfera cojavim uberkonference.cz ... nesnazila tvrdit, ze odesila mail ze seznam.cz - to si pak nabije hubu uz na spf. A dkim se da v nejhorsim proste odstranit a problem solved.
-
Filip JirsákStříbrný podporovatel
Normální mailinglisty odjakživa fungují tak, že při rozesílání e-mailu uvádějí jako obálkového odesílatele svou adresu doplněnou o příznak, kterému adresátovi se e-mail posílá. Když se e-mail vrátí jako nedoručitelný, vrátí se tedy správci konference (softwaru), který s tou chybou jako jediný opravdu může něco udělat (odesílatel původního e-mailu s tím neudělá nic). Např. pokud se e-maily pro adresáta vrací opakovaně, dočasně jej vyřadí z mailinglistu.
Mailinglisty tedy uvádějí obálkového odesílatele většinou správně, protože to pro ně byla nutnost. Chybně je obálkový odesílatel často uváděn při individuálním přeposílání, protože to dříve ničemu nevadilo.
Adresu From v těle e-mailu mailinglisty nemění, podle ní se pozná, kdo je autorem toho e-mailu. Nastavují ale hlavičku Reply-To, aby odpověď (pokud to odpovídající nezmění) šla opět do konference (pokud je to konference určená pro diskuse; konference určené třeba pro oznamování Reply-To nemění, nebo nastavují na nějakého správce).
-
Pali (neregistrovaný)
> Normální mailinglisty odjakživa fungují tak, že při rozesílání e-mailu uvádějí jako obálkového odesílatele svou adresu
S tým som nerozporoval.
> Adresu From v těle e-mailu mailinglisty nemění
Nová verzia mailmana to už vie a v nastaveniach je špeciálne táto voľba popísaná ako jedna z dvoch možností ako byť kompatibilní s DMARC. Druhá možnosť, ktorá sa dá zvoliť, je vytorenie nového emailu a pôvodný (so všetkými hlavičkami) vložiť ako inline attachment.
Neviem či už je to default, ale viaceré mailinglisty postavené na mailmanovi už vidím, že takto fungujú (prepisjú From).
-
Filip JirsákStříbrný podporovatel
Se SPF není možné posílat e-maily do špatně nakonfigurovaných mailinglistů a přeposílat přes špatně nakonfigurované servery (bohužel je to ale výchozí chování mnoha serverů). Obálkový odesílatel je adresa schránky, která je za daný e-mail zodpovědná – například se na ní reportují chyby. V okamžiku přeposlání na sebe ale odpovědnost přebírá ten, kdo e-mail přeposílá, původní odesílatel s ním už nemá nic společného – takže obálkový odesílatel se má přepsat, nemá tam zůstávat ten původní. Dříve to nikdo neřešil, ale dnes už je to problém. Bohužel třeba Postfix ve výchozím nastavení do přeposlaného e-mailu vkládá původního obálkového odesílatele, Google doporučuje u přeposlaných e-mailů zachovat původního obálkového odesílatele…
-
Pali (neregistrovaný)
SPF naviac síce podporuje .forward ale spôsobom, že obálková adresa sa vygeneruje podľa SRS. Horšie je, že kto to nedorží, tak jeho email bude zahodený. Naviac SRS vygenerovaná adresa nie je validná emailová adresa.
Ale prečo by mal nejakú takú vec implementovať SMTP server, ktorý SPF nevaliduje (tzn. ju nepodporuje)? Naviac štandardy pre SMTP (či už RFC5321 alebo staršie) nič také nevyžadujú.
Btw, pri prepise obálkovej adresy na novú vznikne ďalší problém. Nemusí to prejsť ďalšími spam kontrolami, ktoré overujú, že obálnový odosielateľ je ten vo From/Sender. Prípadne či prijímateľ v obálke sedí s nejakým v To/Cc (čo je naviac tiež dobrá volovina).
> V okamžiku přeposlání na sebe ale odpovědnost přebírá ten, kdo e-mail přeposílá, původní odesílatel s ním už nemá nic společného
To neplatí vždy! Ak si užívateľ na prvom serveri nastaví preposielanie emailov na druhý server a druhý server (z ľubovoľného dôvodu) email nepríjme (resp. ho prvý server na druhý ani doručiť nevie), tak je to stále problém pôvodného odosielateľa a chyba sa má propagovať k nemu.
Váš vyššie uvedený popis pre mailing listy ale platný je.
-
Filip JirsákStříbrný podporovatel
obálková adresa sa vygeneruje podľa SRS
To je jen jeden ze způsobů, jak nastavovat obálkovou adresu. Na přesném způsobu nezáleží, důležité je, aby to byla adresa někoho nebo něčeho, kdo je za ten e-mail zodpovědný.Naviac SRS vygenerovaná adresa nie je validná emailová adresa.
Samozřejmě že je to validní e-mailová adresa, jinak by to nedávalo žádný smysl.Ale prečo by mal nejakú takú vec implementovať SMTP server, ktorý SPF nevaliduje (tzn. ju nepodporuje)?
Protože to se SPF nijak nesouvisí. Jednoduše je to nastavení takové adresy odesílatele, která má v obálce logicky být.Naviac štandardy pre SMTP (či už RFC5321 alebo staršie) nič také nevyžadujú.
No, nevyžadují. Podle standardu je obálkový odesílatel adresa, kam se mají hlásit chyby. Tedy je to adresa, která je za doručení toho e-mailu zodpovědná, a musí to tedy logicky být nějaká adresa spojená s klientem, který ten e-mail odesílá – nedává smysl dávat tam nějakou cizí adresu.Nemusí to prejsť ďalšími spam kontrolami, ktoré overujú, že obálnový odosielateľ je ten vo From/Sender.
To jsou ale špatné kontroly, kterými neprojde spousta věcí.To neplatí vždy! Ak si užívateľ na prvom serveri nastaví preposielanie emailov na druhý server a druhý server (z ľubovoľného dôvodu) email nepríjme (resp. ho prvý server na druhý ani doručiť nevie), tak je to stále problém pôvodného odosielateľa a chyba sa má propagovať k nemu.
Uvedl jste jeden z příkladů, který perfektně ukazuje, proč je špatně nepřepisovat obálkového odesílatele. Původní odesílatel pošle e-mail třeba třiceti adresátům, z toho jeden adresát jefranta@example.com. Serverexample.comten e-mail přesměruje napepa@example.net, načež se vrátí původnímu odesílateli zpráva, že e-mail se nepodařilo na adresupepa@example.netdoručit. Co s tím bude odesílatel dělat? On e-mail na takovou adresu neposílal, vůbec nemusí vědět, ke které původní adrese ten e-mail patří. Navíc s tím přesměrováním nemůže nic udělat. Na tom je vidět, že správně řešení je přepsat obálkového odesílatele, tím pádem se chyba vrátí na přeposílající server, a tam je možné s tou chybou jednak něco dělat, jednak je možné informovat původního odesílatele, že se e-mail profranta@example.comnepodařilo doručit. SRS pak slouží k tomu, aby si nemusel přeposílající server pamatovat, který přeposlaný e-mail patří ke kterému přijatému – ale není nutné to používat, klidně si místo toho může vést tabulku původních a přeposlaných e-mailů.Mimochodem, dobře je to vidět také na tom, že e-mail je navržen tak, aby bylo možné posílat jej mezi různými druhy sítí. Takže ten přeposílající server také může být brána, která přeposílá e-maily mezi FidoNetem a Internetem. Příjemce nejspíš bude poštovní server, který umí komunikovat jenom přes Internet, takže nemůže případnou chybu poslat přímo původnímu odesílateli – musí ji poslat tomu, od koho e-mail dostal, a ten musí vědět, kam chybu předat dál.
-
Pali (neregistrovaný)
Ok, zlý príklad, v tom máte pravdu.
Ale stále je tu problém, keď doména obálkového odosielateľa a doména vo From nesedia. Pri validovaní DMARC je nutné aby boli domény zhodné.
Ak ale pri preposielaní obálkového odosielateľa prepíšem a email preposielam na inú doménu, tak to cez DMARC validáciu neprejde. V tomto prípade je nutné zachovať pôvodného obálkového adresáta.
-
j (neregistrovaný)
Hele bez na zive, tam ti to bude sluset vic. DMARC nic nikde nevaliduje, to zaprvy, zadruhy DKIM je podpis, a validuje se jestli sedi proti zverejnenymu podpisu (navic pro domenu, ktera je uvedena v tom podpisu, a ktera v principu muze byt jina nez odesilajici), tzn pokud neni, tak neni ani co validovat, a SPF resi jen to, jestli odesilajici server je opravnenej odesilat za danou domenu, ktera nema nic spolecnyho s from.
Ono se totiz predpoklada (coz ty ale nemuzes zjevne pochopit) ze pokud nekdo odesila pod svoji domenou (trebas skocdopole.cz) za nekoho kdo poslal from: skocdopole@seznam.cz ... tak ze si sam ve vlastnim zajmu overi toho manika ze seznamu. Vime?
-
Pali (neregistrovaný)
> DMARC nic nikde nevaliduje
RFC7489 3.1.
"DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier."
"In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
> DKIM je podpis, a validuje se jestli sedi proti zverejnenymu podpisu (navic pro domenu, ktera je uvedena v tom podpisu, a ktera v principu muze byt jina nez odesilajici)
RFC7489 3.1.1.
"In relaxed mode, the Organizational Domains of both the [DKIM]-authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322.From domain must be equal if the identifiers are to be considered aligned."
-
Filip JirsákStříbrný podporovatel
Aha, takže z DMARC není nesmyslná jenom to polovina, která umožňuje nechat si hlásit, kolik virů zrovna používá adresy z mé domény, ale i ta druhá polovina, která validuje adresu From místo obálkové adresy. To by mne nenapadlo, že někdo vezme údajnou chybu SPF, a reálně jí implementuje do nového doporučení.
-
Filip JirsákStříbrný podporovatel
Ale stále je tu problém, keď doména obálkového odosielateľa a doména vo From nesedia.
Problém s tím mají maximálně správci chybně nastavených serverů. Vůbec bych se nedivil, kdyby mezi e-maily, které nejsou spamem, byla nadpoloviční většina těch, které mají From a obálkového odesílatele různé. Je to totiž typické pro hromadně zasílané e-maily (ať už e-mailové konference, automaticky generované transakční e-maily nebo různé newslettery).Pri validovaní DMARC je nutné aby boli domény zhodné.
Na to jste přišel jak? -
Pali (neregistrovaný)
> Problém s tím mají maximálně správci chybně nastavených serverů.
To potom platí pre všetkých, ktorí zapínajú a vynucujú DMARC.
> Vůbec bych se nedivil, kdyby mezi e-maily, které nejsou spamem, byla nadpoloviční většina těch, které mají From a obálkového odesílatele různé.
Ani ja by som sa nedivil. Zas p=reject nie je až tak rozšírené.
> > Pri validovaní DMARC je nutné aby boli domény zhodné.
> Na to jste přišel jak?Píše sa to priamo v štandarde DMARC. Preto vravím, že to spôsobí problémy v kombinácií so SPF a .forward.
-
Jak je libo. Jestli se vám líbí, že kdokoliv může vaším jménem (jménem vaší firmy) kohokoliv e-mailem oslovit a napsat mu cokoliv, potom je v pořádku to všechno povypínat. Existuje celá řada způsobů, jak udělat mailing list kompatibilní s DMARCem , což je to momentálně jediná použitelná metoda pro boj s podvodnými e-maily, která nám umožní protistraně sdělit, že opravdu trváme na tom, že naše maily mají být naše a nemá je cestou nikdo měnit. Realita je taková, že mailing list do e-mailu zasahuje a proto je JEHO zodpovědnost, jak JÍM odeslaný mail vypadá. Podívejte se na to taky z hlediska typického zaměstnavatele... řekněte mu, že sice existují technologie, které částečně dokáží zabránit podvodným e-mailům, ale že to nebudete zapínat, protože to rozbije pár mailing listů, které mu, na rozdíl od těch potencionálně podvedených zákazníků, nevydělají ani korunu. Jestli máte lepší řešení, sem s ním, rád se poučím.
-
Filip JirsákStříbrný podporovatel
Jestli se vám líbí, že kdokoliv může vaším jménem (jménem vaší firmy) kohokoliv e-mailem oslovit a napsat mu cokoliv,
K tomuhle ale slouží elektronický podpis, nikoli SPF nebo DKIM. SPF a DKIM jsou záležitosti poštovních serverů, takže to není „jménem mým“ nebo „jménem firmy“, ale „jménem poštovního serveru“.Existuje celá řada způsobů, jak udělat mailing list kompatibilní s DMARCem
Já ale nechci nic dělat kompatibilní s DMARCem. E-mail tady byl dávno před DMARCem, pokud chce někdo přijít s něčím novým, ať to udělá buď zpětně kompatibilní, nebo ať udělá novou verzi e-mailu. DMARC porušuje pravidlo č. 1 e-mailu, totiž že poštovní server se řídí jen obálkovými adresami a tělo e-mailu je pro něj blackbox. Proto jsou ty dvě adresy zdánlivě „zduplikované“ na obálce, proto se používá ta analogie s pozemní poštou, která taky doručuje podle obálky a nestará se o vnitřek.Vzhledem k tomu, že e-mail může být podepsaný, server nemůže měnit jeho obsah. Takže z té celé řady způsobů zbývá asi jen vložení e-mailu jako přílohy do nového e-mailu, což je opravdu úžasné řešení.
což je to momentálně jediná použitelná metoda pro boj s podvodnými e-maily, která nám umožní protistraně sdělit, že opravdu trváme na tom, že naše maily mají být naše
Já znám jiné použitelné metody – třeba DKIM nebo SPF. DMARC je zbytečnost navíc, a ještě ke všemu škodlivá.nemá je cestou nikdo měnit
Právě, nemá je nikdo měnit, takže těžko můžu měnit hlavičku From, aby vyhověla DMARC. A nejenom, že je nemá cestou nikdo měnit, nemá je nikdo ani číst.Realita je taková, že mailing list do e-mailu zasahuje a proto je JEHO zodpovědnost, jak JÍM odeslaný mail vypadá.
Mailing list do obsahu e-mailu žádným způsobem zasahovat nemusí. Mailing list je odpovědný za obálku, ne za obsah. Je to jako když necháte rozeslat poštou letáky. Vy ručíte za obsah, pošta ručí za obálky a za doručení. Pošta vám nebude upravovat obsah letáku, a vy zase nebudete poště kecat do toho, že se někdo přestěhoval a chce to doručit na novou adresu.Podvodným e-mailům brání elektronický podpis. Podvodnému rozesílání brání SPF a/nebo DKIM.
-
Pali (neregistrovaný)
> Jestli se vám líbí, že kdokoliv může vaším jménem (jménem vaší firmy) kohokoliv e-mailem oslovit a napsat mu cokoliv, potom je v pořádku to všechno povypínat.
Nepáči sa mi to, ale DMARC to nerieši. Ak riešením myslíte aj zahodiť validné emaily (také, čo nie sú podvrhnuté), tak to rozhodne riešenie nie je.
> Existuje celá řada způsobů, jak udělat mailing list kompatibilní s DMARCem
Stále čakám na nejaký postup. Najprv ste mi navrhli dva, hoci ani jeden z nich nefunguje. A potom ďalší, ktorý nie je možné nasadiť v existujúcich OSS projektoch.
Mne netreba veľký zoznam/radu rôznych postupov, uspokojím sa s jedným, ktorý bude fungovať tak, že nezahodí validné emaily, ktoré doteraz prechádzali.
> což je to momentálně jediná použitelná metoda pro boj s podvodnými e-maily
Chcelo by to dôkaz, že je to naozaj jediná použitelná metóda. Takémuto tvrdeniu sa bude ťažko veriť, zvlášť keď zahadzuje netriviálny počet validných emailov.
Na zaistenie toho, že email nie je podvrhnutý, slúži podpisovanie emailu jeho odosielateľom. Nie nejakým SMTP serverom po ceste.
A ako som spomínal, keď ľudia budú používať UI, ktoré im zobrazí len meno odosielateľa a nie email (čo napr. robí GMail), tak podvrhnete emailov koľko len chcete aj cez zapnutý DMARC.
Čakám kedy niekto začne používať IDN domény, ktoré budú mať podobné znaky v emailovej adrese, a začne takto "podvrhávať" emaily, ktoré budú dokonca ešte aj DMARC validné...
-
Filip JirsákStříbrný podporovatel
Píše sa to priamo v štandarde DMARC. Preto vravím, že to spôsobí problémy v kombinácií so SPF a .forward.
Nikoli, problém není v kombinaci SPF a přeposílání e-mailů, to funguje perfektně. Problém je v kombinaci DMARC a SPF a obecně v tom, že se DMARC stará o obsah e-mailu. Poštovní server si obsahu e-mailu nemá vůbec všímat, v ideálním případě by byl celý obsah e-mailu zašifrován a poštovní server by si všímal jen obálky a hlaviček Received a DKIM (které fakticky vzato nepatří do těla e-mailu ale na obálku). -
velkorypadlo (neregistrovaný)
Ty jo, takove nesmysly v diskusi, to je je ulet.
A message satisfies the DMARC checks if at least one of the supported
authentication mechanisms:1. produces a "pass" result, and
2. produces that result based on an identifier that is in alignment,
as defined in Section 3. -
Martin Mareš (neregistrovaný)
> Co s tím bude odesílatel dělat? On e-mail na takovou adresu neposílal, vůbec nemusí vědět, ke které původní adrese ten e-mail patří.
Odesilatel se především dozví, že některému z příjemců zpráva nedorazila. I kdyby nevěděl kterému, je to pořád lepší, než když bude mail servery udržován v bláhové naději, že mail všem došel (což je přesně to, k čemu Váš návrh vede).
Jinak pokud odesilatel opravdu stojí o to, aby zjistil, o kterého z původních příjemců se jedná, může použít VERP (Variable Envelope Return Path). Mailing listy to už pěkných pár let dělají a funguje to docela spolehlivě.
-
Filip JirsákStříbrný podporovatel
Odesilatel se především dozví, že některému z příjemců zpráva nedorazila.
Což se dozví i při přepisu obálkové hlavičky. Je to zodpovědnost přeposílajícího serveru přeposlat mu chybovou zprávu.I kdyby nevěděl kterému, je to pořád lepší, než když bude mail servery udržován v bláhové naději, že mail všem došel (což je přesně to, k čemu Váš návrh vede).
Když neví, kterému adresátovi e-mail nedošel, je ta informace úplně k ničemu. Můj návrh k ničemu takovému nevede. Podle RFC má být v obálkovém odesílateli adresa, na kterou se mají zasílat chyby. Což je v případě přeposílání přeposílající server, protože ten jediný ví, komu má tu chybu doručit. Ostatně e-mailové konference to takhle dělají odjakživa – přeci jen těch e-mailů doručují trochu víc, než jeden přeposílač, takže si nemohou dovolit mít to nakonfigurované špatně. -
Filip JirsákStříbrný podporovatel
RFC5321 v části 3.3 říká, co má být v obálkové adrese odesílatele:
The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting).
Pokud tam server nechá původní adresu, je to špatně, protože o té adrese neví vůbec nic, neví jestli existuje, jestli je dostupná pro cílový server. Nebo snad někde ve standardu vidíte, že v obálkové hlavičce odesílatele může být jakákoli náhodná adresa, kterou si klient zrovna vymyslí?
V sekci 3.6.3 je pak napsáno, že server, který akceptoval e-mail k doručení, a dodatečně zjistí, že jej doručit nemůže, musí sestavit zprávu o nemožnosti e-mail doručit a tu zaslat právě na onu adresu obálkového odesílatele, kterou se dozvěděl od klienta.
If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path).Mimochodem, také je v této části napsáno, že přeposílající server nesmí čmuchat v obsahu e-mailu (mimo hlaviček Received kvůli detekci smyčky) a už vůbec je nesmí měnit, takže přepisování hlavičky From v e-mailu přeposílajícím serverem odporuje RFC.
Na přeposílání chybových zpráv není potřeba si udržovat vnitřní stav, je to jen otázka implementace. Server může použít SRS, může zpáteční adresu vložit do nějaké hlavičky.
-
Martin Mareš (neregistrovaný)
> Pokud tam server nechá původní adresu, je to špatně, protože o té adrese neví vůbec nic, neví jestli existuje, jestli je dostupná pro cílový server.
No to je přesně ta věc, o které mi vůbec není jasné, kde jste ji vzal. SMTP servery se od počátku věků chovají přesně tímto způsobem.
-
Filip JirsákStříbrný podporovatel
Má tam být mailbox which can be used to report errors. To těžko může být nějaká náhodná adresa, o které nevím vůbec nic (a na neověřenou obálkovou adresu se jinak než jako na náhodnou adresu dívat nemůžu). Má tam být adresa, na kterou je možné hlásit chybu – pochybuju o tom, že to je v RFC myšleno ironicky stylem „chyby můžete hlásit na lampárně“.
Nechovají se tak všechny servery, ale jenom ty jednodušší. Servery, které musely řešit složitější věci ohledně doručování e-mailů (např. servery e-mailových konferencí), obálkového odesílatele přepisují. To, že dříve nikomu nevadilo, že se do obálkové adresy odesílatele dávala nesmyslná adresa, neznamená, že to ničemu nevadí i dnes. Ostatně zprávy o nedoručení už se dnes neposílají, právě proto, že v té adrese je ve většině případů nějaká náhodná adresa a ne skutečný odesílatel. Zprávy o nedoručení je dnes možné odesílat jedině tehdy, pokud máte adresu odesílatele ověřenou, tedy pokud ji odesílající klient nastavil na nějakou adresu, za kterou je zodpovědný, a ověřilo se to přes SPF.
-
Při použití SRS se chyby hlásí na adresu, kterou SRS uvedlo jako MAIL FROM při navázání komunikace (oproti tomu je zároveň ověřeno SPF, pokud se používá). SRS se potom v případě chyby postará o odeslání zpět na původní adresu, která se dá ze SRS adresy vyčíst a navíc se kontroluje hash, aby nebylo možné díky SRS posílat e-maily kamkoliv. Mimochodem, u konferencí je většinou potřeba zpětné chyby odfiltrovat, protože když někdo něco pošle do konference, určitě ho nezajímá, kolik nefunkčních adres je aktuálně registrováno, jediné, co ho zajímá, pokud e-mail z nějakého důvodu konference odmítne ještě před distribucí dalším účastníkům.
Tahle opičárna se vyplatí pro konferenci, ale na běžném serveru nemá cenu. DMARC projde tak dlouho, dokud je v pořádku alespoň DKIM a jestli neprojde SPF není zase tak moc podstatné. Takže kdo si na domácím serveru provozuje nějaký mailing list, nic mu nebrání v instalaci třeba postsrsd.
Takže znovu, dokud konference nehrabe do obsahu, DMARC PROJDE!!! s platným DKIM a failnutým SPF (pokud nepoužívá SRS). Pokud konference do obsahu hrabe, DMARC stále může projít s failnutým DKIMem, ale platným SPF, pokud se použije SRS, ale podle mě by konference v takovém případě měla e-mail převzít (tělo) a poslat jej pod svými hlavičkami.
Takže stále nevidím žádný problém s nastavením konference tak, aby s DMARCem fungovala a nevidím ani problém v DMARCu. Naopak, pokud budu email zahazovat jen kvůli failnutému SPF, jak tu kdosi inteligentně navrhoval (což bych ani neměl, protože trvám na tom, že SPF nám jen sděluje, jestli podepisujeme, nebo ne, ale neuvádí žádnou politiku, jak se chovat v případě chyby), tak bude situace horší, než s DMARCem, protože přijdu o možnost doručení na základě korektního DKIMu.
-
Filip JirsákStříbrný podporovatel
DMARC projde s platným DKIM jedině tehdy, pokud se DKIM používá. Pokud se použije jen SPF (protože je to jednodušší, nebo protože e-maily odesílá cizí server), a přeposílající server nepřepíše obálkového odesílatele, tak DMARC neprojde.
DMARC stále může projít s failnutým DKIMem, ale platným SPF, pokud se použije SRS, ale podle mě by konference v takovém případě měla e-mail převzít (tělo) a poslat jej pod svými hlavičkami.
Ke změně hlaviček e-mailu není žádný důvod. Naopak u přeposílání je to špatně, protože přeposílající server nemá hlavičky e-mailu vůbec řešit a už vůbec je nemá měnit. U konference by se změna hlaviček ještě dala obhájit, že to není jen SMTP relay.nevidím ani problém v DMARCu
Problém DMARCu je v tom, že se váže na hlavičkuFromv e-mailu, do které e-mailovému serveru nic není. Ta hlavička může být klidně šifrovaná… Před několika lety proběhla českým internetem aféra, kdy jeden velký český poskytovatel freemailu doručoval e-maily podle hlavičkyTomísto obálkové hlavičky. Tenkrát se to řešilo jako nepředstavitelná chyba serveru, dnes se z doručování podle hlaviček e-mailu místo obálkových hlaviček dělá standard…(což bych ani neměl, protože trvám na tom, že SPF nám jen sděluje, jestli podepisujeme, nebo ne, ale neuvádí žádnou politiku, jak se chovat v případě chyby
A kvalifikátory (+, ?, ~, -) jsou podle vás v SPF k čemu? V příloze G RFC7208 máte doporučení ohledně politik. -
Použít DMARC bez DKIM absolutně nemá význam a rovnou se můžu (ne)spolehnout jen na SPF.
Mimo jiné
SPF "fail" results can alternately be used as one input into a larger set of evaluations that might, based on a combination of SPF "fail" results with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means).
Jsou tam doporučení, co je možné udělat, ale nikde není napsáno nic o tom, že nám odesílatel říká konkrétním nastavením konkrétní postup. Pokud budu e-maily zahazovat kvůli SPF, jak radíte, rozbiju tím víc věcí, než DMARCem.
Takže jediná relevantní věc, která vám evidentně vadí, je to, že DMARC kouká na From:. Já tomu sice rozumím, že to od něj není hezké, na druhou stranu to jinak prostě nejde. DMARC je třeba vnímat tak, že dělá práci za uživatele, kteří se ji za desítky let dělat nenaučili. Ano, uživatel by měl vyžadovat nějakou formu průkazného podpisu a jeho průkaznost by si měl i ověřovat, ale on to nedělal, nedělá a dělat asi ani nebude. Proto je tu DKIM s DMARCem, které dohromady ověřují, že je podpis jako takový správný a že je opravdu od odesílatele, respektive alespoň jeho domény, což je lepší, než nic. Berte to asi tak, že když si na schránku nalepíte "nevhazovat reklamní letáky", tak delegujete na pošťáka, který by měl bez keců doručit cokoliv od kohokoliv, možnost rozhodnout, co vám tam hodí a co ne.
Mimochodem, zrovna mě napadla zajímavá myšlenka, vytvořit každému uživateli vlastní DKIM klíč se selektorem podle username a tím si u ŘÁDNĚ INFORMOVANÉ protistrany zvýšit důvěru z "je to od nás" na "je to od nás a od konkrétního člověka".
-
Filip JirsákStříbrný podporovatel
Ano, DMARC ověří, že doména uvedená v hlavičce e-mailu není podvrh, načež e-mailový klient tu adresu vůbec nezobrazí. Takže jinak to samozřejmě dělat jde – například to nedělat vůbec, Což je pořád lepší, než to dělat špatně a dostat výsledek, který je k ničemu.
-
Filip Jirsák: aha... a spam filtry a antiviry taky nebudeme používat, protože nejsou stoprocentní... a navíc... ty mrchy běží na serveru, čtou tělo zprávy a na základě toho dělají nějaké závěry... TO JE SKANDÁL!!! Můžu se stavit na návštěvu? Předpokládám, že doma zásadně nezamykáte a možná nemáte ani dveře, protože ještě nikdo nevyrobil žádné dokonalé...
-
Filip JirsákStříbrný podporovatel
a spam filtry a antiviry taky nebudeme používat, protože nejsou stoprocentní...
To s něčím polemizujete?ty mrchy běží na serveru, čtou tělo zprávy a na základě toho dělají nějaké závěry...
Antipsam a antivir neběží na SMTP relay, fungují na MDA nebo-li na serveru, který doručuje do schránek. Můžete je chápat jako součást klienta poštovní schránky, jako uživatelský filtr ve schránce. -
Za prvé, antivir i antispam klidně na relay běžet můžou, stejně jako SPF, DKIM a DMARC a ať se vám to líbí, nebo ne, je to volba majitele relay serveru, kterou nijak neovlivníte. Jestli máte problém s DMARCem na relay, tak si jej tam neinstalujte, na zprávy nesahejte, SRS si používejte nebo nepoužívejte dle libosti, maximálně rozbijete SPF (což asi nechcete, když ho doporučujete místo DMARC) a do zprávy v rámci svých pevných zásad nesahejte, čímž necháte funkční alespoň DKIM a tím pádem i DMARC. Pro vás to není problém, pro mě to není problém, DMARC u odesílatele i jeho kontrola u příjemce vám může být zcela ukradená a dodržíte tím i to, že DMARC ověření proběhne až u MDA, což je dle vás zcela v pořádku. Ale teď už opravdu nevím, na co si stěžujete... Na špatně nastavené relay servery? Ale to jsem říkal už na začátku. Pokud je nastaven korektně, nic nerozbije a DMARC vůbec řešit nemusí.
-
j (neregistrovaný)
2Michal Pastrňák: Mas v tom peknej hokej ...
SPF nic nepodepisuje ani nesdeluje nic o podpisech a naopak zcela jasne rika, co si drzitel domeny preje aby se stalo s maily ktere jsou odeslany z jinych nez vyjmenovanych stroju.
A to za pomoci -/~/? ... cimz sdeluje, zda se ma dotycnej zaznam (pripadne vse) brat jako "zahodit" nebo "zhodnotit" nebo "brat v potaz".
Tzn mx -all rika, ze pokud neni mail odeslany ze serveru odpovidajicich MX zaznamum, tak ze si majitel preje aby byl zahozen, protoze takove maily neodesila.
Pokud by tam bylo mx ~all tak tim rika, ze sice posila z MX, ale ze se ani z ostatnich nema zahazovat rovnou, ale ma se to brat jako jedno z hledisek hodnoceni spamu.
Pokud by tam pak bylo mx ?all, tak tim rika, ze obecne posila maily odkudkoli, byt primarne pouziva mx.
-
j: Já taky netvrdím, že SPF něco podepisuje, od toho je tam DKIM, ale SPF jenom říká, odkud by tak mohl email přijít. A i když SPF zfailuje (-all), tak není nikde napsáno, ani jednoznačně doporučeno, že kvůli tomu MUSÍM, nebo bych alespoň MĚL mail zahodit. Je tam napsáno, že ho MOHU zahodit, nebo to MOHU použít jako jedno z kritérií pro další posuzování. Toto je dle RFC moje rozhodnutí a protistrana mi k tomu nic nenařizuje. (na rozdíl od DMARC, který obsahuje jasnou politiku). Mně osobně by se líbilo ho radši zahodit a to jak kvůli fail SPF, tak DKIM, ale už bylo pár takových, co to zkoušeli a zase si to většinou rozmysleli. Já spíš nechápu ten velmi speciální postoj, kdy zahodit něco kvůli SPF je v pořádku, ale zahodit to kvůli DMARC je strašnej problém a to asi jen proto, že DMARC kouká na From.
-
Filip JirsákStříbrný podporovatel
DMARC také nic nenařizuje, u použití politiky zveřejněné vlastníkem domény je SHOULD.
zahodit to kvůli DMARC je strašnej problém a to asi jen proto, že DMARC kouká na From
To, že DMARC kouká na hlavičku, do které serveru vůbec nic není a kde může být cokoli, samozřejmě je podstatný problém. Kdyby se DMARC rozhodoval podle prvního slova e-mailu nebo podle (textového) podpisu v e-mailu, připadalo by vám to normální? -
RFC 7208 (SPF):
SPF "fail" results CAN be used to reject messages during the SMTP transaction
SPF "fail" results CAN alternately be used as one input into a larger set of evaluationsRFC 7489 (DMARC):
Domain Owners publish policy assertions about domains via the DNS.
These receivers CAN use these results to determine how the mail SHOULD be handled.takže dle RFC:
MOHU zamítnout zprávu kvůli SPF
MOHU výsledek SPF použít jako součást vyhodnocování
MOHU použít politiku vlastníka k vyhodnocení, jak BYCH MĚL maily zpracovat. -
Martin Mareš (neregistrovaný)
Nevím, proč sem pořád pletete nějakou náhodnou adresu. Adresa odesilatele v obálce původního mailu je adresa zcela konkrétní, o které si odesilatel mailu přál, aby na ni chodily zprávy o nedoručitelnosti mailu. A nevšiml jsem si, že by si vymínil, že pokud k nedoručitelnosti dojde až po přeposlání, tak už ho to nezajímá ;)
Ale jak vidím, i Hurvínek si válku představoval o něco věrněji než Vy fungování mailu, takže další diskuse bude nejspíš zcela marná...
-
Filip JirsákStříbrný podporovatel
To, že si odesílatel přál odesílat na danou adresu zprávy o nedoručitelnosti, ještě neznamená, že je dobrý nápad na tu adresu zprávy posílat. Dnes chodí spousta spamu a virů, které mají adresy odesílatele falešné – a majitel té e-mailové adresy si rozhodně nepřál dostávat nějaké zprávy o nedoručitelnosti spamu nebo viru. Na tu adresu můžu doručovat chyby jedině tehdy, pokud jsem si ověřil, že ta adresa (nebo aspoň ta doména) je v pořádku. Jinak tu adresu musím považovat za náhodnou.
Nikde jsem nepsal, že po přeposlání původního odesílatele nedoručitelnost nezajímá. Ale když přeposílající server přijal e-mail k doručení, je jeho zodpovědnost, aby byla zpráva o nedoručitelnosti doručena odesílateli.
-
Martin Mareš (neregistrovaný)
Vaše interpretace standardů je opravdu úsměvná. Například si představujete, že přeposílající servery si budou udržovat nějaký vnitřní stav a přeposílat i chybové zprávy. To mi povězte, kde jste tuhle představu vzal (ideálně s citací standardu) a jestli jste někdy viděl nějaký mailový systém, který by to takto implementoval.
-
Martin Mareš (neregistrovaný)
> Bohužel třeba Postfix ve výchozím nastavení do přeposlaného e-mailu vkládá původního obálkového odesílatele, Google doporučuje u přeposlaných e-mailů zachovat původního obálkového odesílatele…
Což je odjakživa standardní způsob, jak se maily přeposílají. Jen autoři SPF to ignorují a tváří se, že se jejich svéhlavosti musí celý svět přizpůsobit. Ale kupodivu to ještě neudělal, nejspíš má rozum :)
-
Filip JirsákStříbrný podporovatel
Což je odjakživa standardní způsob, jak se maily přeposílají. Jen autoři SPF to ignorují a tváří se, že se jejich svéhlavosti musí celý svět přizpůsobit. Ale kupodivu to ještě neudělal, nejspíš má rozum :)
To, že se to v některých případech dlouho dělalo špatně, protože na tom zas tolik nezáleželo, neznamená, že je to správně. Navíc to není tak docela pravda, třeba e-mailové konference odjakživa e-maily přeposílají správně, tedy se změnou obálkového odesílatele. Přepis obálkového odesílatele není žádná svéhlavost, plyne to z RFC (má tam být e-mail, na který se mají doručovat případné chyby), a pokud se adresa nepřepisuje, rozbíjí to i jiné věci, než jen SPF – například doručování chybových zpráv. -
j (neregistrovaný)
Nejlepsi zpusob je poslat podobny debily doprdele, protoze jak uz rek tuxik, je to primitivne trivialne resitelny na strane konference.
Ta totiz stejne prepisuje hlavicky, a kdyz uz to dela, neni problem to poresit tak, aby vse bylo koser jak z pohledu spf tak dkim a tudiz i dmarc.
-
Cx (neregistrovaný)
Provozujeme poštovní servery už několik let a všechny nástroje popsané v tomto seriálu máme nějakým způsobem nasazené také a docela se těším, že se jich jednou zbavíme. Nastavit Postfix+Dovecot a k tomu kontrolu na viry, spam a podepisování přes DKIM je tak složitý, že i s podobným návodem se tomu člověk musí věnovat minimálně dny, než to funguje jak má a věří tomu. A pak když to funguje, tak to člověka třeba rok nezajímá, maximálně to aktualizuje a hlídá monitoring. Potom se něco stane a to kolečko učení může začít znovu a najít tam problém a opravit ho je opět akce na dny.
Proto bych měl pro budoucí správce mailových serverů několik rad:
* Zkuste se tomu vyhnout, Google Apps nebo Zoho nejsou tak drahý.
* Pokud to nejde, tak vynecháním Postfixu odstraníte 80 % komplexnosti.
* Alternativou je třeba Haraka, která se dá propojit s Dovecotem. Pohodlně i s kontrolou na viry a spam.
* SpamAssassin patří do muzea, lepší je si pohrát s rspamd.
* Debianí distra (Debian, Ubuntu) mají hezky připravenou konfiguraci Dovecotu, tam se s ním pracuje dobře.
* Největší problém provozovatele mail serveru je odchozí spam, ten příchozí vadí "jen" uživatelům.
* Proto je lepší příchozí a odchozí server oddělit na samostatné stroje, zjednoduší se tím konfigurace a zajistí se, že odchozí pošta nebude ovlivněna přeposílaným spamem.
* Rozhodně nepoužívat stejnou IP pro odesílání emailů od uživatelů a z webových aplikací. Ty Wordpressy, zvlášť když nejsou vaše, tam dřív nebo později někdo střelí. Pokud to není Wordpress ale něco custom co běží už roky bez upgradu, tak už to je pravděpodobně nabouraný.
* Pokud to jde, nepřeposílat emaily, protože SPF a protože vaše spamová kontrola nechytne všechno. Pak přeposíláte spam a dostáváte se na blacklist vy.
* Částečné řešení, alespoň pro SPF problém, je přepisovat takovým mailům obálku (SRS), ale když pak projde spam, způsobí to problémy všem uživatelům, protože některé blacklisty koukají i na doménu v obálce emailu.
* Na odesílání emailů z aplikací je lepší použít služby typu Mailgun nebo Mandrill.
* Pokud máte hodně uživatelů, tak je dobré mít třeba 10+ IP adres a hlídat co chodí ven a v jakém počtu. Když to je něco podezřelého tak hned zaříznout a změnit odchozí IP adresu. Ideálně automaticky, ale svět není ideální.
* Rate limiting je absolutní nezbytnost i když jste zatím problém s odchozím spamem neměli. Jednou to přijde.
* A poslední, pokud nemusíte, tak se do toho nepouštějte.Email je pro spoustu firem klíčovým nástrojem a jeho výpadek má následky. Blacklisty neovlivníte hned, ne všechny spolupracují, takže ne vždy se vám podaří vyřešit všechno během pár hodin. Budete rádi, když to bude ok druhý den. Během toho posloucháte uživatele a jejich příběhy o tom, jak jim končí byznys, protože se jim nepodařilo doručit email a víte, že s tím nemůžete nic dělat, protože to je prostě úděl sdílené služby. Vyladit všechno je na týdny až měsíce a navíc docela nepříjemné práce. Pokud to tedy jen trochu jde, tak se tomu vyhněte.
-
neuvadim (neregistrovaný)
Zdravim,
Jen bych doplnil:
Rate limit: me se osvedcilo kombinovat to s fail2ban, resp. nakonec spoustu veci resi prave fail2ban. Zejmena lamani hesel a vubec ruzne typy utoku. A da se to predradit jinam.
Nedavno me upozornil kolega na assp ze sourceforge. Vypada to zajimave. Akorat rozjet to na poslednim centosu je spise o tom zahodit to jejich howto a improvizovat.
Jo - aby to nevyznelo - ja perl moc nemusim, ale v dnesni dobe...
-
smal (neregistrovaný)
I treti dil je super, opravdu diky za clanek!
Uz se tesim na dil o SOGo, ani jsem nevedel, ze uz konecne neco takoveho existuje bez silenych Outlook pluginu a jeste navic free.
Az se budes nekdy nudit, slo by prosim pridat jeste provozovani mailing listu? Kdysi jsem jeden s odrenyma usima rozbehl, ale chybel mi tam 'big picture', cili vsechny ty mezipoznamky, ktery v textu mas :)
-
Když jsme u těch emailů, nechce redakce upravit posílání notifikačních emailů o nových komentářích?
Přijde email o novém komentáři, kde je:
Datum: 20. 6. 2017 16:56 Autor: (Michal Pástor)
Jméno autora je link vedoucí na profil autora:
https://www.root.cz/uzivatel/1116115/
Kde:
Údaj není veřejný. E-mail: Údaj není veřejný. Web: Údaj není veřejný. O mně: Údaj není veřejný.
A potom v diskusi je autor pod jménem
Tuxík.A jako autor článku je uveden Michal Pastrňák (https://www.root.cz/autori/michal-pastrnak/).
Nešlo by to trochu učesat? Spojit profily autora (jeden článkový a druhý komentářový) do jednoho? A ukazovat stejné jméno v emailu s komentářem a na komentáři? Nebo alespoň, pokud si tedy nepřeje ukazovat svoje jméno, neposílat je ani v emailu?
-
j (neregistrovaný)
Nebud blazen, tenhle pozadavek tu zaznel, uz nejmin 100x za posledni 2 roky ...
Jestli to chces vazne vyresit, tak podej stiznost na UOOU ... pripadne jeste tak rok pockej, a podej ji pak. To bude o dost veselejsi, protoze od kvetna pristiho roku za to iinfo muze dostat 30% obratu flastr.
-
velkorypadlo (neregistrovaný)
Jinak pro autora: dobre to je, jen takova drobnost - chtelo by to jeste nastavit a (pravidelne stahovat) PublicSuffixList (https://en.wikipedia.org/wiki/Public_Suffix_List) - viz treba zde: (https://www.stevejenkins.com/blog/2015/03/installing-opendmarc-rpm-via-yum-with-postfix-or-sendmail-for-rhel-centos-fedora/)
Jo a prichazi ARC. Brace for impact :)
-
velkorypadlo (neregistrovaný)
A mozna jeste par poznamek:
Existuje SRS - nechte si forwardovat neco pres seznam a podivejte se, co tam seznam dava do obalkoveho senderu :) Nakolik je to uzitecne pro maillisty jsem nezkoumal.
A SPF se da validovat i pres HELO/EHLO (ale ne pro DMARC)
Uzitecnou moznosti je nastavit postfix tak, ze na postgrey a ruzne blacklisty dojde jen kdyz odesilajicimu serveru dementni spravce nenastavil SPF.
-
_dmarc.google.com. 300 IN TXT "v=DMARC1\; p=reject\; rua=mailto:mailauth-reports@google.com" _dmarc.microsoft.com. 3600 IN TXT "v=DMARC1\; p=reject\; pct=100\; rua=mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com\; fo=1" _dmarc.yahoo.com. 1800 IN TXT "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_rua@yahoo.com\;" _dmarc.facebook.com. 3600 IN TXT "v=DMARC1\; p=reject\; pct=100\; rua=mailto:d@rua.agari.com,mailto:postmaster@facebook.com\; ruf=mailto:d@ruf.agari.com\;"
Zajímavý seznam malých firem, které neví, co dělají a mají tak rozbité e-maily, že se s nimi vlastně ani komunikovat nedá. Nemusím snad dodávat, že všichni používají i SPF a DKIM.
A proč by někdo měl chtít DKIM? V Česku třeba minimálně kvůli Seznamu? A to se minimálně firmám vyplatí, pokud chtějí rozesílat třeba newslettery.
Elektronický podpis v e-mailu může být bezva, ale co vlastně prokazuje? Že zprávu odeslal někdo konkrétní a že ji nikdo nezměnil. To je pro jednotlivce samozřejmě dobré, ale nechává to na příjemci, aby si alespoň poprvé ověřil, že je podpis pravý a že má právo třeba jednat za firmu. DKIM udělá v podstatě to samé, s tím rozdílem, že neověřuje jednotlivce, ale doménu (firmu). Navíc pomocí DMARC je zpráva zahozena, pokud není ani podepsána (nebo špatně), ani odeslána ze správného serveru. Toto je pro firmu mnohem větší benefit, než nějaký nic neříkající podpis nějaké konkrétní osoby.
Byl jsem svědkem toho, kdy jedna velmi "moudrá" paní účetní celkem velké stavební firmy "A" zanesla do systému nové číslo účtu dodavatele "B", protože jí to napsala jiná paní, se kterou před tím už několikrát komunikovala. Že si má takové věci potvrdit jiným nezávislým kanálem, to je pravda a byla blbost něco takového provést na základě e-mailu, ale ví to všechny účetní? Mimochodem, ten e-mail poslal "neposlušný propuštěný zaměstnanec" firmy "A", který si "vypůjčil" od dodavatele jeho adresu, okopíroval podpis (neelektronický) a měl asi za to, že zmizí za kopečky, než to někomu dojde. Jen zázrakem se na to přišlo a nic se mu neposlalo.
-
Filip JirsákStříbrný podporovatel
DKIM udělá v podstatě to samé, s tím rozdílem, že neověřuje jednotlivce, ale doménu (firmu). Navíc pomocí DMARC je zpráva zahozena, pokud není ani podepsána (nebo špatně), ani odeslána ze správného serveru. Toto je pro firmu mnohem větší benefit, než nějaký nic neříkající podpis nějaké konkrétní osoby.
K čemu je vám informace, že někdo opravdu odeslal e-mail z domény seznam.cz? A nic neříkající podpis konkrétní osoby? Vám je jedno, jestli vám objednávku za několik milionů poslal ředitel firmy nebo vrátný? Vtipné je, že jste pak sám uvedl příklad, že doména opravdu není podstatná, podstatný je podpis konkrétního člověka… -
Pokud mám jako firma vlastní doménu a vlastní mailserver, potom chci, aby přes něj chodila všechna moje pošta. Pořád platí, že nelze e-mail považovat za dostatečně spolehlivý kanál pro důležitá data, ale pořád je pro mě lepší, když může neoprávněnou objednávku odeslat "jenom vrátný a uklízečka", navíc z adres, které mám pod kontrolou, než když to může udělat kdokoliv. Problém digitálních podpisů je v tom, že se využívají málo a lidé vlastně většinou neví, co s tím. Podpis "Pepík Novák, ředitel zeměkoule" si může udělat kdokoliv a stejně to neznamená, že opravňuje daného člověka ředitelovat zeměkouli. Na to je nejprve potřeba si tu informaci ověřit, což bohužel udělá málokdo. Já jsem naopak uvedl příklad, kdy došlo k takovému zneužití důvěry v e-maily, kterému by DMARC zabránil. Ano, nezabránil by tomu, aby něco podobného udělal vrátný firmy B, ale pořád to bude alespoň člověk, kterého bude možné dohledat a ne někdo zcela anonymní s účtem založeným na bílého koně.
Samozřejmě, že ideální by v podobné komunikaci bylo PGP, ale schválně zkuste obejít vaše účetní, sekretářky, klidně manažery, jestli ví, co to je a jak to správně použít, aby to bylo důvěryhodné. A až je proškolíte, tak můžete vyrazit ke všem vašim dodavatelům a odběratelům a provést to samé.
Takže z toho důvodu považuju DMARC za alespoň částečně funkční řešení, které funguje automaticky za exaktních podmínek a je schopné zabránit alespoň něčemu, zatímco podpis v emailu automaticky nic nevyřeší a stále zůstává závislost na rozhodování lidí, kteří o tom většinou nic neví. Je to smutné, ideální by bylo zkombinovat oboje, ale... -
Filip JirsákStříbrný podporovatel
To, aby všechna vaše pošta chodila přes vaše servery, zařídí SPF a/nebo DKIM. DMARC k tomu vůbec není potřeba. DMARC neřeší vůbec nic, protože za prvé čmuchá v hlavičce From v e-mailu, do které e-mailovému serveru nic není, a navíc z té hlavičky řeší jen e-mailovou adresu, kterou zase velmi často nevidí uživatel. Pokud chcete jako firma zajistit správnost hlaviček From ve vašich e-mailech, nastavte si DKIM a podepisujte jím i hlavičku From.
-
Filip JirsákStříbrný podporovatel
Nerozumím tomu „něčím to kontrolovat musíte“. SPF i DKIM jsou samostatné protokoly – při přijetí e-mailu se podíváte, zda doména odesílatele má SPF, pokud ano, ověříte ho. Pak se podíváte, zda má klíč pro DKIM, pokud ano, ověříte ho. V obou případech může správce domény odesílatele určit, jak se má zacházet s e-maily, které pravidlům nevyhovují. DMARC k tomu vůbec nepotřebujete.
Tak proc neprihlednout k tomu, co vam rika skrze DMARC odesilatel?
Přihlédnout k tomu můžu. Problém je v tom, že DMARC řeší odesílatele e-mailu (v těle e-mailu), ale údaje má uvádět ten, kdo e-mail transportuje. Jako kdyby pošťák měl potvrzovat, co je uvnitř balíku. To samozřejmě nemůže obecně fungovat. -
SPF i DKIM sice můžou tvrdit, že email má být odněkud a má být nějak podepsaný, ale na základě jejich výsledků se nedoporučuje žádná přímá akce, protože SPF ani DKIM neobsahuje informaci o tom, jak s takovými e-maily naložit. Přesně tuto informaci obsahuje DMARC - tedy já jako odesílatel sděluji příjemci, co má dělat, pokud kontroly neprojdou. DMARC samozřejmě musí řešit adresu odesílatele, protože to je přesně to, co mě zajímá. Mně je úplně jedno, kolika servery ten e-mail prošel, mně zajímá, kdo ho poslal a jestli ho měl právo poslat. Má to samozřejmě svoje mouchy, protože DMARCu stačí, když má e-mail správný podpis, NEBO je odeslán ze správného místa, což v praxi znamená, že pokud někdo e-mail cestou změní, stále mi může projít SPF a stále ho DMARC pustí. Proto je taky dobré si v klientu DKIM kontrolovat, aby byl alespoň uživatel upozorněn, že něco nemusí být v pořádku.
Ke konferencím - pokud je konference správně nastavená a vnitřku e-mailu se ani nedotkne, je vše v pořádku a normálně to funguje. Pokud do mailu jakýmkoliv způsobem zasáhne (třeba přidá patičky s unregister linkem), už se nejedná o původní mail a je to její zodpovědnost, ona by si měla provést na vstupu kontroly, jestli je vše v pořádku a ona by měla poskytnout další kontrolní mechanismy na výstupu. Zároveň by měla e-mail kompletně převzít pod sebe, včetně from, protože když to neudělá, jakákoliv její chyba může poškodit reputaci zcela nevinného původního odesílatele.
-
Filip JirsákStříbrný podporovatel
Za prvé, jak už jsem psal, SPF i DKIM umožňují sdělit příjemci doporučení, jak má s e-maily naložit. Za druhé, příjemcem jsem já, takže já si rozhodnu o tom, jak s nimi naložím. Od správce serveru mi stačí jen informace, zda e-maily vůbec nepodepisuje, podepisuje některé nebo podepisuje všechny (analogicky SPF místo „podepisuje“ je „odesílá přes svůj server“).
Adresu odesílatele ať si DMARC klidně řeší, ale pak to nemohou řešit servery po cestě (kterým do obsahu e-mailu vůbec nic není), může to maximálně řešit cílový server při ukládání do schránky – a pak ale zase nemůže adresu odesílatele nijak srovnávat s tím, kudy e-mail putoval. E-mail byl od začátku postaven na tom, že putuje přes několik serverů. Už jenom doručení na záložní mail server znamená, že ho do schránky dostanete odjinud, než od původního odesílajícího serveru.
Kontrolu toho, kdo vám e-mail poslal, umožňuje jen DKIM. SPF umožňuje kontrolovat jenom to, od koho jste e-mail dostal. Což třeba úplně stačí ke kontrole toho, zda mu máte odpovídat v případě chyby.
Pokud konference něco mění, je to na její zodpovědnosti. Ale že by poškozovala reputaci původního odesílatele – pokud původní odesílatel nechtěl, aby se na -emailu něco měnilo, měl ho podepsat.
Není ale pravda to, že pokud konference nic nemění, je všechno v pořádku. Když konference nic nezmění a přepošle e-mail, nebude souhlasit odesílatel uvedený v hlavičkách e-mailu s doménou uvedenou v obálce e-mailu. Což je naprosto v pořádku, e-mail s tím od začátku počítá – ale nepočítá s tím DMARC.
-
M. (neregistrovaný)
Apropo, ještě k původnímu obsahu. Řešil jste někdo porovnání Dovecotu proti třeba Cyrus IMAP server, který je i v tom CentOSu také přítomen? Kdysi jsem přešel na Cyrus z Dovecotu kvůli velkým schránkám (to byla ještě doba Dovecot 1.x), které zvládal Cyrus lépe, tak jak si to stojí dneska.
Takový typický uživatel s 20.000 zprávami v inboxu i dalších složkách, kdy každá má pár desítek GB (cca 100 GB per uživatel sumárně a padesátka takových uživatelů na serveru, celkem 16 TB místa pro poštu, cca půlka zaplněná). Typická malá firma. :-) -
greensmileStříbrný podporovatel
Pár postřehů z víkendového zkoušení a těžce nabytích zkušeností:
1) DKIM a TXT záznam v DNS. Samozřejmě jsem udělal chybu při spojování řetězců ve vygenerovaném testmail2017.txt Pro převod z formátu BIND na požadovaný požadovaný formát DNS stačí použít:
cat testmail2017.txt | tr -d "\"\n\" \t" | sed -r "s/.*\((.*)).*/\\1\n/" > testmail2017-dns.txt.
Drobnost která ušetří spoustu času.
2) Z vesela jsme ignoroval nastavování ip6tables, že to "potom" převedu, až bude finální stav hotov. A jelikož jsem měl u všech řetězců jako výchozí politiku DROP... Jak se přidávaly jednotlivé komponenty komunikující přes síť (miltery apod.) narůstal postfixu transaction time. U mně to bylo až na 16 s oproti úvodním 1-2 s. Sledováním postfixu jsem zjistil, že se snaží komunikovat na IP6 na loopbacku [::1] a jelikož firewall měl komplet DROP (až na OUTPUT)... Z lenivosti jsem si do ip6tables přidal -A INPUT -i lo -j ACCEPT a transakční čas se vrátil k normálu, "potom" to dám do kupy... ;-)
3) Generování certifikátu s acme.sh mi přijde neuvěřitelně pomalé, jeho získání mi trvalo cca 35 minut (doba běhu acme.sh --signcsr --csr...) To je normální? Generoval jsem certifikát pro EU doménu hostovanou u Wedosu. S certbotem to bylo prakticky ihned.
4) Konfigurace amavisu mi k srdci dvakrát nepřirostla. Nešel mi spustit avamivsd jako služba a z výpisu chyby jsem se toho příliš nedozvěděl. Pomohlo ladění amavisd -c /etc/amavisd/amavisd.conf debug. Tak jsem zjistil chyby v konfiguraci (zapomenutý středník, zapomenutý $ apod.).
Dotaz na autora ke konfiguraci amavisu, konkrétně
@mynetworks = qw(127.0.0.0/8 [::1]/128 [2001:15e8:110:99e::1]/128 81.2.241.158/32);
chápu první dvě, co jsou ale zač adresy [2001:15e8:110:99e::1]/128 81.2.241.158/32? -
1) Ano, je to zákeřné
2) IP6 je potvora, spousta služeb se na něm primárně snaží
3) Trvá to pár vteřin, nemůže to také souviset s tou IPv6? Když jsem měl kvůli nějakým experimentům IPv6 "rozbitou", byl s tím docela problém
4) To jsou konkrétní adresy toho serveru. Někde na začátku jsem psal, že pracuji s existující konfigurací. -
greensmileStříbrný podporovatel
ad 3) Pravděpodobně to bude IP6, zkusím doladit ip6tables a zkusím znovu.
ad 4) [2001:15e8:110:99e::1]/128 81.2.241.158/32 korespondují s mail.testmail.cz? Já že mi dig mail.testmail.cz A vrátí 82.208.29.194. Předpokládám, že to poplatné době vzniku toho textu a mezitím se realita (ip adresa) změnila? -
greensmileStříbrný podporovatel
ad 3) Po sladění ip6tables to proběhne během několika sekund. Lenost se nevyplácí. ;-)
-
greensmileStříbrný podporovatel
Uvedená konfigurace DMARCu má zaručit, že když SPF test selže, tak se mail odmítne, tj. nedostane se do inboxu (resp. vůbec nedojde na LDA)?
-
greensmileStříbrný podporovatel
A když není DKIM a SPF selže tak se doručuje? Podle co zkouším já, tak ano. Šlo by todmítnutí postavit čistě na SPF v rámci DMARCu?
-
LDP (neregistrovaný)
Pokud nastavím DMARC dle návodu a pokouším se odeslat poštu z klienta (např. Thunderbird) prostřednictvím submission, pak server zprávu odmítne:
5.7.1 rejected by DMARC policy for ...Pro tento případ pomůže přidat IP adresu providera do souboru /etc/opendmarc/ignore.hosts. Co ale v případě, kdy se pokaždé připojuji z jiného místa nebo s jinou adresou?
-
Filip JirsákStříbrný podporovatel
Port 25 je určený pro komunikaci mezi servery. Pro odeslání e-mailu s poštovního klienta na server, který bude e-mail dál doručovat, slouží právě port 587. U portu 587 se očekává, že si server ověří, že je to „jeho“ klient. Rozdíl je v tom, že komunikaci na port 25 z domácích někteří ISP blokují, protože je velice pravděpodobné, že je to SPAM – naproti tomu k blokování portu 587 není žádný důvod.
-
Lukimanicka (neregistrovaný)
Zkoušel jsem nastavit amavis dle návodu, ale nemůžu jej spustit.
čec 13 10:27:36 mail.heluk.eu amavis[21786]: starting. /usr/sbin/amavisd at mail.heluk.eu amavisd-new-2.11.0 (20160426), Unicode aware, LANG="cs_CZ.utf8" čec 13 10:27:36 mail.heluk.eu amavis[21787]: (!)Net::Server: 2017/07/13-10:27:36 Can't connect to TCP port 10026 on 127.0.0.1 [Operace zamítnuta]\n at line 68 in file /usr/share/perl5/vendor_perl/Net/Server/Proto/TCP.pm čec 13 10:27:36 mail.heluk.eu systemd[1]: PID file /var/run/amavisd/amavisd.pid not readable (yet?) after start. čec 13 10:27:36 mail.heluk.eu systemd[1]: amavisd.service never wrote its PID file. Failing. čec 13 10:27:36 mail.heluk.eu systemd[1]: Failed to start Amavisd-new is an interface between MTA and content checkers.. -- Subject: Unit amavisd.service has failed
Nemá někdo nápad, kde by mohl být zakopaný pes?
Díky
-
Lukimanicka (neregistrovaný)
To jsem zkoušel a tady to vypadá, že to jede. Dokonce i netstat hlásí, že na těch portech naslouchá. Ale přes systemctl ho nespustím s výše uvedenou chybou.
# netstat -a -n | grep 1002 tcp 0 0 127.0.0.1:10024 0.0.0.0:* NASLOUCHÁ tcp 0 0 127.0.0.1:10025 0.0.0.0:* NASLOUCHÁ tcp 0 0 127.0.0.1:10026 0.0.0.0:* NASLOUCHÁ tcp6 0 0 ::1:10024 :::* NASLOUCHÁ tcp6 0 0 ::1:10026 :::* NASLOUCHÁ
A mejl uvízne nejspíš v postfixu, takže se nedoručí.
-
Tak možná zkontroluj volbu
$pid_file = "/var/run/amavisd/amavisd.pid"
v amavisd.conf, případně spusť amavis v debug režimu a ve druhým terminálu zkus ten PID file ověřit, jestli je tam, kde má být. Případně mrkni do /usr/lib/systemd/system/amavisd.service, jestli tam není špatná cesta ke konfiguráku... -
Lukimanicka (neregistrovaný)
Tak jsem to zkontroloval a zkusil. Pokud jsem to spustil v debugu tak ve /var/run/amavisd/ je jenom soubor amavisd.lock s velikostí 0. Ještě jsem zkouknul nastavení služby /usr/lib/systemd/amavisd.service a všechno je tam ok. Zkusil jsem jsem ještě spustit
/usr/sbin/amavisd -c /etc/amavisd/amavisd.confProvedlo se bez chyby, ale na status té služby to nemělo vliv, zůstala failed. A pid soubor se taky nezapsal.
-
Na status služby to mít vliv nemůže, protože si to nespustil sD. Každopádně vyzkoušej, jestli to opravdu běží a zkus přes to prohnat e-mail. Pokud ano, skoro to vypadá jen na problém s tím PID filem. Ještě jednou se mrkni do amavisd.conf, jestli je tam opravdu ten pid file správně a zkontroluj oprávnění na složce, kde má být...
-
Lukimanicka (neregistrovaný)
Takže shrnutí:
Kontrola /etc/amavisd/amavisd.conf
$pid_file = "/var/run/amavisd/amavisd.pid";Spuštění systemd služby:
# systemctl start amavisd
Job for amavisd.service failed because a configured resource limit was exceeded. See "systemctl status amavisd.service" and "journalctl -xe" for details.Spuštění v debug módu:
# /usr/sbin/amavisd -c /etc/amavisd/amavisd.conf debug
Funkční, PID soubor vytvořen a projdou přes to i mejly. -
Lukimanicka (neregistrovaný)
Status:
# systemctl status amavisd.service
amavisd.service - Amavisd-new is an interface between MTA and content checkers.
Loaded: loaded (/usr/lib/systemd/system/amavisd.service; enabled; vendor preset: disabled)
Active: activating (start) since Čt 2017-07-13 15:17:58 CEST; 631ms ago
Docs: http://www.ijs.si/software/amavisd/#doc
Control: 3737 (amavisd)
CGroup: /system.slice/amavisd.service
└─3737 /usr/bin/perl -T /usr/sbin/amavisd -c /etc/amavisd/amavisd.conf
čec 13 15:17:58 mail.heluk.eu systemd[1]: amavisd.service holdoff time over, scheduling restart.
čec 13 15:17:58 mail.heluk.eu systemd[1]: Starting Amavisd-new is an interface between MTA and content checkers....Journalctl -xe
-- Unit amavisd.service has begun starting up.
čec 13 15:18:45 mail.heluk.eu amavis[3850]: starting. /usr/sbin/amavisd at mail.heluk.eu amavisd-new-2.11.0 (20160426), Unicode aware, LANG="cs_CZ.utf8"
čec 13 15:18:45 mail.heluk.eu amavis[3851]: (!)Net::Server: 2017/07/13-15:18:45 Can't connect to TCP port 10026 on 127.0.0.1 [Operace zamítnuta]\n at line 68 in fi
čec 13 15:18:45 mail.heluk.eu systemd[1]: PID file /var/run/amavisd/amavisd.pid not readable (yet?) after start.
čec 13 15:18:45 mail.heluk.eu systemd[1]: amavisd.service never wrote its PID file. Failing.
čec 13 15:18:45 mail.heluk.eu systemd[1]: Failed to start Amavisd-new is an interface between MTA and content checkers..
-- Subject: Unit amavisd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-develaudit.log:
ype=SERVICE_START msg=audit(1499952083.195:2556): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
type=SERVICE_START msg=audit(1499952083.427:2557): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1499952083.427:2558): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1499952085.090:2559): avc: denied { name_bind } for pid=3917 comm="/usr/sbin/amavi" src=10026 scontext=system_u:system_r:antivirus_t:s0 tcontext=system_u:object_r:spamd_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1499952085.090:2559): arch=c000003e syscall=49 success=no exit=-13 a0=7 a1=51672c0 a2=10 a3=10 items=0 ppid=3916 pid=3917 auid=4294967295 uid=990 gid=987 euid=990 suid=990 fsuid=990 egid=987 sgid=987 fsgid=987 tty=(none) ses=4294967295 comm="/usr/sbin/amavi" exe="/usr/bin/perl" subj=system_u:system_r:antivirus_t:s0 key=(null)
type=SERVICE_START msg=audit(1499952085.143:2560): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
type=SERVICE_START msg=audit(1499952085.428:2561): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1499952085.428:2562): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1499952087.089:2563): avc: denied { name_bind } for pid=3922 comm="/usr/sbin/amavi" src=10026 scontext=system_u:system_r:antivirus_t:s0 tcontext=system_u:object_r:spamd_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1499952087.089:2563): arch=c000003e syscall=49 success=no exit=-13 a0=7 a1=58242c0 a2=10 a3=10 items=0 ppid=3921 pid=3922 auid=4294967295 uid=990 gid=987 euid=990 suid=990 fsuid=990 egid=987 sgid=987 fsgid=987 tty=(none) ses=4294967295 comm="/usr/sbin/amavi" exe="/usr/bin/perl" subj=system_u:system_r:antivirus_t:s0 key=(null)
type=SERVICE_START msg=audit(1499952087.136:2564): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
type=SERVICE_START msg=audit(1499952087.427:2565): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=SERVICE_STOP msg=audit(1499952087.427:2566): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=amavisd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' -
ttt (neregistrovaný)
Je někde v návodu zajištěné, aby postfix odesílal z té "správné" IP adresy, která je uvedená v SPF záznamu? Narazil jsem na to, že server má víc IPv6 adres a postfix používá pro odeslání jinou než tu, na kterou je nasměrovaný MX záznam.
Napadá mě, že bych buď mohl nastavit všechny adresy serveru do MX záznamu, což zní nepraktivky, nebo přinutit postfix používat jednu konkrétní adresu nebo nastavit smtp_bind_address(6), viz https://serverfault.com/questions/92181/how-to-make-postfix-use-another-ip-address.
-
dzakobolos (neregistrovaný)
Nebylo by jednodussi pouzit nektery z jiz predpripravenych mail serveru, ktery bude mit jiz vse v sobe? Napriklad tento EVO Mail Server, ktery beha na Windows? Viz https://pocitace-a-internet.blogspot.com/2017/01/nastaveni-mailoveho-serveru-na-windows_99.html
-
Cenda (neregistrovaný)
Článek je hezky napsaný a postup instalace super. Jen se potýkám s problémem ohledně doručení mailů na gmail. Na ostatní mailservery (seznam, centrum a jiné) mail dorazí do doručené pošty. Napadne někoho důvod, proč google vyhodnocuje maily jako spam?
VPS CentOS7 u Forpsi
DNS u Wedos
DNS záznamy a PTR jsou nastaveny na hostname serveru
DKIM, DMARC a SPF je ok.díky za radu
Č. -
Honza (neregistrovaný)
Ahoj, zkoušel jsem nastavit mailserver dle návodu, bohužel jsem prozatím úplný začátečník v této oblasti. Vše se zdá funkční, až na jednu maličkost. Když odesílám email z terminálu přes echo na nějaký gmail, všechny zabezpečení jsou PASS dkim, spf i dmarc. Pokud si ale přidám účet přes imap a smtp do emailového klienta, žádné z toho zabezpečení při odeslání emailu na gmail nevidím, jen SPF je NEUTRAL. Je třeba toto nastavení řešit v emailovém klientovi nebo na straně serveru? Děkuji za odpovědi!
