Fórum Root.cz
Hlavní témata => Server => Téma založeno: Michal Holub 10. 02. 2011, 08:21:57
-
Ahoj,
podařilo se mi zprovoznit postgrey, žádný spam neprojde, problém mám s tím, že občas to chytne i regulérní email (dle dokumentace nesprávná implementace SMTP protokolu na straně odesílatele).
1x denně si nechám vygenerovat postgreyreport zachycenych emailu a zkontroluju to proti uzivatelum v sql. Jenomze takhle to nemuzu delat donekonecna :( poradte mi prosim jak to vylepsit. Diky
-
No moc možností není, já to vidím leda na whitelist.
-
Whitelistuju, to jo...ale stejne...napriklad onemocnim na 14 dni a hned je tam asi 10 emailu (false positive). Takhle to prece nemuze fungovat ne? Tim padem se to asi moc nepouziva v produkcnim nasazeni, nebo mi neco unika?
-
My to používáme ve firmě o 100 lidech, a prý si nikdo nestěžuje, ale jinak souhlas, že to není nejideálnější řešení. Sice jako funguje to, ale občas to zdržení e-mailů je až děsivé.
-
Taky to máme nasazené a bez potíží. Zdržení mailů není problém, protože mail není chat a hlavně si server zapamatuje adresy, které už prošly a pak je pouští okamžitě.
-
Taky to máme nasazené a bez potíží. Zdržení mailů není problém, protože mail není chat a hlavně si server zapamatuje adresy, které už prošly a pak je pouští okamžitě.
A jak jste resili, ze obcas se regulerni email nedostal skrz?
-
BTW: Aky cas pouzivas na grey liste? U mna je to 3 minuty, SPAM sice chodi, ale tak 1/2. Tu jednu polovicu potom s mensou zatazou odstranis dalsimi anti spam toolsami.
Niektori dilinovia maju nastavenych 30 min... Mozno aj dlhsie. Napriklad moj mail server skusa 1. raz hned, potom za 5 min a potom za 30 min. Ak sa nepodari odoslat, uzivatel dostane bounce.
Cize ak by si dakto dal 40 min a grey liste, odo mna nedostane jediny mail.
-
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=60" muzu to zvysit, ale problem to (asi) neresi...Fakt se mam spolehat na to, ze kdyz ten odesilatel (=clovek co tomu nerozumi) dostane "rejected" tak po tom bude patrat a posle to znovu?! A to se tyka i velkym serveru jako treba hotmail.de, email.cz ktere se objevily v postgreyreportu
-
Nechce sa mi citat doku... Tych 60 je minut alebo sekund? Ak minut tak to mas samovrazdu. Ak sekund, tak to je praveze este celkom malo a potom nechapem problem.
EDIT:
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=180 --max-age=30 --auto-whitelist-clients=10"
Takze mas nastavenych 60 sekund, cize tvoj mail server prijme mail uz po 1 minute. Cize kde je problem? To akoze niektore mail servre sa neobtazuju poslat po par (5) minutach mail znova? Sa mi nezda...
-
No prostě asi 3x do týdne najdu v logu zablokovaný email, který by ale měl projít (jde o soukromé klienty)...původně jsem si myslel, že za to může tohle na straně odesílatele
(výňatek z wiki)
On a technical level, some SMTP clients and SMTP servers acting as clients may interpret the temporary rejection as a permanent failure. Old clients conforming only to the obsolete specification (RFC 821) and ignoring its recommendations may give up on delivery after the first failed attempt—RFC 821 states that clients "should" retry messages rather than using the word "must". RFC 2119 dictates that "should" means recommended and to ignore at your own risk, and it is a violation of the current SMTP standard for the client to fail to retry. The current SMTP specification (RFC 5321) clearly states that "the SMTP client retains responsibility for delivery of that message" (section 4.2.5) and "mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender." (section 4.5.4.1).
Jenomže jsou tam i servery jako hotmail.de a email.cz (u kterých bych tohle nečekal). Samozřejmě to whitelistuju...ale celkem mě děsí představa, že se prostě nějaký email nedostane tam kam má.
-
Ahojte,
nedávno som tiež pátral, prečo náš sqlgrey neprepúšťa niektoré správy. Bolo to preto, že druhý pokus o doručenie prišiel síce od toho istého hostname, ale z inej IP-adresy. U mňa išlo konkrétne o moutng.kundenserver.de
dig moutng.kundenserver.de
vráti viacero IP-adries, i čím si sqlgrey bežne poradí, pokial sú tie adresy z jedného /24 subnetu, lenže v tomto prípade sú v hre dva subnety).
V sqlgrey pomohlo jedine zaradenie do whitelistu. Postgrey má možno rovnaký problém.
-
Chcete říct, že po 30 minutách se už s doručením mailu neobtěžujete? To mi připadá jako dost málo, ve firmě, kde dělám správce, se celkem běžně párkrát do roka stává, že jsou několik hodin bez proudu, tudíž i bez mailserveru, který by maily přijal. Většina serverů má interval pro doručení myslím 3 dny.
BTW: Aky cas pouzivas na grey liste? U mna je to 3 minuty, SPAM sice chodi, ale tak 1/2. Tu jednu polovicu potom s mensou zatazou odstranis dalsimi anti spam toolsami.
Niektori dilinovia maju nastavenych 30 min... Mozno aj dlhsie. Napriklad moj mail server skusa 1. raz hned, potom za 5 min a potom za 30 min. Ak sa nepodari odoslat, uzivatel dostane bounce.
Cize ak by si dakto dal 40 min a grey liste, odo mna nedostane jediny mail.
-
A proč dvě podsítě vadí? V nejhorším případě to tedy vypadá tak, že nastane pokus z první podsítě, postgrey ho odmítne. Oni to po pár minutách zkusí z druhé podsítě, postgrey odmítne. Potřetí to projde, protože postgrey už má zaznamenané pokusy z obou podsítí.
Ahojte,
nedávno som tiež pátral, prečo náš sqlgrey neprepúšťa niektoré správy. Bolo to preto, že druhý pokus o doručenie prišiel síce od toho istého hostname, ale z inej IP-adresy. U mňa išlo konkrétne o moutng.kundenserver.de
dig moutng.kundenserver.de
vráti viacero IP-adries, i čím si sqlgrey bežne poradí, pokial sú tie adresy z jedného /24 subnetu, lenže v tomto prípade sú v hre dva subnety).
V sqlgrey pomohlo jedine zaradenie do whitelistu. Postgrey má možno rovnaký problém.
-
Chcete říct, že po 30 minutách se už s doručením mailu neobtěžujete? To mi připadá jako dost málo, ve firmě, kde dělám správce, se celkem běžně párkrát do roka stává, že jsou několik hodin bez proudu, tudíž i bez mailserveru, který by maily přijal. Většina serverů má interval pro doručení myslím 3 dny.
BTW: Aky cas pouzivas na grey liste? U mna je to 3 minuty, SPAM sice chodi, ale tak 1/2. Tu jednu polovicu potom s mensou zatazou odstranis dalsimi anti spam toolsami.
Niektori dilinovia maju nastavenych 30 min... Mozno aj dlhsie. Napriklad moj mail server skusa 1. raz hned, potom za 5 min a potom za 30 min. Ak sa nepodari odoslat, uzivatel dostane bounce.
Cize ak by si dakto dal 40 min a grey liste, odo mna nedostane jediny mail.
Vetsina to tak mit bude, kdyz vidim v postgreyreportu, ze se neco regulerniho bloklo, dam to do whitelistu a za chvili to dojde (i po dni, dvou)
-
Já bych ten dotaz napsal trochu jinak:
Občas se mi stává, že postgrey pozdrží nějaký mail a jeho odesílatel se neobtěžuje ho poslat znovu.
:)
-
Jenomže to je špatně....
Proč by se měl uživatel obtěžovat, on poslal email a ten někdo ho nedostal. Čí je to chyba? Podle mě toho, kdo to měl doručit.
Celé tohle téma jsem chtěl vyřešit jednu věc - jestli jde nějak systémově vyřešit, že to občas zachytí email, který by měl projít.
Jenom dodám, že pokud to řešení nemá, tak je to podle mě špatný systém (postgrey), to je celé.
-
Problem bude pravdepodobne v neopravenej feature Exchange 2003, ktory proste pri pokuse o dorucenie na greylistovany server hodi mail do nejakej blackhole odkial sa ten email dostane len po restarte serveru. M$ o tejto feature vedel ale nikdy ju neopravil. Nie je to chyba greylistoveho systemu, ale serveru opdosielatela. Tam sa neda nic ineho robit ako bud whitelistovat danu adresu, alebo proste povedat dotycnemu odosielatelovi, nech si necha opravit poriadne mailovy server, t.j. upgradnut na verziu ktora touto nedokumentovanou feature netrpi. Ziaden prijemca nie je povinny robit si diery v greylisting systeme len kvoli tomu, ze odosielatel je lenivy a ma deravy mailovy server ktory sa nechova podla RFC SMTP protokolu!
-
Ešte raz upozorňujem, že to, čo hovorím, platí pre sqlgrey a nemusí platiť pre postgrey.
V hre sú
- dve, alebo viac podsietí n1, n2, ...
- a pozor, nie jedna jediná správa, ale v priebehu dhlšieho časového obdobia viacero správ m1, m2, ...
Tu je jeden možný scenár, s ktorým si sqlgrey neporadí:
čas t0:
n1 chce doručiť m1 - sqlgrey si greylistuje dvojicu [n1, m1]
čas t0 + 5min
n2 chce doručiť m1 - sqlgrey si greylistuje dvojicu [n2, m1]
čas t0 + 60min
n2 chce doručiť m1 - sqlgrey prepustí m1 a whitelistuje n2 ako legálneho klienta
a teraz problém:
čas t0 + 30 dní
n1 chce doručiť m2 - sqlgrey blacklistuje n1 ako nelegálneho klienta, pretože sa neunúval znovu poslať m1
A proč dvě podsítě vadí? V nejhorším případě to tedy vypadá tak, že nastane pokus z první podsítě, postgrey ho odmítne. Oni to po pár minutách zkusí z druhé podsítě, postgrey odmítne. Potřetí to projde, protože postgrey už má zaznamenané pokusy z obou podsítí.
Ahojte,
nedávno som tiež pátral, prečo náš sqlgrey neprepúšťa niektoré správy. Bolo to preto, že druhý pokus o doručenie prišiel síce od toho istého hostname, ale z inej IP-adresy. U mňa išlo konkrétne o moutng.kundenserver.de
dig moutng.kundenserver.de
vráti viacero IP-adries, i čím si sqlgrey bežne poradí, pokial sú tie adresy z jedného /24 subnetu, lenže v tomto prípade sú v hre dva subnety).
V sqlgrey pomohlo jedine zaradenie do whitelistu. Postgrey má možno rovnaký problém.
-
Jenomže to je špatně....
Ano, je :)
Proč by se měl uživatel obtěžovat, on poslal email a ten někdo ho nedostal. Čí je to chyba?
Podle mě toho, kdo to měl doručit.
O uživateli nepadlo ani slovo, bavíme se o komunikaci mezi dvěma mailovými servery.
A ano, souhlasím, že je to chyba toho serveru, který to měl doručit - tj. toho, který poslední mail PŘEVZAL - tj. toho, který ho odesílá na tvůj (postrgeyovaný) server. Tvůj server totiž mail NEPŘEVZAL, proto ani nemůže být zodpovědný za jeho doručení.
Tvůj server (B) prostě odesílajícímu serveru (A) řekne "sorry, ale teď DOČASNĚ nejsem schopen zprávu přijmout" - jestliže si to server A vyloží jako "mail doručen" nebo "mail nelze doručit" nebo "mail můžu zahodit", je to očividně jeho chyba, nikoli chyba serveru B. Minimálně proto (což už tu zaznělo), že mailserver může být chvíli mimo provoz, to je něco, s čím prostě A musí počítat.
Jak by se ti líbilo, kdyby pošťačka zazvonila na tvoje dveře, tys neotevíral a ona by usoudila, že balíčky pro tebe může hodit do koše?
Celé tohle téma jsem chtěl vyřešit jednu věc - jestli jde nějak systémově vyřešit, že to občas zachytí email, který by měl projít.
Ale to je právě úplně špatně položené - postgrey nic "nezachytává", tím méně falešně pozitivně (snad až na těch víc IP, co tady zmiňoval kolega). Postgrey prostě jednoduše odesilateli řekne "teď to nepřijmu, zkus to později". Problém pramení z toho, že to odesilatel nepochopí.
Jenom dodám, že pokud to řešení nemá, tak je to podle mě špatný systém (postgrey), to je celé.
No za prvé je otázka, jestli chci svůj server ohýbat tak, aby řešil chyby jiných serverů. A za druhé je otázka, jaké prostředky mám k řešení chyby jiných serverů.
Co třeba kdyby nějaký mailserver nezačínal komunikaci HELO/EHLO, ale třeba ZDAR, TADY VENCA? Je můj server špatný, když s ním nebude komunikovat?
-
sqlgrey blacklistuje n1 ako nelegálneho klienta, pretože sa neunúval znovu poslať m1
A není problém především tady? Přiznám se, že doteď jsem netušil, že nějaký greylisting nástroj dělá blacklisting z tohodle důvodu... A pokud ho dělá, není na místě zvážit vypnutí téhle feature? (samotný greylisting by IMHO měl úplně vklidu stačit, notoričtí spammeři by měli být nacházení jinak - nějakým "oficiálním" blacklistem)