SpamTechniken zur Abwehr

Dirk Geschke

Linux User Group Erding

23. April 2008

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 1 / 28

Gliederung

1 Methoden der Spambekämpfung

2 Theoretische Verfahren

3 Abschluß

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 2 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Vermeidung von Spam

Mailserver nicht als open relay betreiben, gleiches gilt für openproxies wie z.B. SquidVorsicht bei mailversendenden CGI–Scripten (formmail)Umgang mit Mailadressen

I keine E-Mail Adressen auf WebseitenI lange Namen, 1-2 Buchstaben werden schnell geratenI Vorsicht bei: Gewinnspielen, Newslettern, Gratisproben,

AustragunglinksI keine vacation E-Mails.I Geheimhalten der Adresse, häufiger Adreßwechsel und

Wegwerfadressen (unpraktisch)I Zusatzinformationen in der Adresse: auf Displaynamen achten!I Zusatzinformationen in mailto–Links (Subject)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 3 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Angreifpunkte bei Spam

im Server beim Versand (MSA): egress–Filterung (ISPs)im Server vor der Annahme der E-Mail

I IP-Filter vor ConnectI vor HELO/EHLOI nach HELO/EHLOI nach MAIL FROMI nach RCPT TOI nach DATA und CRLF . CRLF

im Server nach Annahmeim Client vor Abholungim Client nach Abholung

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 4 / 28

Nach Spamanalyse

zustellen, spamverdächtige E-Mails markieren oder separatenFolderabweisen, ressourcensparendlöschen: niemand merkt das, Fehler nicht erkennbar,Rekonstruktion der E-Mail nicht möglich −→ nicht machbar!markieren, entweder unsichtbar im Header oder sichtbar imSubjectunter Quarantäne stellenAusnahmen: Postmaster (zwecks Beschwerden!)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 5 / 28

Nach Spamanalyse

zustellen, spamverdächtige E-Mails markieren oder separatenFolderabweisen, ressourcensparendlöschen: niemand merkt das, Fehler nicht erkennbar,Rekonstruktion der E-Mail nicht möglich −→ nicht machbar!markieren, entweder unsichtbar im Header oder sichtbar imSubjectunter Quarantäne stellenAusnahmen: Postmaster (zwecks Beschwerden!)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 5 / 28

Nach Spamanalyse

zustellen, spamverdächtige E-Mails markieren oder separatenFolderabweisen, ressourcensparendlöschen: niemand merkt das, Fehler nicht erkennbar,Rekonstruktion der E-Mail nicht möglich −→ nicht machbar!markieren, entweder unsichtbar im Header oder sichtbar imSubjectunter Quarantäne stellenAusnahmen: Postmaster (zwecks Beschwerden!)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 5 / 28

Nach Spamanalyse

zustellen, spamverdächtige E-Mails markieren oder separatenFolderabweisen, ressourcensparendlöschen: niemand merkt das, Fehler nicht erkennbar,Rekonstruktion der E-Mail nicht möglich −→ nicht machbar!markieren, entweder unsichtbar im Header oder sichtbar imSubjectunter Quarantäne stellenAusnahmen: Postmaster (zwecks Beschwerden!)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 5 / 28

Nach Spamanalyse

zustellen, spamverdächtige E-Mails markieren oder separatenFolderabweisen, ressourcensparendlöschen: niemand merkt das, Fehler nicht erkennbar,Rekonstruktion der E-Mail nicht möglich −→ nicht machbar!markieren, entweder unsichtbar im Header oder sichtbar imSubjectunter Quarantäne stellenAusnahmen: Postmaster (zwecks Beschwerden!)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 5 / 28

Nach Spamanalyse

zustellen, spamverdächtige E-Mails markieren oder separatenFolderabweisen, ressourcensparendlöschen: niemand merkt das, Fehler nicht erkennbar,Rekonstruktion der E-Mail nicht möglich −→ nicht machbar!markieren, entweder unsichtbar im Header oder sichtbar imSubjectunter Quarantäne stellenAusnahmen: Postmaster (zwecks Beschwerden!)

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 5 / 28

Filterung durch Personen

sehr effektives Verfahren, gewöhnlich wird Spam auf den erstenBlick erkanntwird von manchen Mailinglisten verwendet: moderated Listim Unternehmenseinsatz an zentraler Stelle aufgrund vonDatenschutzbestimmungen nicht möglichFilterung im Mailclienterkannter Spam kann zum Trainieren anderer Filter verwendetwerden, siehe Bayes–Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 6 / 28

Filterung durch Personen

sehr effektives Verfahren, gewöhnlich wird Spam auf den erstenBlick erkanntwird von manchen Mailinglisten verwendet: moderated Listim Unternehmenseinsatz an zentraler Stelle aufgrund vonDatenschutzbestimmungen nicht möglichFilterung im Mailclienterkannter Spam kann zum Trainieren anderer Filter verwendetwerden, siehe Bayes–Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 6 / 28

Filterung durch Personen

sehr effektives Verfahren, gewöhnlich wird Spam auf den erstenBlick erkanntwird von manchen Mailinglisten verwendet: moderated Listim Unternehmenseinsatz an zentraler Stelle aufgrund vonDatenschutzbestimmungen nicht möglichFilterung im Mailclienterkannter Spam kann zum Trainieren anderer Filter verwendetwerden, siehe Bayes–Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 6 / 28

Filterung durch Personen

sehr effektives Verfahren, gewöhnlich wird Spam auf den erstenBlick erkanntwird von manchen Mailinglisten verwendet: moderated Listim Unternehmenseinsatz an zentraler Stelle aufgrund vonDatenschutzbestimmungen nicht möglichFilterung im Mailclienterkannter Spam kann zum Trainieren anderer Filter verwendetwerden, siehe Bayes–Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 6 / 28

Filterung durch Personen

sehr effektives Verfahren, gewöhnlich wird Spam auf den erstenBlick erkanntwird von manchen Mailinglisten verwendet: moderated Listim Unternehmenseinsatz an zentraler Stelle aufgrund vonDatenschutzbestimmungen nicht möglichFilterung im Mailclienterkannter Spam kann zum Trainieren anderer Filter verwendetwerden, siehe Bayes–Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 6 / 28

Einhalten des Protokolls, Timeouts

