File:  [Repository] / email / memo.tex
Revision 1.2: download - view: text, annotated - select for diffs - revision graph
Mon Jun 30 19:54:49 2003 UTC (20 years, 10 months ago) by dwinter
Branches: MAIN
CVS tags: HEAD
Fassung an JR versandt.

\documentclass[a4paper]{article}

\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{ae}
\usepackage{ngerman}

\begin{document}
\title{Memo: Mailserver / Spamproblem}
\author{IT-Gruppe / EDV}
\date{\today}
\maketitle

\section{Problemstellung}
\label{sec:situation}

In den letzten Monaten ist weltweit ein verstärktes Aufkommen von nicht
gewollt zugesandter Werbe-email zu beobachten (Spam). Die entsprechenden Beschwerden der
Nutzer von Emailsystemen häufen sich, dies gilt auch hier am
Institut.

Der meist verwendete Lösungsansatz ist der Einsatz von Filtern
auf dem entsprechenden Mailserver,  um als Spam erkannte Mails
besonders zu kennzeichnen. Der Mailclient des Benutzers kann diese
Mails dann seinerseits in bestimmte Mailboxen verschieben.

Der von einigen Einrichtung gegangene Weg, als Spam erkannte Mails
direkt zu löschen, ist aus datenschutz- und
telekommunikationsrechtlichen Gründe aus unserer Sicht abzulehnen.

Bei allen Lösungen muss berücksichtigt werden, dass die
Pflege eines Spam-Filters einen nicht unerheblichen Arbeitsaufwand
erfordert, da eine ständige Fortschreibung der Regeln notwendig ist,
um die Wirksamkeit der Filter zu sichern.

Der vom Institut eingesetzte Mailserver ``Quickmail'' läßt ein
serverseitiges Filtern der Mails nur eingeschränkt zu. Die eingebauten
Filterfunktionen sind für den Einsatz als Spamfilter nicht
geeignet. Nach Auskunft der Herstellerfirma ist mit einer
Implementation eines Spamfilters nicht zu rechnen.


\section{Lösung}
\label{sec:losung}

Es ergeben  sich prinzipiell drei Möglichkeiten, die
im Anhang ausführlicher beschrieben werden. Zusammenfassend wird aus Sicht der IT-Gruppe in Absprache mit der EDV empfohlen:
\begin{itemize}
\item In der ersten Stufe werden Mails an das MPIWG  von einem Rechner am FHI/GNZ gefiltert und mit einer Kennzeichnung versehen an den Empfänger weitergeleitet (Anhang: Variante 2).
\item In einer zweiten Stufe wird die Übernahme des gesamten Mailsystems durch das FHI/GNZ angestrebt (Anhang: Variante 3). 
\end{itemize}

Für diese Lösung spricht die schnelle Realisierbarkeit, da zusätzliche Entwicklungen, wie die gesamte Umstellung unserer Benutzerverwaltung zunächst nicht erforderlich ist. Desweiteren ist dies zunächst die kostengünstigste Lösung.

\section{Zeitplan}

Nach ersten Gesprächen mit dem FHI/GNZ ist folgender Zeitplan realistisch:
\begin{itemize}
\item Klärung der technischen und administrativen Fragen: Mitte/Ende Juli
\item Einrichtung und Testphase des neuen Systems: Mitte bis Ende August
\item Einführung des neuen Systems Anfang/Mitte September
\end{itemize}

\section{Anhang: Mögliche Varianten}
\subsection{Variante 1: Vorgeschalteter Filter an der Leibniz}
\label{sec:vorg-filt-an}

Alle Mails werden von der Leibniz empfangen, dort gefiltert und dann
mit entsprechenden Tags versehen an den eigentlichen Quickmail-Server
weitergeleitet. Zum Einsatz könnten hier als Public Domain Software erhältliche
Standardfilterprogramme kommen.

Die entsprechenden für eine effiziente Filterung notwendigen Regeln
müssen bei dieser Lösung durch einen Mitarbeiter am Institut gepflegt
werden. Außerdem ist für eine effiziente Filterung die Rückmeldung
von den Nutzern erforderlich, inwieweit die Kennzeichnung der Mails
zutrifft. Es ist mit einem Betreuungsaufwand  von etwa 4 Stunden pro Woche zu rechnen.


\subsection{Variante 2: Vorfilterung durch das FHI/GNZ}
\label{sec:vorf-durch-das}

Alle Mails werden von einem Server am FHI/GNZ empfangen und unter Anwendung
der dort etablierten Regeln vorgefiltert.
Spam-Mail wird dann an unseren Quickmail-Server entsprechend
gekennzeichnet weitergeleitet. Die entsprechenden Filterregeln werden in diesem Falle  vom FHI/GNZ gepflegt. Durch
die größere Anzahl der Nutzer ist die Rückmeldequote höher und es kann
von besseren Trefferquoten bei der Filterung ausgegangen werden. 

Nach dem bisherigen Stand ist für diese Lösung eine Erweiterung des für die Filterung notwendigen Servers am FHI/GNZ um eine Prozessoreinheit notwendig (500-100 EURO)


\subsection{Variante 3: Migration des gesamten Mailsystems an das FHI/GNZ}
\label{sec:migr-des-gesamt}

Die gesamte Mailverwaltung wird vom FHI/GNZ durchgeführt. Mailserver
und Filter werden komplett dort verwaltet.

Neben den oben genannten Vorteilen bei der Aktualisierung der
Filterregeln, würde bei dieser Lösung die arbeitsaufwendige Wartung der
Mailserver auf Seiten des MPIWG entfallen. Eine einheitliche
Benutzerverwaltung von Mailserver, sowie dem Archiv- und Backupsystem
könnte etabliert 
werden. 
Bei dieser Lösung muss geprüft werden, wie die Benutzerverwaltung
vom MPIWG durchgeführt werden kann und wie bisher gewünschte Services,
wie das Adressbuch, weiter bereitgestellt werden können. Nach den bisherigen Auskünften des FHI/GNZ ist für diese Lösung die Anschaffung eines eigenene Mailservers notwendig (ca. 3000 EURO).
\end{document}



FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>