Dotaz: postfix - bounce na jiný stroj

[xts]

Zdravím,

mám stroj který odesílá emaily členům jednoho sdružení - řekněme server1.domena.cz. Jedná se o debian Wheezy + postfix.

Protože vyhazuju nefunkční, plné apod. emaily, nastavuje systém return-path pro NDR bounce message s kódem, podle kterého jde identifikovat adresa, o kterou se jedná - např. bounce123456@server1.domena.cz.

MX záznam pro server1.domena.cz jde na úplně jiný stroj - server2.domena.cz, kde je doménový koš který tohle shromažďuje (ten první je jen pro rozesílání, nemá vůbec schránky ani local delivery atd).

Ručně vše funguje - pokud pošlu něco na test@server1.domena.cz, skončí to správně v doménovém koši na server2.domena.cz.

1, Problém je, že servery někdy odpovídají přímo tomu stroji co rozesílá, místo aby provedly DNS MX dotaz a poslali to tomu stroji co je v DNS uveden. Předpokládám, že se to děje v rámci pořád navázaného smtp spojení, nebo něco podobného? Server1 se tváří že se o tu doménu stará a ty emaily "přijme", načež hodí hlášku že tam ta lokální schránka neexistuje.

2, Pokud ale změním doménu pro bounce message, tedy bude to bounce12345@server2.domena.cz, všechny servery odpoví správně tam, tady (opět předpokládám) že server1 ty maily už nepřijme, takže servery provedou DNS dotaz a pošlou to tam kam to patří.

Radši bych ale měl nastavení podle 1, protože podle 2 tam je jiná doména. Jenže u nastavení 1, jakmile přijde jakýkoliv bounce message, server1 hodí druhý bounce message - klasický postfixový "User unknown", protože schránka bounce12345@server1.domena.cz tam opravdu neexistuje.

Napadá vás jak tohle vyřešit nějak elegantněji - jinak než z toho udělat mailserver co ty maily bude i přijímat? Je ta varianta 2 moc velká kravina z hlediska doručování apod? (samozřejmě předpoklad je i korektně nastavené SPF, DKIM..)

díky za nápady

Odpovědi

[NN]

Pochopil jsem dobre, ze server1 funguje jako relay pro domena.cz, ktera preposila maily dovnitr na server2? Pokud ano pak nerozumim tomu, proc MX zaznam neukazuje na server1?

[xts]

server1 je jen smtp server - tedy jen posílá, nic nepřijímá a nemá žádné lokální mailboxy.

nevím jestli jsem to napsal úplně jasně v tom prvním příspěvku, zkusím to ještě jinak:

- pokud by doména byla seznam.cz, tak:

server1 = smtp.seznam.cz - jen odchozí, nic nepřijímá
server2 = mx1.seznam.cz - přijímá maily pro @seznam.cz

[NN]

No tak v tom pripade by mel server1 odesilat pres server2, tzn. pres ten server ktery ma MX zaznam. Server1 prece nemuze komunikovat ven menem domeny o kterou se nestara.

[xts]

jak to? pokud použiju libovolný smtp server libovolného poskytovatele konektivity, tak se taky nestarají a dokonce neví vůbec nic o doménách emailů, které posílají.. v čem je tedy problém?

Jestliže je server1.doména.cz FQDN, tak MX záznam pro server1.doména.cz nemůže jít na server2.doména.cz. MX záznam pro FQDN je A záznam toho FQDN. Zatímco MX záznam pro doména.cz je nějaký FQDN.

[xts]

ještě si úplně nerozumíme, opět upřesním:

automatické bounce by měly chodit na Return-Path - pokud Return-Path nastavím na bounce12345@server2.domena.cz tak v pořádku dojdou - tedy servery se evidentně dotážou DNS na MX záznam pro @server2.domena.cz, zatímco pokud nastavím Return-Path na bounce12345@server1.domena.cz, tak se ty servery na MX záznam vůbec nedotážou - protože pokud by se dotázaly, tak by to musely poslat na server2 (MX záznam je něco jako @server1.domena.cz MX 10 server2.domena.cz).

Proto se tu ptám jak to funguje, protože mi to přijde divný - ta odpověď musí probíhat v již navázaném smtp spojení - server nemá zvenku povolený žádný porty, takže to firewall musí propouštět dle RELATED/ESTABLISHED

[NN]