Prüfung des HELO-Strings: Ist der Hostname korrekt? Weist erauf eine gültige Adresse hin?Test auf PTR–Eintrag: Existiert er und verweist dieser auf diegleiche IP-Adresse (reverse and forward lookup)Einhaltung der Sequenzen: Sendet der Client vor der Antwort desServers? Vorsicht bei PIPELINING.Tests auf Korrektheit z.B. der Adressen, Vorsicht: es existierennicht-RFC-konforme Mailserver.Verlangsamung, Ausnutzung von Timeouts: Spammer haben eseilig, sie wollen viele E-Mails durchschleusen. Eine bewußteVerlangsamung kann daher helfen.Spammer dürften bei Verbreitung des Verfahrens schnell daraufreagieren, fehlerhafte Mailclients leider nicht.

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 7 / 28

Einhalten des Protokolls, Timeouts

Prüfung des HELO-Strings: Ist der Hostname korrekt? Weist erauf eine gültige Adresse hin?Test auf PTR–Eintrag: Existiert er und verweist dieser auf diegleiche IP-Adresse (reverse and forward lookup)Einhaltung der Sequenzen: Sendet der Client vor der Antwort desServers? Vorsicht bei PIPELINING.Tests auf Korrektheit z.B. der Adressen, Vorsicht: es existierennicht-RFC-konforme Mailserver.Verlangsamung, Ausnutzung von Timeouts: Spammer haben eseilig, sie wollen viele E-Mails durchschleusen. Eine bewußteVerlangsamung kann daher helfen.Spammer dürften bei Verbreitung des Verfahrens schnell daraufreagieren, fehlerhafte Mailclients leider nicht.

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 7 / 28

Einhalten des Protokolls, Timeouts

Prüfung des HELO-Strings: Ist der Hostname korrekt? Weist erauf eine gültige Adresse hin?Test auf PTR–Eintrag: Existiert er und verweist dieser auf diegleiche IP-Adresse (reverse and forward lookup)Einhaltung der Sequenzen: Sendet der Client vor der Antwort desServers? Vorsicht bei PIPELINING.Tests auf Korrektheit z.B. der Adressen, Vorsicht: es existierennicht-RFC-konforme Mailserver.Verlangsamung, Ausnutzung von Timeouts: Spammer haben eseilig, sie wollen viele E-Mails durchschleusen. Eine bewußteVerlangsamung kann daher helfen.Spammer dürften bei Verbreitung des Verfahrens schnell daraufreagieren, fehlerhafte Mailclients leider nicht.

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 7 / 28

Einhalten des Protokolls, Timeouts

Prüfung des HELO-Strings: Ist der Hostname korrekt? Weist erauf eine gültige Adresse hin?Test auf PTR–Eintrag: Existiert er und verweist dieser auf diegleiche IP-Adresse (reverse and forward lookup)Einhaltung der Sequenzen: Sendet der Client vor der Antwort desServers? Vorsicht bei PIPELINING.Tests auf Korrektheit z.B. der Adressen, Vorsicht: es existierennicht-RFC-konforme Mailserver.Verlangsamung, Ausnutzung von Timeouts: Spammer haben eseilig, sie wollen viele E-Mails durchschleusen. Eine bewußteVerlangsamung kann daher helfen.Spammer dürften bei Verbreitung des Verfahrens schnell daraufreagieren, fehlerhafte Mailclients leider nicht.

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 7 / 28

Einhalten des Protokolls, Timeouts

Prüfung des HELO-Strings: Ist der Hostname korrekt? Weist erauf eine gültige Adresse hin?Test auf PTR–Eintrag: Existiert er und verweist dieser auf diegleiche IP-Adresse (reverse and forward lookup)Einhaltung der Sequenzen: Sendet der Client vor der Antwort desServers? Vorsicht bei PIPELINING.Tests auf Korrektheit z.B. der Adressen, Vorsicht: es existierennicht-RFC-konforme Mailserver.Verlangsamung, Ausnutzung von Timeouts: Spammer haben eseilig, sie wollen viele E-Mails durchschleusen. Eine bewußteVerlangsamung kann daher helfen.Spammer dürften bei Verbreitung des Verfahrens schnell daraufreagieren, fehlerhafte Mailclients leider nicht.

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 7 / 28

Einhalten des Protokolls, Timeouts

Prüfung des HELO-Strings: Ist der Hostname korrekt? Weist erauf eine gültige Adresse hin?Test auf PTR–Eintrag: Existiert er und verweist dieser auf diegleiche IP-Adresse (reverse and forward lookup)Einhaltung der Sequenzen: Sendet der Client vor der Antwort desServers? Vorsicht bei PIPELINING.Tests auf Korrektheit z.B. der Adressen, Vorsicht: es existierennicht-RFC-konforme Mailserver.Verlangsamung, Ausnutzung von Timeouts: Spammer haben eseilig, sie wollen viele E-Mails durchschleusen. Eine bewußteVerlangsamung kann daher helfen.Spammer dürften bei Verbreitung des Verfahrens schnell daraufreagieren, fehlerhafte Mailclients leider nicht.

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 7 / 28

Sender Policy Framework, SenderID

Verifikation des Absenders anhand von DNS–EinträgenEinschränkung des Kreises von sendeberechtigten Servernnur der Versender kann Einträge vornehmen: Spamvermeidungbei anderen und nicht bei einem selberSpammer können sich auch SPF-Einträge generierenRelaying über andere Server nur bedingt möglichErfolg begrenzt, Einsatz eher nicht ratsam

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 8 / 28

Sender Policy Framework, SenderID

Verifikation des Absenders anhand von DNS–EinträgenEinschränkung des Kreises von sendeberechtigten Servernnur der Versender kann Einträge vornehmen: Spamvermeidungbei anderen und nicht bei einem selberSpammer können sich auch SPF-Einträge generierenRelaying über andere Server nur bedingt möglichErfolg begrenzt, Einsatz eher nicht ratsam

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 8 / 28

Sender Policy Framework, SenderID

Verifikation des Absenders anhand von DNS–EinträgenEinschränkung des Kreises von sendeberechtigten Servernnur der Versender kann Einträge vornehmen: Spamvermeidungbei anderen und nicht bei einem selberSpammer können sich auch SPF-Einträge generierenRelaying über andere Server nur bedingt möglichErfolg begrenzt, Einsatz eher nicht ratsam

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 8 / 28

