• Informationen für …
• Wir über uns
• Unsere Servicepalette
• Fragen, Beratung und Unterstützung
• Presse
• Projekte, Kooperationen, Arbeitsgruppen
• Andere im WWW

• E-Mail
  • Nutzung von E-Mail am LRZ
  • SquirrelMail
  • Thunderbird 3
  • Mailinglisten mit Mailman
  • Spam-Filterung am LRZ
  • Mail-Policy
  • Konfiguration von Mailservern für Mailempfang aus dem Internet
  • E-Mail-Archive am LRZ

ALIs

kommt noch

Policy für die zentralen Mailrelays des LRZ

Einleitung

In diesem Dokument wird das Verhalten der zentralen Mailrelays des LRZ beschrieben, so wie es von außen von anderen Mailservern und unseren Kunden festgestellt werden kann. Dies umfasst alle Regeln und Konfigurationsdaten, die eine Wirkung auf die Außenwelt haben.

ALs zentrale Mailrelays werden die beiden Rechner

• mailrelay1.lrz-muenchen.de und
• mailrelay2.lrz-muenchen.de

eingesetzt. Der virtuelle Rechner

• mailout.lrz-muenchen.de (mit Alias mailhost.lrz-muenchen.de)

wird dynamisch auf mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de abgebildet. Aus der Sicht der Mailserver im MHN werden mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de für ankommende/empfangene E-Mails genutzt (MX-Records im DNS), während mailout.lrz-muenchen.de von den Mailclients und Mailservern als Forwarder genutzt wird, d.h. also für abgehende/gesendete E-Mails.

Die Regeln und Konfigurationseinstellungen für die zentralen Mailrelays des LRZ sind in 3 Teile gegliedert:

• Empfang von E-Mails
• Verarbeitung von E-Mails
• Versand von E-Mails

Dabei sind die Begriffe Empfang und Versand von E-Mails immer aus der Sicht der Mailrelays beschrieben. Das bedeutet, egal ob eine E-Mail von einem Mailserver oder -client aus dem Internet empfangen oder in selbiges geschickt wird, muss die E-Mail grundsätzlich zuerst auf dem Mailrelay empfangen, dann verarbeitet und anschließend wiederum versand werden, sofern die Mailrelays bei der Übertragung der E-Mail eine Rolle spielen.

Jede Regel oder Konfigurationseinstellung wird durch eine Policy beschrieben. Jede Policy ist in mehrere Punkte gegliedert:

• Ziel: Was soll mit dieser Policy erreicht werden (Kurzfassung).
• Zielgruppe: Wen betrifft diese Policy besonders, hauptsächlich Administratoren von anderen Mailservern, oder jeden einzelnen unserer Kunden selbst.
• Beschreibung: Was soll mit dieser Policy erreicht werden (Langfassung)? Wie sieht die Implementation aus, welche Algorithmen werden verwendet.
• Auswirkungen: Welche Auswirkungen hat diese Policy auf die Zielgruppe, welche Aktionen muss die Zielgruppe durchführen.
• Gültig ab: Ab welchem Zeitpunkt tritt die Policy in Kraft.
• Konfiguration: Welche Softwareteile (Daemonen) der Mailrelays sind betroffen, wie sehen die entsprechenden Optionen aus und wo sind die Konfigurationsdaten zu finden. Dieser Teil ist nur für Administratoren interessant, die dasselbe Produkt Mail*Hub etc. von Syntegra (ehemals Control Data Systems, Inc.) einsetzen.

Empfang von E-Mails

Allgemeines

Dieser Abschnitt beschreibt die Policies, die den Empfang von E-Mails durch die Mailrelays des LRZ beeinflussen. Dies betrifft wie oben schon erwähnt sowohl E-Mails von Mailservern aus dem Internet als auch von Mailservern aus dem MWN. Durch spezielle Regeln werden diese beiden Gruppen aber unterschiedlich behandelt.

Geordnet sind die Policies nach den einzelnen Schritten im Ablauf der Übertragung einer E-Mail von einem Rechner auf den anderen:

