2007.03.19.
Az elmúlt 7 nap spam statisztikája



| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Feb | Apr » | |||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
Mindanyian kaptunk már visszapattant levelet, amely azt közölte, hogy a megadott cÃmzett nem létezik. Azonban az is megoldható, hogy a nem létezÅ‘ email cÃmekre érkezÅ‘ levelek egy megadott postafiókba kerüljenek.
Ez meglehetÅ‘sen kellemes opció, ha levelezÅ‘partnetereink rendre elgépelik az email cÃmeinket, mert valakihez még Ãgy is megérkezik a levél. Azonban a spammerek is örülnek ennek, mert Å‘k sok esetben találgatnak, hogy vajon egy adott cégnél milyen email cÃmek lehetnek, és generálnak egy csomó email cÃmet (pl. aa@ceg.hu, bb@ceg.hu, info@ceg.hu, …) remélve, hogy ezekbÅ‘l legalább néhány meg is érkezik valakihez. Egyébként ez az ún. Directory Harvesting Attack (DHA).
Ezért azt javaslom, hogy ne állÃtsatok be ún. wildcard email cÃmeket, mert oda igen sok spam érkezhet. Ez pedig nagyobb erÅ‘forrás igénnyel jár, pl. nagyobb tárolókapacitás, erÅ‘sebb processzor, több memória szükséges, az emberi erÅ‘forrásigényrÅ‘l nem is beszélve, mert valakinek át kell néznie ezeket a leveleket.
Saját tapasztalataim alapján kb. felére csökken a ténylegesen beérkezÅ‘ spam, ha leellenÅ‘rizzük, hogy a megadott cÃmzett valóban létezik, ha pedig nem, akkor eldobjuk a levelet, ill. egy bounce üzenetet küldünk vissza.
Az érvényes email cÃmeket tárolhatjuk pl. LDAP cÃmtárban, SQL adatbázisban vagy akár DB fájlokban is – ez már a konkrétan használt rendszertÅ‘l függ.