Sender Policy Framework, SenderID

Verifikation des Absenders anhand von DNS–EinträgenEinschränkung des Kreises von sendeberechtigten Servernnur der Versender kann Einträge vornehmen: Spamvermeidungbei anderen und nicht bei einem selberSpammer können sich auch SPF-Einträge generierenRelaying über andere Server nur bedingt möglichErfolg begrenzt, Einsatz eher nicht ratsam

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 8 / 28

Sender Policy Framework, SenderID

Verifikation des Absenders anhand von DNS–EinträgenEinschränkung des Kreises von sendeberechtigten Servernnur der Versender kann Einträge vornehmen: Spamvermeidungbei anderen und nicht bei einem selberSpammer können sich auch SPF-Einträge generierenRelaying über andere Server nur bedingt möglichErfolg begrenzt, Einsatz eher nicht ratsam

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 8 / 28

Sender Policy Framework, SenderID

Verifikation des Absenders anhand von DNS–EinträgenEinschränkung des Kreises von sendeberechtigten Servernnur der Versender kann Einträge vornehmen: Spamvermeidungbei anderen und nicht bei einem selberSpammer können sich auch SPF-Einträge generierenRelaying über andere Server nur bedingt möglichErfolg begrenzt, Einsatz eher nicht ratsam

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 8 / 28

S/MIME, PGP, STARTTLS

Aufwand für Verschlüsselung recht hochExistenz von Signaturen nicht ausreichend, Spammer könneneinmal signieren und mehrfach versendenSTARTTLS hilfreich: Hohe CPU-Last durch Verschlüsselungreduziert Durchsatz bei SpammernAllerdings hilft das nicht viel gegen Bot–Netze, die sind in derRegel leistungsstarkAls Kriterium eher sekundär geeignet, z.B. in Verbindung mitheuristischer Statistik

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 9 / 28

S/MIME, PGP, STARTTLS

Aufwand für Verschlüsselung recht hochExistenz von Signaturen nicht ausreichend, Spammer könneneinmal signieren und mehrfach versendenSTARTTLS hilfreich: Hohe CPU-Last durch Verschlüsselungreduziert Durchsatz bei SpammernAllerdings hilft das nicht viel gegen Bot–Netze, die sind in derRegel leistungsstarkAls Kriterium eher sekundär geeignet, z.B. in Verbindung mitheuristischer Statistik

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 9 / 28

S/MIME, PGP, STARTTLS

Aufwand für Verschlüsselung recht hochExistenz von Signaturen nicht ausreichend, Spammer könneneinmal signieren und mehrfach versendenSTARTTLS hilfreich: Hohe CPU-Last durch Verschlüsselungreduziert Durchsatz bei SpammernAllerdings hilft das nicht viel gegen Bot–Netze, die sind in derRegel leistungsstarkAls Kriterium eher sekundär geeignet, z.B. in Verbindung mitheuristischer Statistik

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 9 / 28

S/MIME, PGP, STARTTLS

Aufwand für Verschlüsselung recht hochExistenz von Signaturen nicht ausreichend, Spammer könneneinmal signieren und mehrfach versendenSTARTTLS hilfreich: Hohe CPU-Last durch Verschlüsselungreduziert Durchsatz bei SpammernAllerdings hilft das nicht viel gegen Bot–Netze, die sind in derRegel leistungsstarkAls Kriterium eher sekundär geeignet, z.B. in Verbindung mitheuristischer Statistik

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 9 / 28

S/MIME, PGP, STARTTLS

Aufwand für Verschlüsselung recht hochExistenz von Signaturen nicht ausreichend, Spammer könneneinmal signieren und mehrfach versendenSTARTTLS hilfreich: Hohe CPU-Last durch Verschlüsselungreduziert Durchsatz bei SpammernAllerdings hilft das nicht viel gegen Bot–Netze, die sind in derRegel leistungsstarkAls Kriterium eher sekundär geeignet, z.B. in Verbindung mitheuristischer Statistik

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 9 / 28

Right Hand Side Blacklists RHSBL

Blockierung aufgrund des Domainnamens des AbsendersAbsender leicht fälschbar −→ schlecht für Blacklistssinnvoll nur bei bekannten Spam-Domains.hilfreich bei Whitelists, Anwendung muß gut durchdacht seinwenig hilfreich, höchstens in Verbindung mit DKIM

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 10 / 28

Right Hand Side Blacklists RHSBL

Blockierung aufgrund des Domainnamens des AbsendersAbsender leicht fälschbar −→ schlecht für Blacklistssinnvoll nur bei bekannten Spam-Domains.hilfreich bei Whitelists, Anwendung muß gut durchdacht seinwenig hilfreich, höchstens in Verbindung mit DKIM

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 10 / 28

Right Hand Side Blacklists RHSBL

Blockierung aufgrund des Domainnamens des AbsendersAbsender leicht fälschbar −→ schlecht für Blacklistssinnvoll nur bei bekannten Spam-Domains.hilfreich bei Whitelists, Anwendung muß gut durchdacht seinwenig hilfreich, höchstens in Verbindung mit DKIM

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 10 / 28

Right Hand Side Blacklists RHSBL

Blockierung aufgrund des Domainnamens des AbsendersAbsender leicht fälschbar −→ schlecht für Blacklistssinnvoll nur bei bekannten Spam-Domains.hilfreich bei Whitelists, Anwendung muß gut durchdacht seinwenig hilfreich, höchstens in Verbindung mit DKIM

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 10 / 28

Right Hand Side Blacklists RHSBL

Blockierung aufgrund des Domainnamens des AbsendersAbsender leicht fälschbar −→ schlecht für Blacklistssinnvoll nur bei bekannten Spam-Domains.hilfreich bei Whitelists, Anwendung muß gut durchdacht seinwenig hilfreich, höchstens in Verbindung mit DKIM

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 10 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

Realtime Blackhole Lists

Sperrung anhand der IP-Adresse des AbsendersAuch DNSBL genannt: Mißbrauch von DNS um Informationen zuIP-Adressen zu verteilenVertrauen in Betreiber von RBLs notwendigdiverse Policies: offene Relays, bekannte Spammer, dial-inAdressenWer kommt alles auf die Liste? Wie verfährt man wenn jemandfälschlich auf die Liste gesetzt wurde? Wie schnell werden dieListen aktualisiert?rechtlich nicht einwandfrei: Speicherung von IP-Adressen könnenpersonenbezogen seingenerell aber recht effektiv

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 11 / 28