• Aufbau der TCP/IP-Verbindung
• Aufbau der auf die TCP/IP-Verbindung aufsetzenden SMTP- bzw. ESMTP-Verbindung (Austausch des Protokollelements HELO bzw. EHLO)
• Übertragung einer oder mehrerer E-Mails, wobei sich diese jeweils wiederum in 3 Teile aufteilt:
• • Absender der E-Mail (Originator, Protokollelement Mail From)
  • ein oder mehrere Empfänger (Recipient, Protokollelement RCPT To)
  • Übertragung des eigentlichen Inhalts der E-Mail (Protokollelement Data)

Absender und Empfänger aus dem SMTP- bzw. ESMTP-Protokoll werden auch als der Umschlag der E-Mail bezeichnet. Diese sind nicht mit dem Absender und den Empfängern aus dem ersten Teil des Inhalts der E-Mail, dem sogenannten Header zu verwechseln. Diese Adressen können ganz andere sein.

Zum Schluss werden die Policies aufgeführt, auf die sich andere Policies abstützen.

Vertrauenswürdige Mailserver

Ziel

Ist ein Rechner ein vertrauenswürdiger Mailserver, so betrachten die zentralen Mailrelays diesen Rechner als einen ihrer Kunden. Für diese Rechner gelten daher andere Regeln beim Empfang und Versand von E-Mail als bei einem Rechner, der nicht zu den vertrauenswürdigen Mailservern gehört.

Zielgruppe

alle

Beschreibung

Um eine E-Mail über eines der zentralen Mailrelays des LRZ zu schicken, baut ein Mailserver zuerst eine TCP/IP-Verbindung zu einem der Mailrelays auf. Dabei wird unter anderem die IP-Adresse des sendenden Mailservers an den MTA auf dem Mailrelay übergeben. Für diese IP-Adresse versucht das Mailrelay mit einer Reverse Mapping Abfrage beim DNS den zugehörigen Domainnamen herauszubekommen.

Ist der entsprechende Nameserver nicht erreichbar (errno=146, h_errno=2) bzw. tritt ein anderer temporärer Fehler bei der DNS-Abfrage auf, so kann nicht entschieden werden, ob der Mailserver zu den vertrauenswürdigen Servern gehört oder nicht. Aus diesem Grund wird die TCP/IP-Verbindung zurückgewiesen.

Bei Erfolg wird der Domainname, ansonsten die IP-Adresse in der untenstehenden Tabelle gesucht. Wird sie gefunden, so gehört der Rechner zu den vertrauenswürdigen Mailservern. Ein '*' in der Tabelle bedeutet, dass alle Subdomains bzw. alle Rechner aus diesem Netz vertrauenswürdig sind.

Auswirkungen

Die Eigenschaft vertrauenswürdiger Mailserver wird von einer Reihe anderer Policies benutzt, um zu entscheiden, welche Teilregel beim Empfang von Mails anzuwenden ist:

• Relay-Blocking

Gültig ab

02.11.1998

Konfiguration

SMTPlistener: Option -T
X.500: Objectclass cdsSMTPDomainInfo, Attribute trustedSMTPDomains

Größe einer Mail

Ziel

E-Mails werden nur bis zu einer Größe von 30 MByte (31.457.280 Bytes) angenommen. Dies gilt aus der Sicht eines Mailclients oder -servers sowohl für den Empfang als auch für den Versand von E-Mails.

Zielgruppe

alle

Beschreibung

Die Einschränkung der Größe der übertragenen E-Mails hat sich aus zwei Gründen als notwendig erwiesen:

• Die Protokolle SMTP bzw. ESMTP sind keine Filetransferprotokolle wie z.B. FTP, da sie nicht für die Übertragung großer Datenmengen optimiert sind. Kommt es bei einer Übertragung zusätzlich noch zu Verbindungsabbrüchen, so gibt es keinen Mechanismus, um bei einem erneuten Verbindungsaufbau die Übertragung an der Stelle beginnen zu lassen, wo sie beim Abbruch der Verbindung geendet hat. Somit müssen alle Daten von neuem übertragen werden.
• Es kommt immer wieder vor, dass ein Programm 'Amok' läuft und sehr große Mailfiles (z.B. Logfiles) erzeugt, die dann oft noch an eine Reihe von Personen geschickt werden. Oder jemand stößt, ohne sich dessen bewusst zu sein, die Übertragung einer sehr großen Datei an.

