pouzivam greylisting nad qmailom, GL data su ulozene v sql. Na server mi pred greylistingom chodilo cca 3000 spamov denne, po nasadeni GL ich pride maximalne 5 a o tie sa postara SA. O com ale chcem pisat je vyvratit mylne myslienky a dohady o GL, ktore tu boli popisane:
1. Vacsina mailserver fariem pouziva ipcky z jedneho /24 subnetu. Nebavime sa o worldwide freemailoch, ktore manualne nahodit do databazy je otazka 10 minut. Cize uplne staci, ked
sa pri prijimani mailu zaznamena adresa vo forme x.y.z.% (a cela adresa pre pripad potreby) a ta sa potom pouziva pri matchovani dalsich mailov.
2. podla rfc2821: "The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes". Cize, kto nedodrzuje RFC, ma problem on nie ja. Preto ak sa z rovnakeho subnetu pokusi niekto dorucit mail skor ako po 30 minutach, jedna sa o spammera. Ak je to regularny MTA, tak raz ten mail doruci po pozadovanej odmlke. Konkretne u mna sa o to stara zaznam v stlpci block_expires a pri zapisovani do databazy je NOW()+30minut.
GL funguje, funguje skvele a nezaujima ma co bude ked sa spameri naucia posielat maily RFC compilant... to budem riesit az to nastane a nie potom si vycitat, ze kym sa este dalo efektivne bojovat proti spamu, tak som sa radsej babral a stracal cas s inymi metodami.
"In general, the retry interval SHOULD be at least 30 minutes" [...]
Preto ak sa z rovnakeho subnetu pokusi niekto dorucit mail skor ako po 30 minutach, jedna sa o spammera.
No pozor, SHOULD != MUST. Odosielatelia necakajuci 30 minut vyhovuju RFC. Dokonca by som povedal, ze najlepsie riesenie pre server je vybrat nahodne uniformne cakanie z intervalu (0, 30] minut kym akceptuje mail. V priemernom pripade bude cakanie 15 minut (v najhorsom 30). Alebo vybrat take rozdelenie, ze maximalna hranica bude neobmedzena (nekonecno), ale pravdepodobnost, ze si server take cakanie vyberie, bude klesat inverzne exponencialne (napr. normalne rozdelenie s maximom v 15 minut a rozumne "natiahnute" do stran).
Uz sa mi parkrat stalo, ze som sa potreboval poslat rychlo mail (odchod do zony bez netu ;-)) a bol som zagreylistovany. Pockat trebars 10 minut sa este da, ale tych 30 minut moze byt problem.
netvrdim ze greylisting nema ziadne nevyhody... a zdrzanie legalnych mailov je jediny, ktory cloveka moze naozaj nastvat. Mozem povedat, ze prve 3 mesiace som vzdy prepadol panike, ze mi nefunguje mta, ked som si odniekial poslal mail, resp. niekto poslal mne a nedorazil mi za par okamihov. Dnes som s tym uz zmiereny :)
SHOULD = MAL BY... cize ak posle skor, je to na jeho riziko, ze si tym uskodi. Ak mam pravdu povedat, tak ani samotny qmail od DJB nedodrziava 30 minut od prveho dorucenia (1. okamzite, druhe po cca 6 min., tretie po cca 26 min. a az stvrte je po hodine).
Cim vyssia doba (onych 30 minut), tym je system efektivnejsi pri boji proti spamu... pretoze az po tej dobe sa sprava od daneho odosielatela z nejakej ip pre dotycneho prijimatela povazuje za nespam. A ked niekto zaflooduje milion mailov, je otazkou par desiatok minut, kym sa ip adresa objavi na nejakom znamom blackliste. Dovtedy treba drzat hradzu pred pripadnym pokusom o opakovany flood :)
Na koniec este - pravdepodobnost, ze ti niekto prvy mail posle s urgenciou je dost nizka... cize ak si uz s niekym komunikoval, spravy od neho ti dorazia okamzite.
Na koniec este - pravdepodobnost, ze ti niekto prvy mail posle s urgenciou je dost nizka... cize ak si uz s niekym komunikoval, spravy od neho ti dorazia okamzite.
Jj, v spominanom pripade to vyzeralo, ze greylisting bol cerstvo zavedeny na MTA, takze este nebol "natrenovany" na "znamych ludi".
neviem ci niekde je zoznam, ale staci si dat: "SELECT relay_ip FROM relaytofrom where mail_from LIKE "%gmail.com" GROUP BY relay_ip" na databazu po par dnoch a pozriet reverz. Konkretne gmail ma format "countrycode"-out-####.google.com
A potom to tam nahadzat s hodnotou MANUAL v stlpci origin_type (aby sa to pri cisteni nezmazalo)
host -t MX gmail.com
gmail.com mail is handled by 50 gsmtp163.google.com.
gmail.com mail is handled by 50 gsmtp183.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 10 alt2.gmail-smtp-in.l.google.com.
Mam pocit, ze gmail schvalne pravidelne meni DNS MX zaznamy (a aj odosielacie uzly), natvrdo zadratovat povolenie gmailu bude tazke. Zda sa mi, ze je to ochrana proti automatickym skriptom, ktore maju natvrdo zadratovane IP/hostname.
