Vlákno názorů k článku Stavíme vlastní e-mailový server: základní nastavení systému od František Havel - Držím palce, uvidíme jestli tohle překoná Lukáše Jelínka...
-
BoBLO (neregistrovaný)
Ja by som este pridal do Vasej ctenej pozornosti "Anti Spam SMTP Proxy" (ASSP).
Vid
https://sourceforge.net/projects/assp/
https://sourceforge.net/p/assp/wiki/Main_Page/Viac ako desat rokov sme ho s velkym uspechom pouzivali vo firme, nez dosli novi managori a presadili "komercne" riesenie.
Velkou vyhodou ASSP je, ze okrem toho, ze pokryva viacero bezpecnostnych vrstiev v postovej prevadzke (i v clanku spominanych), umoznuje a sprostredkuje dalsie sluzby v oblasti transportu, uzivatelov, notifikacii a pod.
Kedze pocet nastavitelnych parametrov je niekolko sto, vyhodou je prehladne administratorske rozhranie cez web.
-
tewy (neregistrovaný)
Kdepak, graylisting veci zbytecne komplikuje - casto se stava, ze je potreba email dorucit rychle a z jine adresy... lepsi je nasazeni Nolistingu - https://www.computer.org/csdl/proceedings/dsn/2016/8891/00/8891a562-abs.html
-
j (neregistrovaný)
"je potreba email dorucit rychle "
Tohle ti nezaruci naprosto zadny opatreni a je uplne jedno jestli pouzivas nebo nepouzivas greylist.Pokud nekdo potrebuje neco dorucit rychle, a snazi se o to emailem, tak pouziva naprosto spatnej nastroj. Email funguje totiz exaktne stejne jako posta - hodis neco do shranky a mozna, nekdy (nekomu) neco dojde.
-
tewy (neregistrovaný)
Pozor, ja nikde netvrdim, ze je email nejakou sluzbou s garatnovanym doprucenim a navic v garantovanem case. (Naopak uz jsem za ty roky co se tim zabyvam zazil leccos). To je jen casty priklad z praxe, kdy se nestihaji terminy, dotycny to podesila ze sveho napr. soukromeho emailu, pac je na cestach.... a pak se divi, ze to neprichazi a zrovna ted kdyz se specha.
-
Dle RFC 5321 by MĚL BÝT čas mezi pokusy alespoň 30 minut, ale téměř nikdo to nedodržuje.
Konkrétně postfix se v tomto řídí několika volbami:
queue_run_delay - default je 300s, znamená to, jak často se snaží znovu projet deferred queue - frontu odmítnutých zpráv
minimal_backoff_time - default opět 300s - po jaké době nejdříve zkusit další doručení. Tato doba se z každým pokusem pro konkrétní mail zdvojnásobuje až do horní hranice, což je další volba
maximal_backoff_time - default 4000s - maximální čas čekání mezi dvěma pokusy
maximal_queue_lifetam - default 5d, maximální čas, po který se snaží doručit mail, poté je zahozen jako nedoručitelný
delay_warning_time - default 0 (vypnuto) - po jak dlouhé době se odesílateli oznámí, že mail čeká ve frontě a zatím nebyl doručen.Ve výchozím nastavení to tedy znamená, že druhý pokus je někde mezi 300 a 599 vteřinami a pokud problém trvá, odesílatel se to dozví po 5ti dnech!
Třeba Postgrey má výchozí čas pro druhé doručení tuším 300 vteřin, což je kouzelné, protože jestli se nepletu, třeba MS Exchange má default retry po jedné minutě.
Větší servery mívají retry i několik hodin, protože jejich deferred queue bývá dlouhá jak pohádka...
a teď si vyberte... řídit se RFC, neřídet se RFC, čekat hodiny na maily... nedává to smysl. Navíc, jak jsem psal, servery spammerů bývají často nastaveny líp, jak ty nespamovací, aby měly vůbec šanci něco doručit. Graylisting toho opravdu víc rozbije, než zachrání.
