Postfix: generování zpráv o nedoručení jen pro určité cílové domény

2. 6. 2020
Doba čtení: 5 minut

Sdílet

 Autor: Depositphotos
Zprávy o nedoručení e-mailu (bounce) jsou známá a na první pohled jednoduchá věc. Často se ale věci zkomplikují třeba při přeposílání pošty. Ukážeme si, jak nastavovat pravidla pro různé domény.

Když pošta nedorazí

Když pošleme e-mail na špatnou adresu, generuje poštovní server, který zjistí, že zpráva je nedoručitelná, zprávu o nedoručitelnosti (NDR report, bounce). To je samozřejmě potřeba proto, aby odesílatel věděl, že musí zprávu poslat znovu. Podle situace se buď generuje zpráva o nedoručení ihned (problém s doručováním je trvalý, bezpečně víme, že cíl neexistuje) a nebo po určité době jako varování a teprve když doručení není možné několik dní, generuje se finální zpráva o nedoručitelnosti a zpráva se zahodí. To v případě, že posíláte poštu do cíle, který vypadá, že existuje, ale není momentálně dostupný.

Postfix ve výchozí konfiguraci negeneruje varování o nedoručitelnosti, ale jen finální hlášení o neúspěšném doručení po pěti dnech. Pokud chcete zapnout i to varování, lze to nastavením parametru delay_warning_time  v souboru main.cf na nenulovou hodnotu.

Bohužel autoři spamu si této funkcionality všimli a začali ji zneužívat. Např. tak, že spam posílají jako zfalšované hlášení o nedoručitelnosti, protože lidé spíše otevřou zprávu, která vypadá jako systémové hlášení. Ale jsou i složitější postupy, kdy schválně posílají zprávy na neexistující adresy, kde jako odesílatele uvedou příjemce spamu a snaží se dosáhnout toho, aby váš mailserver zprávu vrátil, protože tím skryjí svou IP adresu se špatnou reputací a použijí vaši, která je důvěryhodnější. Někteří poskytovatelé e-mailu proti tomu bojují tím, že nezobrazí uživateli hlášení o nedoručení ke zprávě, kterou neodeslal, což zase naopak vede ke zmatkům, pokud jsou zprávy odesílány z více systémů najednou.

Provozovatelé mailserverů se proto snaží nepřipustit, aby přijali zprávu, která vyvolá chybu doručení. Udržují seznamy povolených příjemců, nastavují limit na velikost zprávy tak, aby nejmenší byl na serveru přijímajícím poštu z internetu a uvnitř sítě mají pak limity vyšší. A to všechno jak na primárním mailserveru, tak na všech záložních MX, protože spammer posílá typicky všechno přes MX servery s nízkou prioritou, kde očekává menší zabezpečení. Historicky totiž bývalo pravidlem, že záložní MX servery přijaly jakoukoliv zprávu pro doménu, kde věděli, že jsou MX a spoléhali na to, že až primární mailserver ožije, tak už si vytřídí jakou poštu doručit lze a jakou ne.

Komplikuje se to

Někdy se vám ale stane, že přeposíláte poštu jinam a příjemce má tvrdší nebo minimálně jiná pravidla pro příjem zpráv než máte vy. Takže poštu přijmete ze svého pohledu správně, ale už ji není možné předat dál. V tu chvíli byste měli generovat NDR/bounce a zprávu vrátit. Bohužel v dnešní době jde drtivá většina takových bounce na zfalšovaného odesílatele, takže naopak generujete obtěžující zprávy. Více se o tom dozvíte na Wikipedii.

Jindy není žádoucí zprávu o nedoručení generovat, protože pošta se doručuje lokálně (úspěšně) a současně přeposílá a hlášení o nedoručení je pak jednak matoucí a navíc prozrazuje cíl přesměrování a to také nemusí být každému příjemné.

Postfix bohužel neumí příliš jemně nastavovat politiku, kdy NDR generovat a kdy ne.

První možné řešení je NDR negenerovat vůbec. Ale pak se uživatelé nedozví, že e-mail, který poslali nelze doručit a e-maily začnou potichu mizet, což není příliš hezké řešení. Přesto jej někde potkávám jako rychlé řešení, když se server ocitne na blacklistu.