Diese Probleme führten in der Vergangenheit immer wieder dazu, dass die Ressourcen der beteiligten Mailserver bis an die Grenze beansprucht wurden, und es zu Problemen beim Austausch regulärer E-Mails kam.

Bei der Überprüfung der Nachrichtengröße sind zwei Fälle zu unterscheiden:

• Der sendende Mailserver benutzt das Protokoll ESMTP. In diesem Fall schickt das Mailrelay als Antwort auf den Verbindungsaufbau (Protokollelement EHLO) den Parameter size und die Angabe 31457280 zurück. Der sendende Mailclient oder -server weiß dann, ob die E-Mail von der Größe her übertragen werden kann oder nicht. Sollte sie zu groß sein, generiert er eine Fehlermeldung an den Absender der E-Mail.
• Der sendende Mailclient/-server hält sich nicht an obiges Verfahren und versucht die E-Mail trotzdem zu übertragen oder er verwendet das Protokoll SMTP. In diesem Fall schickt das Mailrelay, sobald die E-Mail die Größe von 31.457.280 Bytes überschreitet, die Fehlermeldung
• 
  552 message size exceeds maximum message size
  und bricht die TCP/IP-Verbindung ab.

Die relevante Größe ist die Bruttogröße, d.h. die E-Mail mit der Transfer-Kodierung. Das bedeutet bei der Verwendung der Transfer-Kodierung BASE64, die in der Regel für Attachments verwendet wird, dass die Netto-Größe bei ca. 22,5 MByte liegt.

Auswirkungen

Es können über die zentralen Mailrelays keine E-Mails größer als 30 MByte gesendet oder empfangen werden. Größere E-Mails müssen auf mehrere E-Mails aufgeteilt werden.

Gültig ab

02.11.1998

Konfiguration

SMTPresponder: Option -S 31457280

Korrekte Syntax der Absende- und Empfangsadressen

Ziel

• Zurückweisung von E-Mails, die nach dem Eintreffen am Zielrechner nicht zugestellt werden könnten, wegen der syntaktisch falschen Empfangsadresse.
• Zurückweisung von E-Mails, an die keine Fehlermeldungen zurückgeschickt werden könnten, wegen der syntaktisch falschen Absendeadresse.

Zielgruppe

alle

Beschreibung

Es wird die Syntax der Adressen in den SMTP-Protokoll-Elementen MAIL FROM und RCPT TO überprüft. Dabei gelten die Regeln aus den Standards RFC 821, RFC 952 und RFC 1123, mit folgenden Ausnahmen:

• Blanks in einer Adresse werden nur akzeptiert wenn sie in '"' eingeschlossen werden.
• Eine Adresse muss laut RFC 821 immer in die Zeichen '<' und '>' eingeschlossen sein. Fehlt jedoch eines oder beide dieser Zeichen, wird die Adresse dennoch akzeptiert.
• Das Zeichen '<' innerhalb einer Adresse muss in '"' eingeschlossen sein.
• Fehlt das Zeichen '<' am Anfang und gibt es dafür eines mitten in der Adresse, so werden die Zeichen vor dem '<' ignoriert und der Rest als Adresse hergenommen.
• Die Zeichen + _ * $ & im Domainnamen der Adresse werden akzeptiert, wenn sie nicht am Anfang oder Ende stehen.

Die häufigsten syntaktischen Fehler sind

• Blanks in einer Mailadresse, insbesondere anstatt eines '.' oder vor/nach einem '.'
• das Zeichen '.' am Ende des linken Teils der Adresse direkt vor dem Zeichen '@'
• '.-' oder '-.' in der Domain
• Umlaut in der Adresse
• Teile, die der Adresse vorangestellt werden, aber nicht dazu gehören, wie SMTP:adresse oder mailto:adresse

Auswirkungen

Es wird so früh wie möglich eine Fehlermeldung generiert und zwar vom sendenden Mailserver. Dabei geht eine Kopie an den Postmaster des sendenden Rechners oder die Fehlermeldung landet direkt beim Absender. Damit hat der Absender viel schneller eine Reaktion und es kann ihm durch den Postmaster vor Ort viel eher geholfen werden.