Pokud komunikujes pres server poskytovatele, komunikujes jeho jmenem a to jenom proto, ze ti to dovoli, protoze jses na jeho siti, ale venku to takto proste nefunguje. Nemuze si kazdy posilat co chce a komu chce, MX zaznamy reprezentuji postovni servery, ktere reprezentuji konkretni domeny. Nerozlisujes klient/server a server/server komunikaci..

[pupu]

To je absolutni nesmysl. Servery odesilajici mail pro urcitou domenu nemusi k te domene mit zadny vztah a uz vubec na ne nemusi smerovat MX. Pletes si smerovani posty, MX zaznamy a overovani odesilatele, napriklad pres SPF.

[Kriegel]

1, Problém je, že servery někdy odpovídají přímo tomu stroji co rozesílá, místo aby provedly DNS MX dotaz a poslali to tomu stroji co je v DNS uveden. Předpokládám, že se to děje v rámci pořád navázaného smtp spojení, nebo něco podobného? Server1 se tváří že se o tu doménu stará a ty emaily "přijme", načež hodí hlášku že tam ta lokální schránka neexistuje.

Jestli je hostname totozny s "domenou", tak to postfix bere jako default pro mydestination a snazi se ji taky lokalne dorucit. Pokud zmizi z mydestination, tak by mela byt routovana dle MX, pripadne dalsich definovanych mechanismu.

[xts]

ano - hostname je FQDN - server1.domena.cz - to bude přesně ono.

v main.cf mám pouze

myhostname = server1.domena.cz

můžu to smazat úplně - tedy může být postfix bez myhostname/mydomain?

Nevím jestli nedělám moc velkou opičárnu, ale prostě potřebuju aby jeden server odesílal a druhý řešil bounce, odpovědi, běžné emaily atd - a nerad bych bych na prvním zprovozňoval lokální inboxy, otevíral porty atd.

Pokud zmizi z mydestination, tak by mela byt routovana dle MX, pripadne dalsich definovanych mechanismu.

to ale bude posílat dle MX můj postfix ne? Tedy, ne že by to vadilo, jen mě ještě zajímá, jestli ty servery odpovídají opravdu v rámci navázaného spojení, místo aby si zjistily kam ukazuje Return-Path

[Kriegel]

můžu to smazat úplně - tedy může být postfix bez myhostname/mydomain?

Ne, ja jsem mluvil o mydestination, ne o myhostname, takze mydestination= Jinak pocitej s tim, ze to ovlivni jakouli lokalni postu, tedy errory z cronu atp...

to ale bude posílat dle MX můj postfix ne? Tedy, ne že by to vadilo, jen mě ještě zajímá, jestli ty servery odpovídají opravdu v rámci navázaného spojení, místo aby si zjistily kam ukazuje Return-Path

Samozrejme, bounce vzdy musi generovat to MTA, ktere nebylo schopne dorucit dal (nedostalo 250 pri end-of-data); co je vlastne return-path? Jen informace extrahovana z MAIL FROM, vlozena jako header. Nakladani s timto headerem ma sva specifika, nicmene to tebe ted moc zajimat nemusi, protoze pokud provadis submission na tom stroji, tak by tam tohle byt nemelo, to vlozi az server, ktery dorucuje finalne (do mailboxu).

Tvuj server (ted jako klient) se pripoji nekam, predstavi se, rekne MAIL FROM:<server1.domena.cz>, dostane ok, rekne RCPT TO:<none@domain> a nedostane ok a pokud je to jediny recipient, tak session ukonci a otevre novou v ktere dorucuje "bounce" na puvodce toho mailu (z MAIL FROM), ktery nebyl schopen predat dal, t.j. musi zjistit, ka teremu serveru se pripojit; defaultne podle MX/A, pripadne podle definovaneho transportu, smart hosta, atp.

Na tomto chovani /nechovani je postaven cely spam. MAIL FROM a From: nemusi byt stejne a pokud servery prijmou cokoliv a resi to pozdeji, t.j. generuji bounces, pak davaji vsanc svou ip/domenovou reputaci a povetsinou do toho zatahuji treti stranu, ktera je pak prijemcem vsech tech bounces (backscatter).

[xts]

Ne, ja jsem mluvil o mydestination, ne o myhostname, takze mydestination= Jinak pocitej s tim, ze to ovlivni jakouli lokalni postu, tedy errory z cronu atp...

mydestination v main.cf vůbec nemám, mám tam pouze:

myhostname=server1.domena.cz
inet_interfaces = loopback-only
inet_protocols = ipv4
mynetworks = 127.0.0.0/8

