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.
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.
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 ;)
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...
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.
* 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?
- 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.
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.