Wird eine Mail mit syntaktisch falscher Absendeadresse erst angenommen und kann dann wegen einer falschen Empfangsadresse nicht weitergeleitet werden, so kann an den Absender keine Fehlermeldung geschickt werden. Solche Fehlermeldungen landen in einer speziellen Queue auf den zentralen Mailrelays und müssen manuell bearbeitet werden.

Gültig ab

02.11.1998

Konfiguration

SMTPresponder: Option -A

Relay-Blocking

Ziel

Mit dieser Policy soll der Missbrauch der zentralen Mailrelays des LRZ als Relay, insbesondere als Spam-Relay, ausgeschaltet werden.

Zielgruppe

alle

Beschreibung

Gehört ein Mailserver nicht zu den in der Policy Vertrauenswürdige Mailserver festgelegten Mailservern, dann wird eine E-Mail von den zentralen Mailrelays nur entgegengenommen, wenn Sie an Empfänger im Münchner Hochschulnetz adressiert ist, d.h. die Domain der Empfangsadresse muss zu den akzeptierten Maildomains gehören.

Überprüft wird die Adresse in jedem Protokoll-Element RCPT-To. Ist die Domain der Adresse eine der akzeptierten Maildomains, so wird die Mail akzeptiert. Ist sie dies nicht, so wird die Mail für diesen einen Empfänger mit der Fehlermeldung

551 Relay request denied

abgelehnt. Diese Überprüfung wird für jeden Empfänger der E-Mail durchgeführt. Wird keiner der Empfänger akzeptiert, so wird das Protokoll-Element Data, d.h. der Wunsch nun den Inhalt (Content) der E-Mail zu übertragen mit der Fehlermeldung

503 No valid recipients specified

abgelehnt.

Auswirkungen

Kunden, die über einen anderen Internet Service Provider (ISP) eine Verbindung zum Internet aufbauen - sie befinden sich damit ausserhalb des MHN -, können die zentralen Mailrelays des LRZ nicht mehr für den Versand von E-Mail ins Internet benutzen. Sie müssen in diesem Fall die Mailrelays ihres ISPs verwenden.

Dies betrifft insbesondere diejenigen, die Wählzugänge anderer ISPs oder die Einwahlmöglichkeiten der Bürgernetze verwenden. Aber auch Studenten und Mitarbeiter aus dem Bereich des MHN, die als Gast an einer anderen Hochschule/Universität weilen und weiterhin die Mailrelays des LRZ benutzt haben, müssen ihren Rechner, z.B. Notebook, umkonfigurieren.

Gültig ab

02.11.1998

Konfiguration

SMTPresponder: Option -D ohne Angabe einer Domain
X.500: Objectclass cdsIntraStoreMTA, Attribute servicedSMTPDomains

Akzeptierte Maildomains

Ziel

Die akzeptierte Maildomains sind die Domains im MHN für die die zentralen Mailrelays des LRZ E-Mails entgegennehmen.

Zielgruppe

alle

Beschreibung

Ist die Domain einer Mailadresse in der Tabelle enthalten oder ist sie eine Subdomain einer Domain in der Tabelle, so gehört sie zu den akzeptierten Maildomains.

Auswirkungen

Die Eigenschaft akzeptierte Maildomain wird von einer Reihe anderer Policies benutzt, um zu entscheiden, welche Teilregel beim Empfang von Mails anzuwenden ist:

• Relay-Blocking

Gültig ab

02.11.1998

Konfiguration

SMTPresponder: Option -D mit Domain oder ohne Domain mit X.500-Eintrag
X.500: Objectclass cdsIntraStoreMTA, Attribute servicedSMTPDomains

Verarbeitung von E-Mails

Allgemeines

Dieser Abschnitt beschreibt die Policies, die die Verarbeitung von E-Mails durch die Mailrelays des LRZ beeinflussen.

Blockade von E-Mails mit ausführbaren Attachments

Ziel

Vermeidung von Infektionsgefahr durch Viren und/oder Würmer, die sich selbständig als ausführbares Attachment (Anlagedatei) versenden oder ein ausführbares Attachment befallen haben.