alias_maps = hash:/etc/aliases

pak už jen věci jako queue lifetime, destination concurrency, dkim milter atd. takže pomůže přidat "mydestination =" ? maily pro roota mám forwardované na email úplně jinde, takže výpisy z cronu atd mi tam chodí.

Tvuj server (ted jako klient) se pripoji nekam, predstavi se, rekne MAIL FROM:<server1.domena.cz>, dostane ok, rekne RCPT TO:<none@domain> a nedostane ok a pokud je to jediny recipient, tak session ukonci a otevre novou v ktere dorucuje "bounce" na puvodce toho mailu (z MAIL FROM), ktery nebyl schopen predat dal, t.j. musi zjistit, ka teremu serveru se pripojit; defaultne podle MX/A, pripadne podle definovaneho transportu, smart hosta, atp.

aha - už to asi chápu, takže server to zkusí poslat na lokální mailbox, který tam není, a tak hodí hlášku pro postmaster@server1.domena.cz (mám nastaveno bounce_notice_recipient a error_notice_recipient na postmaster@server1.domena.cz) - což je ta hláška pro lokální inbox že "user not exist", no a postmaster mám přes aliases opět forwardovaný na jinou emailovou adresu - takže tím se mi to dostane... takže potřebuji jen postfix donutit k tomu aby pochopil že tam žádné lokální schránky nejsou - tím prázdným mydestination?

Na tomto chovani /nechovani je postaven cely spam. MAIL FROM a From: nemusi byt stejne a pokud servery prijmou cokoliv a resi to pozdeji, t.j. generuji bounces, pak davaji vsanc svou ip/domenovou reputaci a povetsinou do toho zatahuji treti stranu, ktera je pak prijemcem vsech tech bounces (backscatter).

chápu - pokud ty bounce cizí server generuje sám, tak mu můžu podvrhnout nějaký fake cíl a oni ho zahltí odpovědma pokud jich bude dost - takhle fungoval i ten ntp DoS útok pokud vím.. Podle čeho se ten server v téhle fázi rozhoduje zda to přijme nebo odmítne? zkontroluje rDNS, SPF, blacklisty, pokud je to ze stejné domény mělo by to taky mít velkou váhu? (jako v mém případě). DKIM, content filter apod. jsou předpokládám v tuhle chvíli ještě mimo

[GeorgeWH]

$mydestination je defaultne $myhostname, localhost.$mydomain, localhost, co je v tvojom pripade ok.

neodosielas nahodou maily s domenovou castou server1.domena.cz - niekto@server1.domena.cz?

[xts]

$mydestination je defaultne $myhostname, localhost.$mydomain, localhost, co je v tvojom pripade ok.

to jsem si myslel, ale trochu mě znejistil Kriegel tím "Ne, ja jsem mluvil o mydestination, ne o myhostname" - tak jsem radši vypsal co tam mám.

neodosielas nahodou maily s domenovou castou server1.domena.cz - niekto@server1.domena.cz?

ano, přesně tak to odesílám - Return-path je bounce12345@server1.domena.cz, a "From" co vidí uživatel je info@server1.domena.cz (to bude asi i MAIL FROM?).

Ty "From" adresy na tomhle stroji ale neexistují, a já potřebuju nějak postfix donutit aby NDR bounce zprávy posílal na ten druhý stroj kde je doménový koš

[Kriegel]

Zjednodusene, Return-Path je MAIL FROM. From: header je zcela jina zalezitost -- to je to, co vidi prijemce v MUA. Pokud na ten mail bude odpovidat masina, pouzije MAIL FROM. Pokud na to v MUA klikne user a posle dotaz zpet, MUA to automaticky adresuje na info@server1.domena.cz, pokud neni definovan Reply-To: header.

Nevim, cim to posilas, ale Return-Path vklada az server, ktery provadi finalni doruceni, tedy do mailboxu. Pokud se jedna o originalni submission (podle popisu ano), tak bys nemel s Return-Path vubec nijak manipulovat; nejaky starsi phpmailer to delal defaultne a neslo to vypnout, ale to je z hlediska pravidel spatne, to jen pro uplnost...

[GeorgeWH]

tak si maily preposielaj. na server1.domena.cz do /etc/aliases pridaj

bounce12345@server1.domena.cz kam_chces@server2.domena.cz

[Kriegel]

mydestination v main.cf vůbec nemám, mám tam pouze:

fajn, uz vis, co znamena defaultni jinak man postconf