URI-Blacklists

Filtern nach URIs innerhalb der E-MailBei Verwendung beliebiger Subdomains nur die unterste DomainverwendenVorsicht: uk hat 3. LevelProblem: Redirect-Dienste wie z.B. TinyURLDatenschutzproblem existiert auch hierSpammer umgehen dies durch z.B. GIF-Bilder mit URLs

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 12 / 28

URI-Blacklists

Filtern nach URIs innerhalb der E-MailBei Verwendung beliebiger Subdomains nur die unterste DomainverwendenVorsicht: uk hat 3. LevelProblem: Redirect-Dienste wie z.B. TinyURLDatenschutzproblem existiert auch hierSpammer umgehen dies durch z.B. GIF-Bilder mit URLs

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 12 / 28

URI-Blacklists

Filtern nach URIs innerhalb der E-MailBei Verwendung beliebiger Subdomains nur die unterste DomainverwendenVorsicht: uk hat 3. LevelProblem: Redirect-Dienste wie z.B. TinyURLDatenschutzproblem existiert auch hierSpammer umgehen dies durch z.B. GIF-Bilder mit URLs

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 12 / 28

URI-Blacklists

Filtern nach URIs innerhalb der E-MailBei Verwendung beliebiger Subdomains nur die unterste DomainverwendenVorsicht: uk hat 3. LevelProblem: Redirect-Dienste wie z.B. TinyURLDatenschutzproblem existiert auch hierSpammer umgehen dies durch z.B. GIF-Bilder mit URLs

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 12 / 28

URI-Blacklists

Filtern nach URIs innerhalb der E-MailBei Verwendung beliebiger Subdomains nur die unterste DomainverwendenVorsicht: uk hat 3. LevelProblem: Redirect-Dienste wie z.B. TinyURLDatenschutzproblem existiert auch hierSpammer umgehen dies durch z.B. GIF-Bilder mit URLs

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 12 / 28

URI-Blacklists

Filtern nach URIs innerhalb der E-MailBei Verwendung beliebiger Subdomains nur die unterste DomainverwendenVorsicht: uk hat 3. LevelProblem: Redirect-Dienste wie z.B. TinyURLDatenschutzproblem existiert auch hierSpammer umgehen dies durch z.B. GIF-Bilder mit URLs

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 12 / 28

Prüfsummenvergleiche

statischer Inhalt: Prüfsummenvergleiche des Inhalts effektivbei leichten Variationen: unscharfe Verfahren wie z.B. nilsimsaVarianten: Distributed Checksum Clearing (DCC), Vipul’s Razor,PyzorBrauchen eine breite Basis um effektiv zu sein: zentrales RegisterDa nur Metadaten abgefragt werden: unbedenklich ausDatenschutzgründenKönnen sehr effektiv sein, benötigen aber in der Regelübergeordnete Instanz

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 13 / 28

Prüfsummenvergleiche

statischer Inhalt: Prüfsummenvergleiche des Inhalts effektivbei leichten Variationen: unscharfe Verfahren wie z.B. nilsimsaVarianten: Distributed Checksum Clearing (DCC), Vipul’s Razor,PyzorBrauchen eine breite Basis um effektiv zu sein: zentrales RegisterDa nur Metadaten abgefragt werden: unbedenklich ausDatenschutzgründenKönnen sehr effektiv sein, benötigen aber in der Regelübergeordnete Instanz

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 13 / 28

Prüfsummenvergleiche

statischer Inhalt: Prüfsummenvergleiche des Inhalts effektivbei leichten Variationen: unscharfe Verfahren wie z.B. nilsimsaVarianten: Distributed Checksum Clearing (DCC), Vipul’s Razor,PyzorBrauchen eine breite Basis um effektiv zu sein: zentrales RegisterDa nur Metadaten abgefragt werden: unbedenklich ausDatenschutzgründenKönnen sehr effektiv sein, benötigen aber in der Regelübergeordnete Instanz

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 13 / 28

Prüfsummenvergleiche

statischer Inhalt: Prüfsummenvergleiche des Inhalts effektivbei leichten Variationen: unscharfe Verfahren wie z.B. nilsimsaVarianten: Distributed Checksum Clearing (DCC), Vipul’s Razor,PyzorBrauchen eine breite Basis um effektiv zu sein: zentrales RegisterDa nur Metadaten abgefragt werden: unbedenklich ausDatenschutzgründenKönnen sehr effektiv sein, benötigen aber in der Regelübergeordnete Instanz

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 13 / 28

Prüfsummenvergleiche

statischer Inhalt: Prüfsummenvergleiche des Inhalts effektivbei leichten Variationen: unscharfe Verfahren wie z.B. nilsimsaVarianten: Distributed Checksum Clearing (DCC), Vipul’s Razor,PyzorBrauchen eine breite Basis um effektiv zu sein: zentrales RegisterDa nur Metadaten abgefragt werden: unbedenklich ausDatenschutzgründenKönnen sehr effektiv sein, benötigen aber in der Regelübergeordnete Instanz

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 13 / 28

Prüfsummenvergleiche

statischer Inhalt: Prüfsummenvergleiche des Inhalts effektivbei leichten Variationen: unscharfe Verfahren wie z.B. nilsimsaVarianten: Distributed Checksum Clearing (DCC), Vipul’s Razor,PyzorBrauchen eine breite Basis um effektiv zu sein: zentrales RegisterDa nur Metadaten abgefragt werden: unbedenklich ausDatenschutzgründenKönnen sehr effektiv sein, benötigen aber in der Regelübergeordnete Instanz

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 13 / 28

Frequenzanalyse

Reputationsverfahren, Häufigkeit und Frequenz von E-MailsGrund-Maillast notwendigVerhältnis gültige zu ungültigen AdressenGröße der E-Mails: Alle ungefähr gleichgroß?temporäres Blacklisten von IP-Adressenrecht einfaches und brauchbares Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 14 / 28

Frequenzanalyse

