Grundsätzlich hat jeder Inhaber eines aktiven POSIX-Account am IBR auch einen gleichnamigen EMail-Account am IBR. Die EMail-Adresse setzt sich stets aus dem Account-Namen und dem Domainnamen des IBR zusammen, z.B. steinb@ibr.cs.tu-bs.de. (In einzelnen Fällen werden für Mitarbeiter:innen auch Aliase vergeben.) Jede:r Benutzer:in ist angehalten die empfangene EMail regelmäßig zu lesen und zu bearbeiten, so dass die Kommunikation für Betreuer:innen bzw. Kolleg:innen zuverlässig gewährleistet ist. Statt des regelmäßgen Abrufens der Mail aus dem IBR können Benutzer:innen sich auch eine Weiterleitung selbst einrichten, s.u.
Zu sendende (Outgoing) EMail kann per SMTP über den "Submission" TCP-Port 587 (nicht über Port 25!) an den Mailserver des IBR übergeben werden. Dieser ist unter dem Namen mail.ibr.cs.tu-bs.de per IPv4 und IPv6 erreichbar. Mit STARTTLS muss die Verbindung verschlüsselt werden und zum Schutz vor Spam-Verteilung (Open Relaying) ist eine Authentisierung mit dem IBR Account-Namen erforderlich. Hier ist eine einfache Passwortverwendung okay, da dies über TLS verschlüsselt übertragen wird. Kerberos ist auch möglich, erfordert aber ggf. etwas mehr Konfigurationsarbeit.
Empfangene EMail wird auf dem Mailserver des IBR zunächst durch verschiedene Software-Komponenten (Amavis, ClamAV, SpamAssassin) klassifiziert, um sie ggf. als mutmaßliche Spam-
oder Viren-Nachrichten zu markieren, und anschließend im Falle von IBR-Empfangsadressen durch die Dovecot-Software verwaltet. Dieses Softwaresystem ermöglicht unter anderem auch eine Filterung, eine Eingruppierung in verschiedene persönliche Mailordner und eine Weiterleitung. All dies kann jede:r Benutzer:in selbst konfigurieren. Der Abruf der EMail erfolgt in der Regel durch IMAP (Port 143 mit STARTTLS, oder IMAPS über Port 993) ebenfalls vom Server mail.ibr.cs.tu-bs.de per IPv4 oder IPv6. Die Authentisierung erfolgt ebenfalls per Passwort oder ggf. Kerberos.
Der IBR-Maildienst ist (mit Ausnahmen) nur für die Verwendung von IBR-Mailadressen (...@ibr.cs.tu-bs.de) vorgesehen. Wer dennoch Mails mit anderen Adressen versenden will, sollte sich in Zeiten von SPF und Co. über die Konsequenzen im Klaren sein oder lieber den für die jeweilige Adresse richtigen SMTP-Server zum Versenden verwenden.
Wer die empfangene IBR-EMail nicht regelmäßig vom Server des IBR abrufen möchte, kann sie auch an eine andere Adresse weiterleiten lassen. Dies geschieht durch eine spezielle Anweisung im Sieve Script, s.u.
Noch einfacher ist eine komplette Weiterleitung aller Mails an eine in $HOME/.forward angegebene Adresse.
Es wird jedoch dringend darauf hingewiesen, dass dienstliche Mail ausschließlich TU-intern behandelt werden darf und eine Weiterleitung sich daher für Mitarbeiter:innen verbietet. Siehe: https://otrs.rz.tu-bs.de/external/knowledge-base/article/332
Auch Studierende sollten unbedingt auf Weiterleitungen außerhalb der TU Braunschweig verzichten. Eine Weiterleitung an den GITZ-Account ist hingegen okay.
Ehemalige Mitarbeiter:innen, die nach Schließung Ihres Accounts eine Ablehnung von Mails in ihre alte IBR-Adresse mit bestimmten Error-Codes (etwa mit Hinweis auf eine neuere Adresse) wünschen, können sich hierzu beim Admin melden.
Ein langfristige Weiterleitung von Mails für bereits geschlossene Accounts wird grundsätzlich nicht vorgenommen, da früher oder später auch die Weiterleitungsadresse nicht mehr stimmen wird.
Vom Mailserver empfangene EMails werden am IBR grundsätzlich nicht pauschal zentral gefiltert, sondern lediglich analysiert und mit Markierungen versehen, um alle Benutzer:innen individuell entscheiden zu lassen, wie diese Markierungen ggf. berücksichtigt werden sollen. Denkbar ist das Verwerfen von Mails ab einem bestimmten "Spam-Score" oder das Aussortieren in Spam-Ordner für eine spätere manuelle Begutachtung. Lediglich Mails deren Spam-Klassifizierung besonders deutlich ausfällt, wird vom Server gar nicht erst angenommen.
Neben dem Verwerfen oder Aussortieren können auch andere Aktionen, wie das erzeugen von automatischen Abwesenheitsantworten ("vacation"), als Aktionen erfolgen.
Die Filterung erfolgt durch Erstellen eines Sieve-Scriptes. Dieses Script kann als $HOME/.sieve/NAME.sieve abgelegt und mittels eines passenden Symlinks $HOME/.dovecot.sieve als aktives Script markiert werden. Alternativ kann die Verwaltung mittels des "ManageSieve" Protokolls vorgenommen werden. Manche Mailprogramme und auch unser Webmailer unterstützen dies.
Eine procmail-Konfiguration des Benutzers wird nicht berücksichtigt!
Das grundlegende Prinzip eines Sieve Scriptes ist es, die in Regeln enthaltenen Bedingungen auszuwerten und bei positivem Ergebnis eine dazugehörige Aktion auszuführen. Regeln sind meist Stringmuster für bestimmte Header-Zeilen. Typische Aktionen sind das Verwerfen von Mails im Falle von Spam, das Einsortieren in bestimmte Folder des Benutzers oder das Weiterleiten an eine andere (externe) EMail-Adresse. Durch die o.g. Markierung
auf dem IBR-Mailserver werden insbesondere die Header X-Amavis-Alert, X-Spam-Level und X-Spam-Status in Mails ergänzt. Selbstverständlich können auch andere Header in Sieve-Regeln ausgewertet werden.
Es folgen typische Beispiele für Sieve-Regeln:
# Die folgenden Zeilen deklarieren benutzte Kommandos; falls eine
# Erweiterungen im Skript nicht vorkommt, sollte die entsprechende Zeile
# auskommentiert werden.
require "envelope"; # envelope-Test
require "fileinto"; # fileinto-Kommando
require "reject"; # reject-Kommando
require "duplicate";
# Mehrfachempfang (z.B. über verschiedene Aliase) unterdrücken
if duplicate {
discard;
stop;
}
# Alle Mails verwerfen, die einen erkannten Virus enthalten.
if header :contains "X-Amavis-Alert" "INFECTED" {
fileinto "INBOX.Virus";
stop;
}
# Mail, die wahrscheinlich Spam ist, in einen eigenes Postfach ablegen.
# Dieses IMAP-Postfach muss zuvor erzeugt worden sein.
if header :matches "X-Spam-Status" "Yes*" {
fileinto "INBOX.Spam";
stop;
}
# Mail von einem unerwuenschten Absender ablehnen; dies erzeugt eine
# Meldung an den Absender, die den angegebenen Grund enthaelt.
if address :all :is "From" "offers@example.com" {
reject "Not interested.";
stop;
}
# Mail mit einem bestimmten String in der Subject-Zeile an einen anderen
# Account weiterleiten.
if header :contains "Subject" "[ADV]" {
redirect "advert@example.com";
stop;
}
# Auto-Response im Fall von Abwesenheit, derzeit auskommentiert
# Bitte den alleinstehenden Punkt am Ende des Textes (EOT) beachten.
#
#if header :contains "to" "my-name"
#{
# vacation :days 9 :addresses "my-name@ibr.cs.tu-bs.de" :subject #"Abwesenheitsnachricht" text:
#Vielen Dank für Ihre Email.
#
#Ich bin ab dem xx.xx.2024 wieder erreichbar. Die Email wird nicht #weitergeleitet. In dringenden Fällen wenden Sie sich bitte an xxx.
#
#Ich werde die Nachricht nach meiner Rückkehr umgehend bearbeiten.
#
#Freundliche Grüße
#xxx
#.
#;
#}
Wurde kein Sieve-Script erstellt und aktiviert, so greif ein Default-Script, das Spam und Viren in separate Ordner aussortiert.
Da die persönlichen Mailfolder im Home-Verzeichnis gespeichert werden (~/.maildir), ist die Größe lediglich durch die Größe bzw. Quota-Limits des Filesystems begrenzt. Wird dieses Limit erreicht, so werden Mails an den User abgelehnt. Das Erreichen des Limits ist also im eigenen Interesse unbedingt zu vermeiden.
Wenn einmal nicht der gewohnte Mailreader zur Verfügung steht, kann auch das webbasierte Roundcube benutzt werden. Dies dient jedoch ausdrücklich nur als "Notlösung".
Für Projekte oder andere Belange können am IBR Mailinglisten eingerichtet werden. Mailinglisten sind mehr als einfache Mailverteiler (Aliases). Jede Mailingliste hat (mindestens) einen "Owner", der die Mitglieder einer Liste verwaltet und das Verhalten der Liste bei Anmeldewünschen oder neuen Beiträgen konfiguriert. Mailman bietet hierzu sehr viele Möglichkeiten. Es ist Aufgabe jedes List-Owners sich hiermit vertraut zu machen. Insbesondere sind ggf. die Privacy- und Archivierungsoptionen anzupassen. Der Owner ist für jede Liste der erste Ansprechpartner, wenn es Fragen zu einer Liste gibt. Die Admins im IBR sind hingegen lediglich für den ordnungsgemäßen Betrieb des Mailinglistenservers verantwortlich, können aber ggf. auch in Belangen einzelner Listen vermitteln.
Für sämtliche im LDAP verwaltete Usergruppen gibt es implizit auch einen gleichnamigen Mail-Alias, beispielsweise mitarb@ibr.cs.tu-bs.de als Verteiler für alle Mitglieder der Gruppe mitarb. Weitere Aliase können auf Wunsch angelegt werden. Im Einzelfall ist zu überlegen, ob ein einfacher Alias, eine Gruppe oder eine Mailingliste am besten geeignet ist.
Der Mailserver setzt Software zur Erkennung und Abwehr von Spam und Viren ein. Dabei werden Viren und Mails, deren Spam-Wahrscheinlichkeit sehr hoch liegt, bereits während der SMTP-Kommunikation mit dem Server abgeleht. Ferner werden DNS-basierte Blocklisten verwendet, so dass bekannte Spam-Hosts und auch Hosts aus Dialup-Netzen ohne Authentisierung blockiert werden. Diese Maßnahmen führen zu einer erheblichen Reduzierung der Mails, die überhaupt vom Server gespeichert und verarbeitet werden müssen.
Alle Mitarbeiter:innen (und auf Wunsch in die Gruppe salearn aufgenommene Accounts) können mithelfen, die zentrale Spam-Erkennung mit eigenem Spam und Ham anzulernen, indem entsprechende Mails manuell in die persönlichen IMAP Folder INBOX.spamassassin.Learn Spam und INBOX.spamassassin.Learn Ham kopiert werden. Diese Folder werden regelmäßig (derzeit alle 30 Minuten) zum Anlernen durchsucht und nach erfolgter Übernahme in die SpamAssassin-Datenbank geleert. WICHTIG: Bitte nur manuell Spam anlernen, und auch nur in eindeutigen Fällen von unerwünschten Massenmails. Also beispielsweise nicht Werbemails der Braunschweiger Zeitung o.ä., nur weil sie einen persönlich belästigen.