[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AGLinux New Media AG

Mailregeln

Mailregeln

In Zeiten des unsäglichen Spammer-Unwesens versuchen wir die Belastung mit unnötigen Mails zu minimieren. Deshalb werden grundsätzlich nur "harmlose" Mails überhaupt angenommen. Die folgenden Abschnitte beschreiben die verschiedenen Filterregeln.

Content-Type Filter

Dazu zählen konkret Mails mit den folgenden MIME-Content-Types:

text/plain
ganz normale herkömmliche Textemails
multipart/signed und multipart/encrypted
um signierte bzw. verschlüsselte Mails zuzulassen
multipart/mixed
um mehrteilige (Text-)Mails zu erlauben
multipart/report und message/delivery-status
um Delivery Status Notifications (Bounces, etc.) durchzulassen - siehe auch RFC 3464.
message/rfc822
um angehängte (Text-)Emails zuzulassen

Filter auf die Email-Größe

Für Mailinglisten und Kontaktadressen (siehe auch RFC2542), die auch alle über Mailinglisten realisiert sind, gilt ein 40kB Größenlimit. Wenn größere Files über eine Mailingliste "verteilt" werden sollen, so ist das große File per URL zugänglich zu machen und der URL zu verschicken. Das ist für die Empfänger und v.a. deren Mailbox (die meist eine endliche Größe hat) harmloser, einen URL in einer Mail zu bekommen, der das upgeloadete große File enthält. Zusätzlich landet die Mail sowieso in einem Archiv am Web, sodaß das File dort noch einmal Platz verschwenden würde.

Echte Spam-Filter

Mails, die der SpamAssassin mit 5 oder mehr Score bewertet, werden ebenfalls nicht angenommen. Der SpamAssassin ist im wesentlichen mit Default-Regeln konfiguriert, allerdings werden MSFT-Executables mit 5 Schlechtpunkten belohnt und die Würmer der jüngeren Vergangenheit haben auch hier ihre Spuren hinterlassen.

Ebenso sind im Moment einige wenige Blacklists wie Spamhaus und Spam Prevention Early Warning System im Einsatz.

Vacation-Messages (oder auch auf neu-deutsch:"Abwesenheitsnotizen")

Es ist nett und zweckmäßig, wenn Bekannte und/oder Geschäftspartner eine freundliche und persönliche Mail bekommen, daß man gerade im Urlaub auf den Malediven weilt und am x.y. wieder zurück ist und dann geruht, die Email zu lesen.

Es ist nicht unbedingt nett und gar nicht zweckmäßig, wenn man diesem Umstand über eine Mailingliste (die nebenbei noch archiviert wird) oder auch direkt persönlich ziemlich unbekannten Menschen mitteilt - und das noch auf jede einzelne Email.

Das geht von unnötigem Mailverkehr und Platzverbrauch im Archiv über sinnlosen Aufwand bei ein paar hundert Mailinglistenteilnehmern ein "ich bin im Urlaub-"Email eines relativ Unbekannten löschen zu müssen bis zu der Tatsache, daß dann weltweit jeder den Archiveintrag in Google wieder finden kann. Abgesehen davon ist es bei typischen Mailinglisten-Emails auch ziemlich egal, ob man sie gleich liest oder erst nach der Rückkehr in 3 Wochen - entweder das Problem ist gelöst, dann kann man sich an der Lösung miterfreuen, oder es ist immer noch nicht gelöst, dann hat man nichts wesentliches versäumt.

Besonders unnötig wird die Angelegenheit, wenn diese unnötigen Emails als Antwort auf jede Email in die Welt gesetzet werden.

Rein technisch ist das Problem einfach gelöst: Die Emails über die Mailingliste gehen mit einem Precedence: bulk Header raus. Auf solche Emails sollten automatische Tools gar nicht antworten (wie es z.B. das normale Unix- vacation Programm macht). D.h. daß man in seinem Mailsystem eben jenen Header entsprechend beachten soll.

Sollte diese nicht möglich oder wünschenswert sein, kann man für die Dauer der Abwesenheit auch von der bzw. den Mailinglisten unsubskribieren und nachher wieder subskribieren.

Als letzte Instanz springen (spätestens) bei Beschwerden Anderer über ebensolche Emails die Listenadministratoren beim Unsubskribieren helfend ein. Das Subskribieren ist auf jeden Fall wieder selber durchzuführen.


powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Mrz 2012