Pokud vam chodi potvrzeni objednavek az po 4 hodinach, zkuste si stezovat u provozovatele toho obchodu... velmi pravdepodobne bude problem napriklad s prilis dlouhou frontou zprav na strane odesilatele. Standardni prodleva pred prijetim zpravy byva 5 minut, to, ze to druhy server zkusi az po 4 hodinach opravdu nemuzete klast za vinu nasazeni greylistu. Pozorovanim vyslo najevo, ze standardni prodleva je 20 minut, ale vzhledem k tomu, ze pres nase servery tech mailu chodi trochu vic, stejne uz je vetsina znamych odesilatelu ve whitelistech, takze jsou prijimany automaticky...
Pokud vim, s greylistingem ma problemy i Ceska Sporitelna. Primo v Arachne Labs jsme na to nenarazili, nicmene kolega ze spriznene firmy si na to stezoval... pri pohledu na stranky rfc-ignorant.org, konkretne na http://rfc-ignorant.org/tools/lookup.php?domain=csas.cz se asi nelze divit...
V pripade, ze by nahodou tento prispevek cetl nekdo ze zminene instituce, zkuste, prosim, nejak zjednat napravu ;)
Díky za odkaz, ale ve skutečnosti ten graylisting nasadil kolega pověřený administrací serveru... já ani nevím, kde přesně v /etc/postfix/.. se to zapíná, a pouze se snažím nějak monitorovat jestli a jak moc to pomohlo...
A popravdě - pomohlo to fakt hodně. Sebelepší antivirová a antispamová kontrola je nanic, pokuď server pod náporem spamu přestane stíhat tuhle kontrolu provádět.
- zpozdeni doruceni by se melo snad dat eliminovat, pokud bude greylisting na vsech MX pro danou domenu a to se _sdilenou_ databazi trojic. Pokud se nepletu dorucujici server by mel hned jakmile mu primar rekne 4XX, zkusit dalsi MX s nizsi prioritou - a ten by v te chvili jiz mel v databazi potrebne udaje pro, aby mohl zpravu akceptovat. Problem je jak vyresit rychlou a spolehlivou synchronizaci DB v pripade, kdy zalozni MX je umisten nekde za horama.
- osobni zkusenost s chovanim GMailu nemam, ale podle zprav na netu to vypada, ze opakovane pokusy k odeslani zpravy provadi z jinych IP. Pak greylisting zpusobi, ze zpravy z GMailu nedojdou :-( Mozna by to pomohla resit synchronizovana DB na vsech MX (prostridat vsechny MX v ramci jednoho pokusu o doruceni by snad mel stale jeden a tyz stroj GMailu). Pripadne nasadit greylisting jen na zaloznim MX - ale toto reseni je z hlediska eliminace spamu podle mne malo ucinne (ne vsechny spamy jdou prez zalozni MX)
- problem s freemailery, ktere se nechovaji podle RFC - odesilaji informaci o nedoruceni odesilateli jiz po prvnim pokusu o doruceni ci dokonce neopakuji doruceni - je problem ale resit by ho mely ty freemailery.
* velmi, velmi tazko sa zakaznikovi vysvetluje, preco mu neprisiel mail od velmi doleziteho zakaznika s oneskorenim niekolko hodin,
* preco mu neprisiel mail od este dolezitejsieho zakaznika pripadne manzelky vobec (ono non-RFC mail serverov a kokotov adminov je prekvapivo velmi vela)
mimochodom, neexistuje niekde zoznam mail serverov velkych freemailov ako napr. gmail?
Ta fronta je na serveru odesilatele, takze tezko.
Obcas si to clovek muze postrcit telnetem na port 25 a pouzitim prikazu ETRN, ale neni to uplne stoprocentni.
No, kdyz mi prijde potvrzeni objednavky z internetoveho obchodu az po 4 hodinach, tak mi to moc klidu neprida. Stejne tak ruzne registrace, ktere potrebuji ihned. Podle me by uzivatel mel mit pravo nahlednout do fronty a vybrat si rucne, co chce dorucit ihned.
Občas mě to první zpoždění sice také zmate, ale 4-6 spamů za den namísto dřívějších 100-150 za to rozhodně stojí. A jak říká Michal - mail není ICQ, byť to mnoho lidí ne a ne pochopit.