takže pomůže přidat "mydestination =" ? maily pro roota mám forwardované na email úplně jinde, takže výpisy z cronu atd mi tam chodí.

pokud to udelas takhle, tak ti forward pres aliasy nebude fungovat (to pouziva jen local agent, ktery ale v tomto pripade nebude vubec volan)

zkus mydestination=localhost.$mydomain, localhost a roota adresuj jako root@localhost

takže potřebuji jen postfix donutit k tomu aby pochopil že tam žádné lokální schránky nejsou - tím prázdným mydestination?

email fungue "per-domain". Postfix musi vedet, ze domena neni lokalni

Podle čeho se ten server v téhle fázi rozhoduje zda to přijme nebo odmítne? zkontroluje rDNS, SPF, blacklisty, pokud je to ze stejné domény mělo by to taky mít velkou váhu? (jako v mém případě). DKIM, content filter apod. jsou předpokládám v tuhle chvíli ještě mimo

tak to je prave to, na cem se vydelavaji $ :) je to kombinace vseho mozneho, od te nejnizsi urovne, t.j. jestli striktne dodrzuje protokol, reputace IP, rDNS, SPF je u bounces k nicemu, protoze prazdne MAIL FROM, stejnetak je pro mnohe pripady kontroverzni i pro normalni provoz, atd... tohle vsechno se da statisticky sledovat a pak s tim nakladat. Pro normalni "hobby" provoz nepotrebujes nic extra, uz jen kombinace par zakladnich a dostupnych kontrol ti odboura naprostou vetsinu.

Jinak tyhle veci se obecne resi takto: mas namespace domena.cz, systemove veci posilas lokalne nebo do internetu s domenou server1.domena.cz, pripadne to maskujes. Pro masove zalezitosti mas separatni namespace, napr. bounces.domena.cz a s tou odesilas (MX pro vratky dle libosti). Pokud trackujes adresy, jestli jsou ok/nok, tak se podivej na VERP, odpadne ti slozitejsi parsovani nebo matchovani oproti databazi. Pokud ne primo VERP, tak pouziti "plus addressing" ma taky svoje vyhody, konkretne treba v tvem pripade, pokud bys posilal ve tvaru bounces+12345@server1.domena.cz, tak si muzes nechat nastaveni jak mas, jen nadefinujes alias bounces s cilem kos@server2.domena.cz a ses hotov.

Moznosti je spousta, zalezi, co mas, muzes a chces. Technicka realizace je az to posledni, co ti potvrdi, jestli je ten design zivotaschopny...

[xts]

velmi děkuju (oběma) za opravdu detailní rozbor. Ano, je tam nastaveno něco jako VERP, celou tuhle opičárnu potřebuju proto že servery často odpovídaj dost šíleně - to že Out-of-office apod. chodí kolikrát na return-path místo na From nebo Reply-to už jsem si zvykl, ale za totální šílenost považuju NDR odpovědi s diakritikou, lahůdky jsou odpovědi kde je jen odesílatel, čas odeslání, a tělo obsahuje jen "user honza not found in domino directory", "user Ales not found", případně "ales@localhost not found" a podobně v milionu různých obměn - proto potřebuju tu adresu bezpečně určit podle adresy odesílatele.

Ještě bych poprosil o vysvětlení tohoto:

konkretne treba v tvem pripade, pokud bys posilal ve tvaru bounces+12345@server1.domena.cz, tak si muzes nechat nastaveni jak mas, jen nadefinujes alias bounces s cilem kos@server2.domena.cz a ses hotov.

to "+" tam má nějaký speciální význam? není mi jasný jak nadefinovat alias když je tam doménový koš a každá adresa je jiná - tedy pro všechny adresy

[Kriegel]

Ano, je tam nastaveno něco jako VERP, celou tuhle opičárnu potřebuju proto že servery často odpovídaj dost šíleně - to že Out-of-office apod. chodí kolikrát na return-path místo na From nebo Reply-to už jsem si zvykl, ale za totální šílenost považuju NDR odpovědi s diakritikou, lahůdky jsou odpovědi kde je jen odesílatel, čas odeslání, a tělo obsahuje jen "user honza not found in domino directory", "user Ales not found", případně "ales@localhost not found" a podobně v milionu různých obměn - proto potřebuju tu adresu bezpečně určit podle adresy odesílatele.

