<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
>

<channel>
	<title>Wikipedistik &#187; Greylisting</title>
	<atom:link href="http://wikipedistik.de/tag/greylisting/feed/" rel="self" type="application/rss+xml" />
	<link>http://wikipedistik.de</link>
	<description>Nutzung von Wikis als Wissensmanagement unterstützende Systeme in Unternehmen</description>
	<lastBuildDate>Thu, 02 Jun 2011 21:06:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
<creativeCommons:license>http://creativecommons.org/licenses/by/2.0/de/</creativeCommons:license>
		<item>
		<title>Graue Listen gegen Spam</title>
		<link>http://wikipedistik.de/2008/03/25/graue-listen-gegen-spam/</link>
		<comments>http://wikipedistik.de/2008/03/25/graue-listen-gegen-spam/#comments</comments>
		<pubDate>Tue, 25 Mar 2008 02:44:15 +0000</pubDate>
		<dc:creator>Tim Bartel</dc:creator>
				<category><![CDATA[Offtopic]]></category>
		<category><![CDATA[E-Mail]]></category>
		<category><![CDATA[Graylisting]]></category>
		<category><![CDATA[Greylisting]]></category>
		<category><![CDATA[Ham]]></category>
		<category><![CDATA[Spam]]></category>
		<category><![CDATA[SpamAssassin]]></category>
		<category><![CDATA[Statistik]]></category>

		<guid isPermaLink="false">http://wikipedistik.de/2008/03/25/graue-listen-gegen-spam/</guid>
		<description><![CDATA[<div class="caption right"><img src='http://wikipedistik.de/wp-content/uploads/2008/03/spam-small.png' alt='Spam is evil' /></div>
<p>Das <a href="http://de.wikipedia.org/wiki/Spam" rel="nofollow" class="liwikipedia">Spam</a>-Problem hat in den letzten Monaten bei mir etwas überhand genommen. Der Großteil der Mails, die an eine meiner Domains gesendet werden, landen auf einem gemeinsamen Server und wurden bisher ausschließlich <a href="http://spamassassin.apache.org/" class="liexternal">SpamAssassin</a> vorgeworfen.</p>
<p>Der Assassine leistet hervorragende Arbeit. Um Spam (= unerwünschte Mail) von Ham (= erwünschte Mail) zu unterscheiden, führt er eine Reihe von Tests durch:</p>
<ul>
<li>Prüfung der Mails auf statistische Spam-Merkmale (z.B. &#8220;Absender aus Korea&#8221;, &#8220;Mail nur in GROSSBUCHSTABEN&#8221;, &#8230;)</li>
<li>Abfrage von <a href="http://de.wikipedia.org/wiki/Realtime_Blackhole_List" rel="nofollow" class="liwikipedia">RBLs und DNSBLs</a></li>
<li>Abfrage von Prüfsummen-basierten Filter-Diensten</li>
<li><a href="http://de.wikipedia.org/wiki/Bayesscher_Filter" rel="nofollow" class="liwikipedia">Bayes-Filterung</a></li>
</ul>
<p>Das Problem: Die Durchführung dieser Tests ist ressourcen-intensiv. Neben einer Menge Hauptspeicher belegt die Spam-Filterung zusätzlich CPU-Arbeitszeit und die Abfragen an netzbasierte Dienste summieren sich auch.</p>
<p>Schaut man sich einmal das Aufkommen von meiner Mail der letzten Monate an&#8230;</p>
<div class="caption center"><img src='http://wikipedistik.de/wp-content/uploads/2008/03/mailaufkommen-small.png' alt='Mailaufkommen 2007/2008' /><br />Mailaufkommen (Größter Teil meiner Mailadressen) 2007/2008</div>
<p>&#8230;so sieht man, dass die Situation wohl eher nicht besser wird.</p>
<p><!--more-->Neben dem Problem der Ressourcen-Auslastung (das z.B. dazu führt, dass die Webseiten auf dem Server &#8211; unter anderem Wikipedistik &#8211; langsamer ausgeliefert werden) kommt noch dazu, dass die Anzahl der <em>false negatives</em> steigt. Unter &#8220;false negative&#8221; versteht man Mails, die Spam sind, aber nicht als solcher erkannt werden. Diese Nachrichten verstopfen die Inbox und verursachen Aufwand, da sie von Hand gelöscht werden müssen.</p>
<p>SpamAssassin ist gut &#8211; aber kein Spamfilter hat eine Erkennungsrate von 100 Prozent. Daraus folgt: Je mehr Mails durch den Filter gehen, desto mehr Problemfälle treten auf. Dank sinnvoller Einstellung gibt es bei mir jedoch so gut wie keine <em>false positives</em>, also Mails, die erwünschte Mails darstellen, aber als Spam erkannt wurden. Der Preis für eine geringere Wahrscheinlichkeit an &#8220;false positives&#8221; ist jedoch eine höhere Wahrscheinlichkeit für &#8220;false negatives&#8221;.</p>
<p>Die einfachste Lösung um die Anzahl an Fehleinordnungen wieder zu senken ist einleuchtend: Die Anzahl der von SpamAssassin zu bearbeitenden Mails muss gesenkt werden. Dies führt dann zusätzlich zu einem weniger ausgelasteten, performanteren System.</p>
<p><strong>Greylisting</strong><br />
Aus diesem Grund habe ich am Karfreitag um 7:00 Uhr auf meinem Mailserver <a href="http://de.wikipedia.org/wiki/Greylisting" rel="nofollow" class="liwikipedia">Greylisting</a> aktiviert.</p>
<p><em>Whitelisting</em> bedeutet, dass Mail nach bestimmten Kriterien immer angenommen wird, während beim <em>Blacklisting</em> die Mail immer abgelehnt wird. <em>Greylisting</em> nutzt hingegen eine Besonderheit des SMTP-Protokolls: Kann eine Mail nicht zugestellt werden, so versucht es der entsprechende Server nach einer gewissen Zeitspanne erneut.</p>
<p>Während diese Funktionalität in jedem vernünftigem Mailsystem umgesetzt ist, so gilt dies nicht für eine Vielzahl von Spam-Software, die wesentlich einfacher gestrickt ist und in der Regel nur einen Zustellversuch macht.</p>
<p>Kontaktiert ein einlieferndes System meinen Mailserver, so gibt es folgende Daten an:</p>
<ul>
<li>IP-Adresse des absendenden Mailservers</li>
<li>E-Mail-Adresse des E-Mail-Senders</li>
<li>E-Mail-Adresse des E-Mail-Empfängers</li>
</ul>
<p>Wurde noch nie Mail empfangen, auf die dieses Trippel zutrifft, so wird die Maileinlieferung mit einem temporären Fehler quittiert. Ein herkömmliches Mailsystem versucht dann nach einer kurzen Zeitspanne eine erneute Einlieferung, die dann akzeptiert wird. Bei der Vielzahl von einmaligen Zustellversuchen von Spam führt dies dazu, dass die betreffende Mail gar nicht erst in meinem System landet und demnach auch nicht von SpamAssassin untersucht werden muss.</p>
<p>Systeme, die in der Greylist gelandet sind und danach eine erfolgreiche Zustellung durchführen, werden automatisch in die Whiltelist aufgenommen. So tritt der Nachteil der nicht unmittelbar ankommenden Mail nur beim ersten Kontakt mit einem bisher unbekannten Trippel auf. Trotzdem muss natürlich dieser Nachteil mit einem möglichen Vorteil abgewogen werden.</p>
<p>Wie meine Abwägung ausfällt?<br />
Das muss ich glaube ich nicht extra in Worten beschreiben.</p>
<p>Die folgenden Graphen sprechen für sich:</p>
<div class="caption center"><img src='http://wikipedistik.de/wp-content/uploads/2008/03/angenommene-mails.png' alt='Angenommene (und verarbeitete) Mails' /><br />Angenommene (und verarbeitete) Mails &#8211; Massiver Rückgang seit Freitag, 7:00 Uhr</div>
<div class="caption center"><img src='http://wikipedistik.de/wp-content/uploads/2008/03/abgelehnte-mails.png' alt='(Durch Greylisting) abgelehnte Mails' /><br />(Durch Greylisting) abgelehnte Mails &#8211; Aktivierung ab Freitag, 7:00 Uhr</div>]]></description>
		<wfw:commentRss>http://wikipedistik.de/2008/03/25/graue-listen-gegen-spam/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
	<creativeCommons:license>http://creativecommons.org/licenses/by/2.0/de/</creativeCommons:license>
	</item>
	</channel>
</rss>