Reputationsverfahren, Häufigkeit und Frequenz von E-MailsGrund-Maillast notwendigVerhältnis gültige zu ungültigen AdressenGröße der E-Mails: Alle ungefähr gleichgroß?temporäres Blacklisten von IP-Adressenrecht einfaches und brauchbares Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 14 / 28

Frequenzanalyse

Reputationsverfahren, Häufigkeit und Frequenz von E-MailsGrund-Maillast notwendigVerhältnis gültige zu ungültigen AdressenGröße der E-Mails: Alle ungefähr gleichgroß?temporäres Blacklisten von IP-Adressenrecht einfaches und brauchbares Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 14 / 28

Frequenzanalyse

Reputationsverfahren, Häufigkeit und Frequenz von E-MailsGrund-Maillast notwendigVerhältnis gültige zu ungültigen AdressenGröße der E-Mails: Alle ungefähr gleichgroß?temporäres Blacklisten von IP-Adressenrecht einfaches und brauchbares Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 14 / 28

Frequenzanalyse

Reputationsverfahren, Häufigkeit und Frequenz von E-MailsGrund-Maillast notwendigVerhältnis gültige zu ungültigen AdressenGröße der E-Mails: Alle ungefähr gleichgroß?temporäres Blacklisten von IP-Adressenrecht einfaches und brauchbares Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 14 / 28

Frequenzanalyse

Reputationsverfahren, Häufigkeit und Frequenz von E-MailsGrund-Maillast notwendigVerhältnis gültige zu ungültigen AdressenGröße der E-Mails: Alle ungefähr gleichgroß?temporäres Blacklisten von IP-Adressenrecht einfaches und brauchbares Verfahren

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 14 / 28

Sperren SMTP-Port, MTAMARK

nur für ISPs und Unternehmen interessanteinige Provider wie z.B. AOL führen dies durchMUAs müssen Mailserver des Providers erreichen können oderMSP-Port verwendenProblem ist, daß man selber keinen eigenen Mailserver betreibenkann, viele Firmen wollen dies aber.könnte gegen viele Bot–Netze helfen

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 15 / 28

Sperren SMTP-Port, MTAMARK

nur für ISPs und Unternehmen interessanteinige Provider wie z.B. AOL führen dies durchMUAs müssen Mailserver des Providers erreichen können oderMSP-Port verwendenProblem ist, daß man selber keinen eigenen Mailserver betreibenkann, viele Firmen wollen dies aber.könnte gegen viele Bot–Netze helfen

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 15 / 28

Sperren SMTP-Port, MTAMARK

nur für ISPs und Unternehmen interessanteinige Provider wie z.B. AOL führen dies durchMUAs müssen Mailserver des Providers erreichen können oderMSP-Port verwendenProblem ist, daß man selber keinen eigenen Mailserver betreibenkann, viele Firmen wollen dies aber.könnte gegen viele Bot–Netze helfen

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 15 / 28

Sperren SMTP-Port, MTAMARK

nur für ISPs und Unternehmen interessanteinige Provider wie z.B. AOL führen dies durchMUAs müssen Mailserver des Providers erreichen können oderMSP-Port verwendenProblem ist, daß man selber keinen eigenen Mailserver betreibenkann, viele Firmen wollen dies aber.könnte gegen viele Bot–Netze helfen

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 15 / 28

Sperren SMTP-Port, MTAMARK

nur für ISPs und Unternehmen interessanteinige Provider wie z.B. AOL führen dies durchMUAs müssen Mailserver des Providers erreichen können oderMSP-Port verwendenProblem ist, daß man selber keinen eigenen Mailserver betreibenkann, viele Firmen wollen dies aber.könnte gegen viele Bot–Netze helfen

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 15 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Heuristische Inhaltsanalyse

Analyse nach Wörtern, Strukturen: rule-based filteringSuche nach bestimmten Begriffen im Body und HeaderBody: Großschreibung, Austragungsoptionen, Aufforderung URLaufzurufen, Mustern innerhalb von URLs,HTML-Verschleierungstricks, . . .Header: Absender, Empfänger, Versand-Datum,X-Mailer-Analyse, Zeitsprünge in Received-Zeilen, . . .Verwendung von Scores für verschiedene gefundeneEigenschaften, positiv wie negativberühmter Vertreter: SpamAssassinEffektivität recht hoch, muß auf aktuellem Stand gehalten werden(Katz-und-Maus-Spiel), hoher Rechenaufwand durch viele Regelnund Regular-Expressionsauf dem Server nur bedingt anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 16 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

Statistische Inhaltsanalyse

Vorhersagbarkeit von HAM oder SPAM durch statistische Analysealter E-Mailsnaive Bayes-Filter: Statistiken über einzelne Wörter (token)Trainingsphase notwendig für SPAM und HAMFilter muß ständig aktualisiert werdenSpamfallen können zum automatischem Training verwendetwerdenProbleme bereiten HTML-Verschleierungen, es gibt Ansätze diediese vorher rendernErfolg hängt vom Training ab, gewöhnlich nur im MUA anwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 17 / 28

DomainKeys Identified Mails (DKIM)

Validierung des Absenders und der E-Mail durch digitaleSignierung auf dem Serverkeine Änderungen am MUA notwendigReplay–Attacken möglich, d.h. mehrfaches versenden einereinmal signierten E-Mailpublic key wird via DNS verteilt, ratsam nur mit DNSSecSpammer können auch DKIM einsetzen: Kombination mit RHSBLbislang keine große Verbreitung, derzeit nur als Whitelistverwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 18 / 28

DomainKeys Identified Mails (DKIM)

Validierung des Absenders und der E-Mail durch digitaleSignierung auf dem Serverkeine Änderungen am MUA notwendigReplay–Attacken möglich, d.h. mehrfaches versenden einereinmal signierten E-Mailpublic key wird via DNS verteilt, ratsam nur mit DNSSecSpammer können auch DKIM einsetzen: Kombination mit RHSBLbislang keine große Verbreitung, derzeit nur als Whitelistverwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 18 / 28

DomainKeys Identified Mails (DKIM)

Validierung des Absenders und der E-Mail durch digitaleSignierung auf dem Serverkeine Änderungen am MUA notwendigReplay–Attacken möglich, d.h. mehrfaches versenden einereinmal signierten E-Mailpublic key wird via DNS verteilt, ratsam nur mit DNSSecSpammer können auch DKIM einsetzen: Kombination mit RHSBLbislang keine große Verbreitung, derzeit nur als Whitelistverwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 18 / 28