Neco jako VERP nemusi nutne znamenat VERP. VERP vyuziva prave toho, ze adresat (jeho adresa) je primo obsazena v MAIL FROM, tedy v adrese odesilatele. Problemy s dorucenim jsou pak reportovany zpet, na tuto 'MAIL FROM', ne na From nebo Reply-To (nekde vys jsem popisoval proc, ve zkratce mail server neparsuje 'DATA' cast, pri transportu operuje s 'MAIL FROM' a 'RCPT TO'). OoO je stejny pripad, je to automaticky generovana zprava, jde zpet na 'MAIL FROM'. Prave proto, ze jde zpet, mas tu zavadnou adresu naservirovanou primo pod nos, protoze je ve tvaru, jaky je u tebe v databazi, takze vis, ktera presne je spatne. Nemusis parsovat NDR, pokud te nezajima duvod, ktery stejne ruzne servery ne/reportuji kazdy jinak. Navic, pokud puvodni adresa prosla expanzi (jako ten ales@localhost) nemas rozumnou sanci machnout to s tou puvodni v databazi. Samo, ze muzes pouzit ten ciselny klic, ale je to dalsi vrstva abstrakce navic... Cteni tady

to "+" tam má nějaký speciální význam? není mi jasný jak nadefinovat alias když je tam doménový koš a každá adresa je jiná - tedy pro všechny adresy

ma vyznam definovaneho separatoru, vetsinou se pouziva plus, protoze se v "normalnich" adresach prilis nevyskytuje. Vyhoda je v tom, ze Postfix se k te adrese chova trochu jinak, resp. pri vyhledani bere v potaz ne/pritomnost toho detailu (to za plus). V podstate ti jde o to vse dostat na jedno misto a tam si to osetrit -- treba sieve skriptem, kterym se ten detail da matchovat velice jednoduse. Dalsi zpracovani a automatizace zalezi na mnozstvi a naslednych akcich. Mailing listy obecne trackujou pocet vracenych message za nejaky cas a pak vetsinou daneho user bud primo vyhodi nebo mu daji nejaky flag, ktery si pak manualne muze odstranit, teda pokud ma list nejake end-user administracni rozhrani... Cteni tady

[GeorgeWH]

co mas na to serveri v $mydestination?

[xts]

vůbec nemám zadáno - viz odpověď výše

[wd]

A man postconf už jsi konzultoval?

[xts]

ano, to je někdy skoro moje bible před spaním (to nemyslím ironicky) - ale cizí zkušenosti, nebo napsání souvislostí tak jak to třeba udělal Kriegel tady, to je k nezaplacení - velký dík ještě jednou, to v manuálech nenajdeš. Když mě někdo nakopne co vlastně chci tak si to pak už v manuálech a referenčních příručkách dohledám

[wd]

A pokud ti to ještě nefunguje, už jsi zkontroloval, kde všude se v konfiguraci serveru1 vyskytuje název server1.domena.tld nebo jakékoliv odkazy na proměnnou s tímto obsahem? Ono je totiž poněkud neobvyklé, aby server nebral poštu pro svoje fqdn, takže defaultní konfigurace neodpovídá tomu, co ty od toho chceš.

Kromě toho jsem vůbec nepochopil, proč to celé děláš. Přijde mi to zbytečně komplikované. Určitě se dá vymyslet řešení, které bude jednodušší, logičtější a tudíž lépe konfigurovatelné.

[Filip Jirsák]

Problém je, že servery někdy odpovídají přímo tomu stroji co rozesílá, místo aby provedly DNS MX dotaz a poslali to tomu stroji co je v DNS uveden. Předpokládám, že se to děje v rámci pořád navázaného smtp spojení, nebo něco podobného? Server1 se tváří že se o tu doménu stará a ty emaily "přijme", načež hodí hlášku že tam ta lokální schránka neexistuje.

Ty přijímající servery určitě tomu vašemu serveru1 neposílají chybové e-maily, ani v rámci navázaného spojení (v navázaném spojení nelze poslat e-mail opačným směrem). Ty servery pouze vašemu serveru1 odpoví přímo v rámci spojení chybovým kódem (váš server pošle "tady posílám e-mail od X pro Y, e-mail je ABCD" a protější server mu odpoví "tenhle e-mail nepřijmu, důvod je XYZ"). Chybový e-mail z toho udělá až váš server. To, že se takový e-mail pokouší doručit lokálně, je pak chyba konfigurace toho vašeho serveru - zřejmě máte někde nastaveno, že má přijímat poštu pro server1.domena.cz.