Zielgruppe

Alle Personen, deren E-Mails explizit oder implizit bei Empfang oder Versand über die Mailrelays des LRZ geleitet werden. Dies betrifft daher alle Personen:

• die ihre Mailbox auf LRZ-Systemen haben.
• die mailout.lrz-muenchen.de zum Versand benutzen.
• auf lokalen Mailsystemen, deren E-Mails beim Empfang per MX-Record über die Mailrelays geleitet werden.
• auf lokalen Mailsystemen, die zum Versenden von E-Mails die Mailrelays als Forwarder eingetragen haben.

Beschreibung

Seit dem ersten Auftreten eines sich massenhaft selbst ausbreitenden Virus (Melissa) im März 1999 ist eine stete Zunahme an E-Mail-Viren zu beobachten. Inzwischen enthält an den LRZ-Mailrelays jede 4. bis 5. E-Mail, die ein ausführbares Attachment transportiert, einen Virus bzw. einen Wurm. Dies ist vor allem bedingt durch die zunehmende Verwendung der 'Viren Construction Kits', die es nahezu jedem erlauben auf einfachste Weise einen Virus zu erstellen.

Bei großen Viren-Ausbrüchen verbreiten sich diese Viren innerhalb weniger Stunden weltweit. Bis der neue Virus von den Herstellern von Anti-Viren-Software analysiert, neue Signaturen erstellt, diese verteilt und in die Software eingespielt sind, vergehen nach unseren Erfahrungen auch in günstigen Fällen zwischen 12 und 36 Stunden.

Obwohl es bei solchen Viren-Ausbrüchen ein entsprechend großes Medienecho gegeben hat und eigentlich jeder E-Mail-Nutzer sich der Gefahr eines sorglosen Anklickens eines Attachments bewusst sein sollte, kommt es laufend zu Infektionen der PCs unserer Nutzer, die von diesen nur mit großem Aufwand wieder zu bereinigen sind.

Deshalb hat sich das LRZ entschlossen neben der Bereitstellung des Virenscanners von Sophos eine zweite Schutzlinie durch die Blockade von ausführbaren Attachments zu ziehen (s.a. Artikel in den Mitteilungen des LRZ vom Juni 2001). Zusätzlich soll zu einem späteren Zeitpunkt auch ein Virenscanner in das Mailsystem auf den Mailrelays integriert werden, damit an zentraler Stelle mit den aktuellsten Virensignaturen gescannt werden kann.

Als ausführbares Attachment wird ein Attachment bezeichnet, dessen Dateiname eine bestimmte Endung aufweist. Anhand dieser Endung weiß ein Mail User Agent, dass das Windows-Betriebssystem in der Lage ist, diese Datei direkt auszufühen, d.h. dass das Attachment ein Programm und keine beliebige Datei ist.

Mails, die Attachments mit einer der folgenden Endungen haben, werden zurückgeschickt:

Endung	Beschreibung
.ade	Microsoft Access Project Extension
.adp	Microsoft Access Project
.bas	Visual Basic® Class Module
.bat	Batch File
.chm	Compiled HTML Help Files
.cmd	Windows NT® Command Script
.com	MS-DOS® Application
.cpl	Control Panel Extension
.crt	Security Certificate
.dll	Dynamic Link Library
.exe	Directly executable program
.hlp	Windows® Help File
.hta	HTML Application
.inf	Setup Information File
.ins	Internet Setup File
.isp	Internet Communication Settings
.js	JScript® File
.jse	JScript® Encoded Script File
.lnk	Link Shortcut
.mdb	Microsoft Access Application
.mde	Microsoft Access MDE Database
.msc	Microsoft Common Console Document
.msi	Windows Installer Package
.msp	Windows Installer Patch
.mst	Visual Test Source File
.ocx	OLE custom control
.pcd	Photo CD Image
.pif	Program Information File, Shortcut to MS-DOS Program
.reg	Registration Entries
.scr	Screen Saver
.sct	Windows Script Component
.shs	Shell Scrap Object
.url	Internet Shortcut (Uniform Resource Locator)
.vb	VBScript File
.vbe	VBScript Encoded Script File
.vbs	VBScript Script File
.wsc	Windows Script Component
.wsf	Windows Script File
.wsh	Windows Scripting Host Settings File