Řešení, které používám já, je využít více instancí Postfixu a pro každou mít jinou NDR politiku. Konkrétně pošta přeposílaná na GMail často končí jako nedoručitelná, protože GMail mnoho spamů zamítá už v průběhu doručování, především když je přílohou spustitelný soubor nebo obsah vypadá jako phishing.

Ukáži, jak nastavit více instancí Postfixu na Debianu, ale princip je shodný na všech distribucích. Postup je inspirován návodem na Postfix.org.

Více Postfixů na jednom serveru

Zapneme si podporu pro více instancí:

# postmulti -e init

Založíme novou instanci:

# postmulti -I postfix-gmail -e create

Tím nám vznikl adresář /etc/postfix-gmail s novou/čistou konfigurací a /var/spool/postfix-gmail s e-mailovou frontou a chrootem pro novou instanci. Do chrootu musíme doplnit v případě Debianu následující adresáře:

# cp -ax /var/spool/postfix/etc /var/spool/postfix-gmail/
# cp -ax /var/spool/postfix/dev /var/spool/postfix-gmail/
# cp -ax /var/spool/postfix/lib /var/spool/postfix-gmail/
# cp -ax /var/spool/postfix/usr /var/spool/postfix-gmail/

Dále musíme upravit konfigurační soubory nové instance. Tedy nastavujeme v adresáři /etc/postfix-gmail. Konkrétně vmain.cf  zakomentujeme master_service_disable = inet  a pokud posíláme poštu na GMail, zapneme šifrování:

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=verify

V master.cf  pak „přestěhujeme“ smtpd na jiný port:

# =========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# =========================================================================
127.0.0.1:10025      inet  n       -       y       -       -       smtpd

a změníme řádky

bounce    unix  -       -       y       -       0       discard
defer     unix  -       -       y       -       0       discard

Tedy na konci místo bounce dáme direktivu discardTím máme Postfix připravený a můžeme si zkusit, jak nová instance poběží:

# systemctl restart postfix
# postmulti -i postfix-gmail -p start
# postmulti -i postfix-gmail -p stop

Povolíme ji v systemd, aby běžela i po startu:

# systemctl enable postfix@postfix-gmail
# systemctl start postfix@postfix-gmail

Aby nám nová instance Postfixu správně logovala, je potřeba rsyslogu říct, že má číst její zprávy:

# cp /etc/rsyslog.d/postfix.conf /etc/rsyslog.d/postfix-gmail.conf

V /etc/rsyslog.d/postfix-gmail.conf  upravit cestu na:

$AddUnixListenSocket /var/spool/postfix-gmail/dev/log

a restartovat rsyslog:

# systemctl restart rsyslog

Tím máme postfix připravený a poslední krok je předávat poštu k doručení nové instanci. Asi nejsnazší je to nasazením transport_maps (v té základní instanci Postfixu, kterou jsem používali dosud), do main.cf doplníme:

transport_maps = hash:/etc/postfix/transport

Zde uvedeme e-mail příjemce na GMailu (na ukázku example.com) a nový transport jako cestu k němu:

example@example.com smtp:127.0.0.1:10025

Samozřejmě zkompilujeme:

# postmap /etc/postfix/transport

Pomáháme neobtěžováním obětí

Pokud v tomto případě dojde k chybě doručení, nebude už NDR generován. Tím trochu porušujeme normy, ale hodně pomáháme tím, že neobtěžujeme nevinné oběti chybami doručení.

Nová instance loguje s prefixem podle svého jména, takže v mail.log  budou její hlášky v našem případě uvozeny prefixem postfix-gmailPokud se potřebujeme podívat, co leží ve frontě k doručení použijeme příkaz:

# postmulti -i postfix-gmail -x mailq

Pokud potřebujeme poštu z fronty ihned odeslat, voláme:

bitcoin_skoleni

# postmulti -i postfix-gmail -x sendmail -q

Obdobně lze spouštět další příkazy, postmulti připraví prostředí, aby příkazy probíhaly nad naší instancí Postfixu.

Tento princip lze samozřejmě použít pro spousty dalších případů, třeba rozdělení front na ty, které doručují často e-maily s vysokou prioritou (potvrzení o objednávce), a e-maily, které leží ve frontě a pokus o doručení se opakuje méně často (newslettery).

Autor článku

Dan Ohnesorg pracuje jako systémový administrátor, správce sítí a příležitostný programátor v jazycích, pro které se nedá najít nikdo, kdo by je znal.