DomainKeys Identified Mails (DKIM)

Validierung des Absenders und der E-Mail durch digitaleSignierung auf dem Serverkeine Änderungen am MUA notwendigReplay–Attacken möglich, d.h. mehrfaches versenden einereinmal signierten E-Mailpublic key wird via DNS verteilt, ratsam nur mit DNSSecSpammer können auch DKIM einsetzen: Kombination mit RHSBLbislang keine große Verbreitung, derzeit nur als Whitelistverwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 18 / 28

DomainKeys Identified Mails (DKIM)

Validierung des Absenders und der E-Mail durch digitaleSignierung auf dem Serverkeine Änderungen am MUA notwendigReplay–Attacken möglich, d.h. mehrfaches versenden einereinmal signierten E-Mailpublic key wird via DNS verteilt, ratsam nur mit DNSSecSpammer können auch DKIM einsetzen: Kombination mit RHSBLbislang keine große Verbreitung, derzeit nur als Whitelistverwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 18 / 28

DomainKeys Identified Mails (DKIM)

Validierung des Absenders und der E-Mail durch digitaleSignierung auf dem Serverkeine Änderungen am MUA notwendigReplay–Attacken möglich, d.h. mehrfaches versenden einereinmal signierten E-Mailpublic key wird via DNS verteilt, ratsam nur mit DNSSecSpammer können auch DKIM einsetzen: Kombination mit RHSBLbislang keine große Verbreitung, derzeit nur als Whitelistverwendbar

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 18 / 28

SMTP-Callout

Validierung des Absenders durch SMTP-Verbindung zumMailserver des vermeintlichen Absendersauch: Sender–Address–Verification, Sender–VerifyProblem: Bindung von Ressourcen, nachfragen kann längerdauern, manche Maliserver nehmen generell für alle E-Mailsentgegenerhöhte Last auf Gegensystem kann zu Verstimmungen führenEinsatz nicht ratsamVariante: Testen ob Server überhaupt auf Port 25 reagiert. SYN,SYN-ACK

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 19 / 28

SMTP-Callout

Validierung des Absenders durch SMTP-Verbindung zumMailserver des vermeintlichen Absendersauch: Sender–Address–Verification, Sender–VerifyProblem: Bindung von Ressourcen, nachfragen kann längerdauern, manche Maliserver nehmen generell für alle E-Mailsentgegenerhöhte Last auf Gegensystem kann zu Verstimmungen führenEinsatz nicht ratsamVariante: Testen ob Server überhaupt auf Port 25 reagiert. SYN,SYN-ACK

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 19 / 28

SMTP-Callout

Validierung des Absenders durch SMTP-Verbindung zumMailserver des vermeintlichen Absendersauch: Sender–Address–Verification, Sender–VerifyProblem: Bindung von Ressourcen, nachfragen kann längerdauern, manche Maliserver nehmen generell für alle E-Mailsentgegenerhöhte Last auf Gegensystem kann zu Verstimmungen führenEinsatz nicht ratsamVariante: Testen ob Server überhaupt auf Port 25 reagiert. SYN,SYN-ACK

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 19 / 28

SMTP-Callout

Validierung des Absenders durch SMTP-Verbindung zumMailserver des vermeintlichen Absendersauch: Sender–Address–Verification, Sender–VerifyProblem: Bindung von Ressourcen, nachfragen kann längerdauern, manche Maliserver nehmen generell für alle E-Mailsentgegenerhöhte Last auf Gegensystem kann zu Verstimmungen führenEinsatz nicht ratsamVariante: Testen ob Server überhaupt auf Port 25 reagiert. SYN,SYN-ACK

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 19 / 28

SMTP-Callout

Validierung des Absenders durch SMTP-Verbindung zumMailserver des vermeintlichen Absendersauch: Sender–Address–Verification, Sender–VerifyProblem: Bindung von Ressourcen, nachfragen kann längerdauern, manche Maliserver nehmen generell für alle E-Mailsentgegenerhöhte Last auf Gegensystem kann zu Verstimmungen führenEinsatz nicht ratsamVariante: Testen ob Server überhaupt auf Port 25 reagiert. SYN,SYN-ACK

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 19 / 28

SMTP-Callout

Validierung des Absenders durch SMTP-Verbindung zumMailserver des vermeintlichen Absendersauch: Sender–Address–Verification, Sender–VerifyProblem: Bindung von Ressourcen, nachfragen kann längerdauern, manche Maliserver nehmen generell für alle E-Mailsentgegenerhöhte Last auf Gegensystem kann zu Verstimmungen führenEinsatz nicht ratsamVariante: Testen ob Server überhaupt auf Port 25 reagiert. SYN,SYN-ACK

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 19 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Greylisting

Spammer ignorieren Antworten des Servers, sie lassen sich durchtemporäre Fehlermeldungen abschreckenFunktionsweise:

I 1. E-Mail wird durch 4xx-Fehlermeldung abgelehnt,I spätere E-Mails mit Tripel (Absender, Sender-IP-Adresse,

Empfänger) werden temporär freigeschaltet: GreylistI jedes Auftreten des Tripels aktualisiert Greylist-Eintrag

Zeiten relevant: sehr effektiv zusammen mit RBLnicht alle Mailserver sind RFC-konform: Whitelists notwendigalle MX-Server müssen Greylisting unterstützenderzeit noch die wirksamste Waffe gegen Spam!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 20 / 28

Spamfallen, Greytrapping

Spamfallen: versteckte, nicht-existierende Mailadressenalles was an diese Adresse gesendet wird ist Spam: gut fürAnalyse via BayesGreytrapping: temporäres Sperren eines Mailservers der an eineSpamfalle E-Mails sendetbeschäftigen Spammer mit unnötiger Arbeitdynamische Adressen und Weblogs können Beweise fürGerichtsverfahren liefernVorsicht: Spammer verwenden manchmal derartige Adressen alsAbsender, bounces und Abwesenheitsnotizen können dann zuProblemen führen!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 21 / 28

Spamfallen, Greytrapping