Diese Tabelle beruht im wesentlichen auf der Tabelle aus Outlook E-mail Security Update - Frequently Asked Questions von Microsoft.

ACHTUNG: Infizierte Dokumente, das können z.B. MS-Word- (.doc), Excel- (.xls) oder HTML-Dateien (.htm, .html) sein, werden nicht blockiert, sondern weiterhin durchgelassen. Es ist also auch in Zukunft notwendig mit jeder Art von Attachment vorsichtig umzugehen!

Entdeckt der Filter auf den Mailrelays bei einem Attachment einem Dateinamen mit einer entsprechenden Endung, so wird die E-Mail nicht weitergeleitet, sondern an den Absender zurückgeschickt. Der Absender erhält die Fehlermeldung:

Your message was not delivered to the following recipients:

                E-MAIL-ADRESSE: Email rejected

  Attachment FILENAME could contain a virus. To resend the
  attachment, rename the file extension or put the file into an archive.
  More information can be found at

     http://www.lrz-muenchen.de/services/netzdienste/email/block_en/

  or obtained by sending an email to

     attachment-blockade@lrz.de

  (no need for subject or body).

  ------------------------------------------------------------------

  Die E-Mail wurde zurueckgewiesen und nicht an den Empfaenger
  ausgeliefert, da die Anlage DATEINAME ein Virus enthalten
  koennte. Aendern Sie die Endung des Dateinamens oder verpacken
  Sie die E-Mail in ein Archiv, bevor Sie sie erneut versenden.
  Mehr Informationen finden Sie unter

     http://www.lrz-muenchen.de/services/netzdienste/email/block_de/

  oder erhalten Sie, wenn Sie eine E-Mail an

     anlage-blockade@lrz.de

  schicken (ohne Betreff, ohne Inhalt).

  ------------------------------------------------------------------

Auswirkungen

Es können keine ausführbaren Attachments mehr verschickt bzw. empfangen werden. Dadurch wird aber auch die Ausbreitung und Infektionsgefahr durch sich selbst versendende Viren wesentlich vermindert.

Um die Blockade zu umgehen, muss das Attachment so verschickt werden, dass es vom Empfänger nicht mehr automatisch durch einen einfachen Klick ausgeführt werden kann, d.h. es muss händisch eingegriffen werden.

ACHTUNG: ausführbare Dateien (sie haben meistens die Endung .exe), die mit einem Virus infiziert sind, werden dadurch wieder übertragen !!!

Als Möglichkeiten bieten sich an:

• Änderung der Endung des Dateinamens, sodass es sowohl vom Filter als auch vom MUA (Mail User Agent = Mailprogramm) nicht mehr als ausführbar erkannt wird. Der Empfänger muss das Attachment mit der richtigen Endung abspeichern und kann es dann ausführen.
• Attachment komprimieren und in ein Archiv stecken, z.B. mit dem frei erhältlichen PowerArchiver. Dabei aber darauf achten, dass man kein sich selbst entpackendes Archiv erzeugt, da so ein Attachment die Endung .exe hätte und daher wiederum abgewiesen würde. Der Empfänger muss das Archiv-Attachment abspeichern, entpacken und kann dann das urspüngliche Objekt ausführen.

Gültig ab

26.06.2001

Konfiguration

Perlprogramm basierend auf messageFilter von Syntegra

Ausfilterung von E-Mails mit Viren behafteten Attachments (provisorische Lösung)

Ziel

Vermeidung der Einschleppung von Viren/Würmern ins MWN.

Zielgruppe

Alle Personen, deren E-Mails explizit oder implizit bei Empfang oder Versand über die Mailrelays des LRZ geleitet werden. Dies betrifft daher alle Personen,

• die ihre Mailbox auf LRZ-Systemen haben,
• die mailout.lrz-muenchen.de zum Versand benutzen,
• die ein lokales Mailsystem nutzen, dessen E-Mails beim Empfang aus dem Internet per MX-Record über die Mailrelays geleitet werden,
• die ein lokales Mailsystem nutzen, das zum Versenden von E-Mails die Mailrelays als Forwarder eingetragen hat.

