Spam és vírusszűrési tapasztalatok a PPKE-ITK -n II.
Csillag Tamás
<cstamas@digitus.itk.ppke.hu>
http://digitus.itk.ppke.hu/~cstamas
Jelen dokumentum a Creative Commons license by-sa alatt érhetõ el.
Előadás áttekintése
- Email netikett
- Anti spam módszerek okozta hátrányok
- avagy a spam ellen mindent szabad?
- ... és néhány workaround
- vagy barátságosabb módszerek?
- Az újabbak közül
- SPF - inkább ne!
- DomainKeys, avagy DKIM - de hogyan?
Spam szűrés
Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel (RFC 793)
Some parts of RFC 821 are simply too absurd to tolerate. -- D.J. Bernstein
I'm not interested in security through obscurity. I want real security mechanisms, solutions that work for _everybody_. Yes, that's a lot more difficult than randomly blowing away "suspicious" portions of the Internet mail infrastructure, but it's the Right Thing To Do. -- D.J. Bernstein
Email netikett
- Ne generáljunk bounce-ot!
- Helyette before-queue utasítsuk el a levelet!
... azaz még az SMTP kapcsolat ideje alatt! - Leggyakrabban a bounce hamisított címre menne.
- Kezeljük a bounce-okat!
- pl. listák üzemeltetésénél
... használjunk VERP-et
és kapcsoljuk ki a "hibás" email címeket! - Mailman opció
Greylisting - hátrányok
- greylist röviden..
- delayed mail
- hagyományos greylist esetében minden levélnél újraküldés
- default - Postfix esetében (2.4 előtt)
- queue_run_delay = 1000s
minimal_backoff_time = 1000s
maximal_backoff_time = 4000s
default_destination_concurrency_limit = 20 - Ha greylisting sender verification -nel találkozik...
Greylisting - workaround
- queue_run_delay = 300s (new default, BTW)
minimal_backoff_time = 300s (new default, BTW)
- Külön transport a greylisting -hez (buggyisp)
buggyisp_destination_recipient_limit = 10 (recipient korlát is) buggyisp_destination_concurrency_limit = 200
Greylisting - nálunk
- /24 -es block -ot egyként kezel
- Nagy szolgáltatók
- Google, Yahoo, Hotmail...
- Automatikus whitelist
- 10 levél után "szabad" az út
- 30 nap után újra greylisting 1 (!) levélre
Általános módszerek
- DNS feloldás
- helo check
- RBL
- Fontos a körültekintő kiválasztás
- Több listával kapcsolatban rossz a tapasztalat
- Pl. néha egy-egy internet szolgáltató is felkerül
- Amelyek jól működnek
- cbl.abuseat.org
- dnsbl.njabl.org
- zen.spamhaus.org
SPF, CallerID
"SPF is harmful. Adopt it" -- Jonathan de Boyne Pollard
- Elvileg egy spam ellenes megoldás
De úgy tűnik egy levelezés ellenes megoldás - Cél: küldő domain neve alapján lehessen whitelistet használni
- De ma már nem erre használják!!
- SRS nélkül (és több jelentős változtatás nélkül):
- Forwarding breaks, alias breaks, bounce breaks
- Spam nem csökken
- Spammereknek van a legjobban elkészített SPF recordja ;-)
- Az SRS sokszor egyébként se működne, mert túllépné a 64 karakteres limit-et
DomainKeys, DKIM
- Hasonló célok
- Jobban illeszkedik a jelenlegi rendszerbe
- Nyilvános - magánkulcs alapú titkosítás
- DNS-ben publikáljuk a nyilvános kulcsot
- Fingerprintet készít a levelezőszerver ezzel hitelesítve a levelet
- Az aláírás az eddigi headereket hitelesíti
- Mindennapi használatban sem okoz váratlan meglepetéseket
- Levelezőlista szerverekre külön figyelmet kell szentelni
- Csak pozitív szűrésre!