Spamfallen: versteckte, nicht-existierende Mailadressenalles was an diese Adresse gesendet wird ist Spam: gut fürAnalyse via BayesGreytrapping: temporäres Sperren eines Mailservers der an eineSpamfalle E-Mails sendetbeschäftigen Spammer mit unnötiger Arbeitdynamische Adressen und Weblogs können Beweise fürGerichtsverfahren liefernVorsicht: Spammer verwenden manchmal derartige Adressen alsAbsender, bounces und Abwesenheitsnotizen können dann zuProblemen führen!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 21 / 28

Spamfallen, Greytrapping

Spamfallen: versteckte, nicht-existierende Mailadressenalles was an diese Adresse gesendet wird ist Spam: gut fürAnalyse via BayesGreytrapping: temporäres Sperren eines Mailservers der an eineSpamfalle E-Mails sendetbeschäftigen Spammer mit unnötiger Arbeitdynamische Adressen und Weblogs können Beweise fürGerichtsverfahren liefernVorsicht: Spammer verwenden manchmal derartige Adressen alsAbsender, bounces und Abwesenheitsnotizen können dann zuProblemen führen!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 21 / 28

Spamfallen, Greytrapping

Spamfallen: versteckte, nicht-existierende Mailadressenalles was an diese Adresse gesendet wird ist Spam: gut fürAnalyse via BayesGreytrapping: temporäres Sperren eines Mailservers der an eineSpamfalle E-Mails sendetbeschäftigen Spammer mit unnötiger Arbeitdynamische Adressen und Weblogs können Beweise fürGerichtsverfahren liefernVorsicht: Spammer verwenden manchmal derartige Adressen alsAbsender, bounces und Abwesenheitsnotizen können dann zuProblemen führen!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 21 / 28

Spamfallen, Greytrapping

Spamfallen: versteckte, nicht-existierende Mailadressenalles was an diese Adresse gesendet wird ist Spam: gut fürAnalyse via BayesGreytrapping: temporäres Sperren eines Mailservers der an eineSpamfalle E-Mails sendetbeschäftigen Spammer mit unnötiger Arbeitdynamische Adressen und Weblogs können Beweise fürGerichtsverfahren liefernVorsicht: Spammer verwenden manchmal derartige Adressen alsAbsender, bounces und Abwesenheitsnotizen können dann zuProblemen führen!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 21 / 28

Spamfallen, Greytrapping

Spamfallen: versteckte, nicht-existierende Mailadressenalles was an diese Adresse gesendet wird ist Spam: gut fürAnalyse via BayesGreytrapping: temporäres Sperren eines Mailservers der an eineSpamfalle E-Mails sendetbeschäftigen Spammer mit unnötiger Arbeitdynamische Adressen und Weblogs können Beweise fürGerichtsverfahren liefernVorsicht: Spammer verwenden manchmal derartige Adressen alsAbsender, bounces und Abwesenheitsnotizen können dann zuProblemen führen!

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 21 / 28

Tokenbasierte und Challenge–Response–Verfahren

spezieller Token innerhalb einer E-Mail notwendig, wird überBounce erhaltenmanchmal auch alternative Wege wie Webbestätigung erforderlichVorgang meist nur einmal notwendigVerfahren ist sehr effektivjedoch nicht ratsam, hohe Hürde für normale MailversenderVerwendung mit Mailinglisten hoffnungslos: Whitelists notwendig

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 22 / 28

Tokenbasierte und Challenge–Response–Verfahren

spezieller Token innerhalb einer E-Mail notwendig, wird überBounce erhaltenmanchmal auch alternative Wege wie Webbestätigung erforderlichVorgang meist nur einmal notwendigVerfahren ist sehr effektivjedoch nicht ratsam, hohe Hürde für normale MailversenderVerwendung mit Mailinglisten hoffnungslos: Whitelists notwendig

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 22 / 28

Tokenbasierte und Challenge–Response–Verfahren

spezieller Token innerhalb einer E-Mail notwendig, wird überBounce erhaltenmanchmal auch alternative Wege wie Webbestätigung erforderlichVorgang meist nur einmal notwendigVerfahren ist sehr effektivjedoch nicht ratsam, hohe Hürde für normale MailversenderVerwendung mit Mailinglisten hoffnungslos: Whitelists notwendig

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 22 / 28

Tokenbasierte und Challenge–Response–Verfahren

spezieller Token innerhalb einer E-Mail notwendig, wird überBounce erhaltenmanchmal auch alternative Wege wie Webbestätigung erforderlichVorgang meist nur einmal notwendigVerfahren ist sehr effektivjedoch nicht ratsam, hohe Hürde für normale MailversenderVerwendung mit Mailinglisten hoffnungslos: Whitelists notwendig

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 22 / 28

Tokenbasierte und Challenge–Response–Verfahren

spezieller Token innerhalb einer E-Mail notwendig, wird überBounce erhaltenmanchmal auch alternative Wege wie Webbestätigung erforderlichVorgang meist nur einmal notwendigVerfahren ist sehr effektivjedoch nicht ratsam, hohe Hürde für normale MailversenderVerwendung mit Mailinglisten hoffnungslos: Whitelists notwendig

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 22 / 28

Tokenbasierte und Challenge–Response–Verfahren

spezieller Token innerhalb einer E-Mail notwendig, wird überBounce erhaltenmanchmal auch alternative Wege wie Webbestätigung erforderlichVorgang meist nur einmal notwendigVerfahren ist sehr effektivjedoch nicht ratsam, hohe Hürde für normale MailversenderVerwendung mit Mailinglisten hoffnungslos: Whitelists notwendig

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 22 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Bounce Address Tag Validation (BATV)

Vermeidung von falschen Bouncesspezielle Tags in Envelope-From Adresse, individuelleAbsenderadressenfunktioniert nicht mit Greylistinglocal-part darf nur maximal 64 Zeichen lang seinBATV muß schwer ratbar und Tag ständig erneuert werden,Tracking der vergebenen Tagshilft nur gegen Kollateral–Spammöglicher Gewinn rechtfertigt nicht den Aufwand

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 23 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Elektronische Briefmarken

Idee: geringe Kosten pro E-Mail treffen hauptsächlich SpammerGewinnreduzierung beim Spammer, diese verlieren InteresseFrage der Geldeintreibung offen: MicropaymentWer soll das Geld bekommen? Der ISP? Wer darf dann ISPwerden?interessante Idee: Empfänger bekommt das Geld, spamlesen wirdlukrativVariante: Whitelisten für bestätigte KontakteProbleme: legitime Massenversendungen, Mailinglisten

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 24 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Proof-of-Work