Beschreibung

Seit Ende Januar 2004 und dem Auftreten des MyDoom-Wurms hat die Verbreitung von Viren und Würmern über E-Mail eine neue Dimension erreicht: Einerseits nahm die Anzahl der Schädlinge dramatisch zu und andererseits verbreiten sich diese nicht mehr nur über (unter Windows) ausführbare Attachments, sondern zunehmend auch über zip-Attachments. Damit reichte die bisher an den Mailrelays vorgenommene Blockade von E-Mails mit ausführbaren Attachments nicht mehr aus.

Leider kam diese Zuspitzung der Virensituation zu einem für uns sehr ungünstigen Zeitpunkt: Die Integration der Antiviren-Software von Sophos in die Mailrelay-Software von Syntegra, die eigentlich längst hätte fertiggestellt sein sollen, verzögerte sich nämlich wegen rechtlicher Unklarheiten immer weiter (wir erwarten das fertige Produkt nunmehr in der zweiten Jahreshälfte 2004). Wir mussten aber handeln um eine Überschwemmung des MWN mit den neuen zip-Würmern zu verhindern und haben uns für folgende provisorische Lösung entschieden:

• Alle E-Mails mit (unter Windows) ausführbaren Attachments sowie alle E-Mails mit zip-Attachments werden an einen speziellen Rechner weitergeleitet und dort mit Sophos auf Viren/Würmer untersucht. E-Mails, bei denen ein Schädling erkannt wird, werden zur Sicherheit noch eine Woche aufbewahrt und dann weggeworfen. Alle anderen E-Mails werden an die Mailrelays zurückgesandt und dort weiterverarbeitet.
• Bei E-Mails, bei denen ein Virus/Wurm erkannt wird und die deshalb ausgefiltert werden, erfolgt weder eine Benachrichtigung des Absenders noch des Empfängers.

Die Nicht-Benachrichtigung von Absender und Empfänger wird aus folgenden Gründen für sinnvoll und gerechtfertigt gehalten:

• Bei den bisher bekannten Schädlingen, die sich über ausführbare bzw. zip-Attachments von E-Mails verbreiten, handelt es sich um Würmer, die keinerlei Nutzinformationen haben (im Unterschied etwa zu Word- oder Excel-Dokumenten, die von Makroviren befallen sind). Das gesamte Attachment besteht ausschließlich aus Informationen, die der Wurm zu seiner Aktivierung und Verbreitung benötigt.
• Da nur E-Mails mit solchen Attachments untersucht werden, kann man mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass es sich bei infizierten E-Mails um Würmer handelt, also - wie gesagt - um E-Mails ohne jegliche Nutzinformationen (diese Aussage wird durch die Logfiles, denen man Art und Anzahl der ausgefilterten Schädlinge entnehmen kann, voll und ganz untermauert).
• Daher macht eine Benachrichtigung der Empfänger keinen Sinn. Man erspart den Adressaten der Wurm-Mails vielmehr eine Flut von Info-Mails, die im besten Fall lästig, für unbedarftere Benutzer möglicherweise auch irritierend oder beunruhigend sind.
• Auch eine Benachrichtigung des Absenders macht keinen Sinn, da bei Wurm-Mails die Absendeadressen gefälscht sind und daher den Falschen erreichen würden (nicht den Inhaber des infizierten Rechners).

Noch ein paar Erläuterungen zur derzeit praktizierten Viren-Filterung:

• E-Mails mit anderen Attachment-Typen als den oben genannten werden nicht auf Viren untersucht. Es ist also durchaus möglich, dass infizierte Word- oder Excel-Dokumente ausgeliefert werden, und es ist deshalb unbedingt zu empfehlen auch auf dem lokalen Rechner ein Antivirus-Programm (wie z.B. Sophos) einzusetzen.
• E-Mails mit ausführbaren Attachments werden auf keinen Fall ausgeliefert. Falls sie die Viren-Prüfung passieren, werden sie von der Attachment-Blockade abgewiesen. In diesem Fall erhält allerdings der Absender eine entsprechende Meldung. Der Grund für die generelle Blockade ist, dass zwischen dem Auftreten eines Virus/Wurms und der Bereitstellung einer entsprechenden Signatur durch Sophos ohne weiteres 24 Stunden vergehen können. Und der Grund dafür, dass diese E-Mails trotzdem zuvor einer Viren-Prüfung unterzogen werden, ist, dass dadurch das Verschicken unzähliger Fehlermeldungen an gefälschte Absendeadressen vermieden wird (siehe oben).
  E-Mails mit zip-Attachments werden hingegen durchgelassen, wenn sie die Viren-Prüfung passieren konnten. D.h. es kann vorkommen, dass Würmer in zip-Attachments ausgeliefert werden aufgrund der angesprochenen Zeitverzögerung bei den Signaturen.

Die derzeitige Vorgehensweise stellt - wie bereits gesagt - eine provisorische Lösung dar. Für die Zukunft ist geplant alle E-Mails einer Viren-Prüfung zu unterziehen und im Zuge dessen wird auch das Thema Benachrichtigung des Absenders bzw. Empfängers nochmals neu zu überdenken sein.

Schließlich noch zwei Zahlen: Derzeit (Mitte Juni 2004) werden montags bis freitags täglich durchschnittlich ca. 45.000 Wurm-Mails und samstags/sonntags täglich ca. 30.000 Wurm-Mails aussortiert.

Auswirkungen

E-Mails mit ausführbaren bzw. zip-Attachments, bei denen Sophos einen Virus/Wurm erkennt, werden ausgefiltert und nicht zugestellt.

Gültig ab

14.06.2004 (testweise seit Mitte März 2004)

Konfiguration

Sophos-Antivirus in Verbindung mit amavisd-new

Versand von E-Mails

Allgemeines

Dieser Abschnitt beschreibt die Policies, die den Versand von E-Mails durch die Mailrelays des LRZ beeinflussen. Die Beschreibung der entsprechenden Policies erfolgt zu einem späteren Zeitpunkt.

Zusätzliche Policies

Allgemeines

Diese Policies sind keine direkten Policies der zentralen Mailrelays des LRZ, stehen aber in einem Zusammenhang mit diesen und sind aus diesem Grund hier aufgeführt.

Sperrung von Port 25 am Eingang ins MHN

Ziel

Es soll für alle Mailserver im MHN verhindert werden, dass diese als Relay für Spam-Mails missbraucht werden können.

Zielgruppe

Administratoren der Mailserver im MHN

Beschreibung

Es wird der SMTP-Port 25 am Brouter zwischen MHN und Internet für SMTP-Verbindungen vom Internet ins MHN gesperrt. Damit sind die Mailserver des MHN nicht mehr direkt aus dem Internet erreichbar und können damit nicht mehr als Relay missbraucht werden. Dadurch ist es nicht mehr so dringend sofort jeden einzelnen Mailserver selbst mit der neusten Mailsoftware zu versehen, die das Unterbinden des Relayings erlaubt.

Dadurch ist auch die Gefahr gebannt, dass der Ruf der Einrichtungen im MHN durch das Fehlverhalten einzelner Rechner geschädigt wird und die jeweilige gesamte Domain auf eine 'blacklist' kommt, womit der Austausch von E-Mails empfindlich gestört wäre.

Auswirkung

Damit weiterhin E-Mails mit dem Internet ausgetauscht werden können, gibt es eine Reihe von Mailrelays, die weiterhin E-Mails direkt aus dem Internet empfangen können.
Über diese Mailrelays, wie z.B. mailrelay1.lrz-muenchen.de und mailrelay2.lrz-muenchen.de, müssen die E-Mails an andere Mailserver im MHN geleitet werden. Was dazu zu tun ist und welche Mailrelays existieren, ist in Konfiguration für Mailempfang aus dem Internet beschrieben.

Gültig ab

16.11.1998

Konfiguration

Am Interface KR-LRZ-Muenchen1.lrz-muenchen.de (188.1.8.22) des Brouters  browan.lrz-muenchen.de wird ein Filter auf Port 25 für hereinkommende SMTP-Verbindungen gesetzt, der nur für die ausgewählten Mailrelays Verbindungen durchlässt.