Idee ähnlich der elektronischen Briefmarkehohe CPU-Last vor dem Versenden erschwert Spammern dasLebenwenig CPU-Last zur VerifizierungBot–Netze haben viel Rechenleistung, daher wenigerfolgversprechendderzeit kaum Verbreitung, praktisch keine Verwendungmögliches Verfahren: HashCashProblem: Muß pro E-Mail unterschiedlich sein, was ist mitRelaying über mehrere Server?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 25 / 28

Dedizierte Mailserver

Zustellung nur über spezielle Mailserver möglicheffektives Verfolgen von Spamversendern möglichProblem: alle ISPs müssen mitmachen und Port 25 entsprechendfilternProblem: zuviel Macht bei ISPs?Wer regelt wer Mailserver betreiben darf?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 26 / 28

Dedizierte Mailserver

Zustellung nur über spezielle Mailserver möglicheffektives Verfolgen von Spamversendern möglichProblem: alle ISPs müssen mitmachen und Port 25 entsprechendfilternProblem: zuviel Macht bei ISPs?Wer regelt wer Mailserver betreiben darf?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 26 / 28

Dedizierte Mailserver

Zustellung nur über spezielle Mailserver möglicheffektives Verfolgen von Spamversendern möglichProblem: alle ISPs müssen mitmachen und Port 25 entsprechendfilternProblem: zuviel Macht bei ISPs?Wer regelt wer Mailserver betreiben darf?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 26 / 28

Dedizierte Mailserver

Zustellung nur über spezielle Mailserver möglicheffektives Verfolgen von Spamversendern möglichProblem: alle ISPs müssen mitmachen und Port 25 entsprechendfilternProblem: zuviel Macht bei ISPs?Wer regelt wer Mailserver betreiben darf?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 26 / 28

Dedizierte Mailserver

Zustellung nur über spezielle Mailserver möglicheffektives Verfolgen von Spamversendern möglichProblem: alle ISPs müssen mitmachen und Port 25 entsprechendfilternProblem: zuviel Macht bei ISPs?Wer regelt wer Mailserver betreiben darf?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 26 / 28

Verbot von Spam

derzeit ist Spamversand erlaubtVerbot müßte weltweit geltenkonsequente Verfolgung notwendigSperrung von IP-Adressen aus Ländern die Spam erlaubendenkbarmögliches Problem: zuviel Macht für den Staat?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 27 / 28

Verbot von Spam

derzeit ist Spamversand erlaubtVerbot müßte weltweit geltenkonsequente Verfolgung notwendigSperrung von IP-Adressen aus Ländern die Spam erlaubendenkbarmögliches Problem: zuviel Macht für den Staat?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 27 / 28

Verbot von Spam

derzeit ist Spamversand erlaubtVerbot müßte weltweit geltenkonsequente Verfolgung notwendigSperrung von IP-Adressen aus Ländern die Spam erlaubendenkbarmögliches Problem: zuviel Macht für den Staat?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 27 / 28

Verbot von Spam

derzeit ist Spamversand erlaubtVerbot müßte weltweit geltenkonsequente Verfolgung notwendigSperrung von IP-Adressen aus Ländern die Spam erlaubendenkbarmögliches Problem: zuviel Macht für den Staat?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 27 / 28

Verbot von Spam

derzeit ist Spamversand erlaubtVerbot müßte weltweit geltenkonsequente Verfolgung notwendigSperrung von IP-Adressen aus Ländern die Spam erlaubendenkbarmögliches Problem: zuviel Macht für den Staat?

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 27 / 28

Schlußbemerkungen

eine perfekte Lösung gibt es nichtnicht alle Verfahren eignen sich überallKombination mehrerer Verfahren ratsamjuristische Aspekte dürfen nicht vergessen werdenReihenfolge mitunter wichtig (Ressourcenverbrauch)heute funktionierende Verfahren müssen nicht morgen auch nocherfolgreich sein, Spammer passen sich an

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 28 / 28

Schlußbemerkungen

eine perfekte Lösung gibt es nichtnicht alle Verfahren eignen sich überallKombination mehrerer Verfahren ratsamjuristische Aspekte dürfen nicht vergessen werdenReihenfolge mitunter wichtig (Ressourcenverbrauch)heute funktionierende Verfahren müssen nicht morgen auch nocherfolgreich sein, Spammer passen sich an

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 28 / 28

Schlußbemerkungen

eine perfekte Lösung gibt es nichtnicht alle Verfahren eignen sich überallKombination mehrerer Verfahren ratsamjuristische Aspekte dürfen nicht vergessen werdenReihenfolge mitunter wichtig (Ressourcenverbrauch)heute funktionierende Verfahren müssen nicht morgen auch nocherfolgreich sein, Spammer passen sich an

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 28 / 28

Schlußbemerkungen

eine perfekte Lösung gibt es nichtnicht alle Verfahren eignen sich überallKombination mehrerer Verfahren ratsamjuristische Aspekte dürfen nicht vergessen werdenReihenfolge mitunter wichtig (Ressourcenverbrauch)heute funktionierende Verfahren müssen nicht morgen auch nocherfolgreich sein, Spammer passen sich an

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 28 / 28

Schlußbemerkungen

eine perfekte Lösung gibt es nichtnicht alle Verfahren eignen sich überallKombination mehrerer Verfahren ratsamjuristische Aspekte dürfen nicht vergessen werdenReihenfolge mitunter wichtig (Ressourcenverbrauch)heute funktionierende Verfahren müssen nicht morgen auch nocherfolgreich sein, Spammer passen sich an

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 28 / 28

Schlußbemerkungen

eine perfekte Lösung gibt es nichtnicht alle Verfahren eignen sich überallKombination mehrerer Verfahren ratsamjuristische Aspekte dürfen nicht vergessen werdenReihenfolge mitunter wichtig (Ressourcenverbrauch)heute funktionierende Verfahren müssen nicht morgen auch nocherfolgreich sein, Spammer passen sich an

Dirk Geschke (LUG-Erding) E-Mail 23. April 2008 28 / 28