Der Mailserver beim IN-Berlin ist auf unterschiedliche Wege zu erreichen. Bis auf webmail ist das derzeit alles der gleiche Server. Aber da das evtl. in Zukunft getrennt werden könnte, sollte man es lieber mit diesen Hostnamen einrichten:

• zum Mailabholen via IMAP (empfohlen) unter imap.in-berlin.de
• zum Mailabholen via POP3 unter pop3.in-berlin.de
• zum Mailverschicken via SMTP unter mail.in-berlin.de
• via Webinterface unter https://webmail.in-berlin.de/

Das Postmaster-Postfach hat als Usernamen den Sitenamen, als Passwort das Mailpasswort (siehe Passwörter für die Verteilung der Passwörter). Wenn man keine Blacklist im Service-Interface eingetragen hat (unter Black-/Whitelist bearbeiten), dann kommen hier per Default alle Nachrichten an, die an eine beliebige Adresse @sitename.in-berlin.de bzw. an jede @domain.tld Domain der Site geschickt werden.
Da damit sehr viel Spam kommt, empfehlen wir, eine Blacklist anzuschalten, s.u.

Legt man ein weiteres Postfach mit dem Namen accountname an, dann loggt sich dieser Account für IMAP, POP3 oder SMTP mit dem Usernamen sitename_accountname an.

Beispiel: Die Site example mit der Domain example.org legt den Account bernd an, dann ist dieser unter bernd@example.in-berlin.de und bernd@example.org zu erreichen. Mails abrufen und verschicken muss der User die Mails aber mit dem Usernamen example_bernd. Als Loginserver dienen dafür nach wie vor imap.in-berlin.de usw.

Die maximale Größe pro E-Mail ist derzeit auf 50MB festgesetzt.

Schickt man seine E-Mails nicht über eine IP-Adresse vom IN-Berlin (VPN, DSL, Serverhousing) ab und trägt beim SMTP-/Postausgangsserver keine Authentifizierungsdaten (Benutzername und Passwort) ein, dann lehnen unsere Mailserver die Einlieferung der E-Mail mit der Meldung „Relaying denied“ ab. Dies dient dem Schutz vor Spam, denn jeder E-Mail-Nutzer soll ja den Mailserver seines Providers für den Versand von E-Mails nutzen und dafür ist eine Anmeldung erforderlich.

Lösung: Benutzername und Passwort in die Konfiguration des SMTP-/Postausgangsservers eintragen. Diese sind identisch mit den Daten für die Abholung von E-Mails.

Als Webmailer verwenden wir die Software Horde. Die ist leider teilweise etwas buggy, sodass Fehler vorkommen können. Am besten meldet ihr euch dann gleich beim Support, idR lässt sich das schnell beheben.

Falls der Fehler „Beim versenden der Nachricht ist ein Fehler aufgetreten: Address is Missing Domain.“ beim Verschicken einer Nachricht auftritt, ist das Absenderprofil falsch. Das kann man beheben, indem man auf das Zahnrad oben rechts geht → Benutzereinstellungen → Allgemeine Einstellungen → Persönliche Angaben. Hier muss man nun eine Standardidentität festlegen, die eine gültige Mailadresse als Absender hat. Danach sollte es gehen. Falls nicht, bitte beim Support mit Angabe des fehlerhaften Mailaccounts melden.

Wir setzen auf unserem Mailserver SpamAssassin ein. Alle(*) eingehenden Mails werden durch ein umfangreiches, trainierbares Regelwerk bewertet. In den ausgelieferten Mails befinden sich dann zusätzliche Headerzeilen wie:

X-Spam-Score: *** (3.506) BAYES_50,FORGED_RCVD_HELO,RCVD_NUMERIC_HELO,WORK_AT_HOME

Die Zahl der Sternchen entspricht der „Punktzahl“, die dahinter angegeben ist, danach sind die Tests aufgeführt, die zu dieser Bewertung geführt haben.

Die Kopfzeilen (Header) können sowohl auf dem POP3/IMAP/Webmail Server als auch beim Empfänger ausgewertet werden. Wir lassen keine sonst bei SpamAssassin übliche Zeile

X-Spam-Flag: YES

einbauen, da wir die Entscheidung, ab welcher Punktzahl eine Mail als Spam angesehen werden soll, den einzelnen Teilnehmern überlassen wollen.

Alle, deren eingehende Mails über unsere Mailserver gehen, können auf

https://service.in-berlin.de/intern/config.cgi?command=editspamfilter

die Filter für ihr eigenes Postfach oder für die gesamte Site einstellen. Bei POP3-/IMAP-Empfängern geht dies auch sehr spezifisch für einzelne Adressen.

Die Spamfilter wirken auch auf Mailweiterleitungen.

Folgende Reaktionen, abhängig vom X-Spam-Score, sind möglich:

• Mail annehmen
• Mail in Spamordner verschieben (nicht bei Empfang per UUCP oder direkter SMTP Auslieferung)
• Mail ablehnen (Absender bekommt i.d.R. mit, wenn die Mail abgelehnt wurde: „rejected by policy“)
• Mail wegwerfen

Daraus folgt sofort die Warnung vor überlaufenen Postfächern: Wer Mails immer nur per POP3 abholt, „sieht“ Spam nicht, der in den Ordner „spam“ verschoben wird, aber die unerwünschten Mails verbrauchen trotzdem Speicherplatz. Der Spamordner wird automatisch angelegt, sofern er nicht bereits existiert.

Abhilfe: Zugriff per IMAP (abhängig vom verwendeten Programm muß der Ordner „spam“ (oder „INBOX.spam“) evtl. erst „abonniert“ werden, damit er sichtbar wird) oder per https://webmail.in-berlin.de/.

Black- und Whitelists beziehen sich auf Empfängeradressen, sie haben an dieser Stelle nichts mit Absenderadressen zu tun. Nicht wenige bekommen Spam an Adressen wie eip9iema@sitename.in-berlin.de. Die kann man gleich zurückweisen lassen. Einzustellen ist dies auf der Webseite zur Konfiguration der eigenen IN-Berlin-Site: https://service.in-berlin.de/intern/config.cgi?command=editcatch . Dies könnte dann z.B. so aussehen:

• Whitelist:

  • willichhaben@sitename.in-berlin.de
  • willichauchlesen@sitename.in-berlin.de
  • mein.name@sitename.in-berlin.de
  • postmaster@sitename.in-berlin.de
• Blacklist: sitename.in-berlin.de
• automatisch „whitelisted“ werden
  • Mailweiterleitungen
  • POP3/IMAP Postfächer
  • Adressen von Mailinglisten

Damit werden nur noch die Adressen willichhaben@sitename.in-berlin.de, willichauchlesen@sitename.in-berlin.de, mein.name@sitename.in-berlin.de, postmaster@sitename.in-berlin.de für sitename.in-berlin.de angenommen. Statt sitename.in-berlin.de kann hier auch eine eigene Domain stehen, für die unsere Server Mail annehmen. Es werden natürlich nur zu einer Site gehörende Adressen akzeptiert.

Die Blacklist enthält vollständige Adressen oder Domains, für die keine Mail angenommen werden soll.

Die Whitelist enthält vollständige Adressen oder Domains, für die Mail angenommen werden soll.

Wenn für eine Empfängeradresse Einträge aus beiden Listen zutreffen, „gewinnt“ die Whitelist, d.h. die Mail wird angenommen.

Mail für angelegte zusätzliche POP3/IMAP Postfächer, Mailaliases und Mailinglisten wird auf jeden Fall angenommen; diese müssen nicht extra in der Whitelist aufgeführt werden (siehe oben).

Meldungen über zurückgewiesene Mails enthalten den Text

----- The following addresses had permanent fatal errors -----
<unerwuenscht@sitename.in-berlin.de>
(reason: 550 5.2.1 <unerwuenscht@sitename.in-berlin.de>... Mailbox disabled for this recipient)

und werden nicht vom IN-Berlin, sondern von dem Mailserver versandt, der versuchte, die Mail bei den zuständigen IN-Berlin Mailservern (MXer) einzuliefern.

Wenn man sich eine Urlaubsbenachrichtigung für seinen Mailaccount einrichten möchte, klickt man im Webmail auf Webmail, Filter, Abwesenheit. Dort kann man einstellen, von wann bis wann man Urlaub hat und welche Nachricht man verschicken will. Klickt man wieder auf „Filterregeln“, kann man den Urlaub auf der rechten Seite mit Klick auf das Kreuz aktivieren (und mit Klick auf ein Häkchen die entsprechende Regel deaktivieren).

Achtung: Wenn man den Urlaub aktiviert, gehen ggf. Regeln, die man im alten Websieve (vor 2014) eingestellt hat, verloren. Siehe auch dafür Filter konvertieren.

Die Mailfilterung beim IN-Berlin läuft über die Sprache Sieve. Sieve kann man auf drei Arten konfigurieren:

• über die Konsole mit dem Programm sieve-connect auf unserem Shellserver (nur für erfahrene Anwender empfohlen).
• über verschiedene Clientprogramme, z.B. das Plugin Sieve für Thunderbird
• über das Webmail-Interface.

Die ersten beiden Wege sind etwas steiniger (als Logindaten benutzt man die gleichen wie für das Mailabholen vom gleichen Server), wir wollen hier nur den letzten beschreiben. Allerdings ist zu beachten: Regeln, die mit einem anderen Sieve-Client erstellt wurden, können von einem anderen Editor in der Regel nicht bearbeitet werden! Also wer sich Regeln mit Thunderbird erstellt hat, wird diese danach mit dem Webmail überschreiben.

Der Filter vom Horde ist in der Benutzung etwas gewöhnungsbedürftig: Wenn man Regeln anlegt, dann werden diese zuerst nur beim Horde selber gespeichert. Diese Regeln werden immer nur benutzt, wenn man sich im Horde einloggt.

Benutzt man nichts anderes als das Webmail vom IN-Berlin, dann kann man an dieser Stelle Halt machen. Benutzt man aber noch andere Mailclients, z.B. Thunderbird, Apple Mail oder Windows Live, dann muss man mehr tun. Denn diese Regeln werden nur auf den Mailserver übernommen, wenn man sie explizit aktiviert. Dafür geht man im Webmail-Interface auf Webmail, dann auf Filter, dann auf Skript. Dort kann man mit Skript aktivieren die eingestellten Regeln von Horde auch auf den Mailserver kopieren, sodass der sie bei jeder eingehenden Mail anwendet.

Filter richtet man ein, indem man auf das Webmail geht und dann auf Webmail, dann auf Filter, und dann auf Neue Regel klickt. Hier kann man nun verschiedene Regeln einrichten, das Interface ist ähnlich dem alten. Zuerst wählt man aus, was alles an Regeln greifen soll, und ob sie alle zusammen oder nur einzeln schon gültig sein sollen. Man wählt ein Feld aus, das gefiltert werden soll, und eine Aktion.

Nachdem man auf „Speichern“ klickt, wird die Regel sofort übernommen. Hat man noch Regeln mit dem alten Webmail vor 2014, dann muss man zuerst einen neuen Tab/Fenster öffnen wie beschrieben unter Filter konvertieren.

Vor der Mailserverumstellung im Dezember 2013 hatte der IN-Berlin ein anderes Skript zum Verwalten der Sieve-Regeln. Leider benutzte das ein eigenes Format zum Abspeichern der Regeln und Horde benutzt ein anderes, sodass die alten Sieve-Regeln sich nicht automatisch konvertieren ließen.

Daher müssen User, die die alten Regeln noch weiterhin benutzen und editieren wollen, diese erstmal in das neue Horde kopieren. User, die einfach nur die alten Regeln weiterbenutzen und nichts ändern wollen, müssen an dieser Stelle nicht weiterlesen.

Die Filterregeln ins neue Format kopieren tut man, indem man im Webmail-Interface (am besten in einem neuen Tab) auf Webmail, dann auf Filter, dann auf Skript und dort auf Aktives Skript anzeigen klickt. Dort sieht man (etwas kryptisch) die alten Sieve-Regeln, aber halbwegs verständlich. Jetzt muss man, wie unter Filter_einrichten beschrieben, diese Filterregeln mit dem neuen Interface zurechtklicken. Wenn man alle Regeln so neu eingegeben hat, klickt man auf Webmail, Filter, Skript und dann auf Skript aktivieren (auf keinen Fall vorher, damit gehen die alten Regeln verloren!). Nun sind alle Regeln des Horde auch auf dem Mailserver aktiv und die alten sind überschrieben.

Falls es Probleme oder Fragen bei der Konvertierung geben sollte, einfach eine Mail an Support schreiben oder direkt über das Webmail-Interface eingeben.

Beispiel:

 1: # Mail rules for user schrank21_listensammler
 2: # Created by Websieve version 0.61h
 3: require ["fileinto"];
 4: 
 5: if allof (header :contains  "Sender" "security-announce-owner@NetBSD.org") {
 6:      fileinto "netbsd-security-announce";
 7: }
 8: 
 9: elsif allof (header :contains  "Sender" "support-bounces@in-berlin.de") {
10:      fileinto "inbev-support";
11: }
12: 
13: elsif allof (header :contains  "Sender" "netbsd-users-owner@NetBSD.org") {
14:      fileinto "netbsd-users";
15: }
16:
17: elsif allof (address :contains ["from"] "security@slackware.com") {
18:      fileinto "slackware-security";
19: }

Diese Regeln sorgen dafür, dass

• (Zeile 5-7) Mails mit dem „Sender“ security-announce-owner@NetBSD.org in den Ordner netbsd-security-announce geschoben werden,
• (Zeile 9-11) Mails mit dem „Sender“ support-bounces@in-berlin.de in den Ordner inbev-support geschoben werden,
• (Zeile 13-15) Mails mit dem „Sender“ etbsd-users-owner@NetBSD.org in den Ordner netbsd-users geschoben werden,
• (Zeile 17-19) Mails mit dem Absender security@slackware.com in den Ordner slackware-security geschoben werden.

Wenn man regelmäßig Mails an größere Mengen von Menschen verschicken möchte, dann empfiehlt sich eine Mailingliste. Das Thema findet sich auf einer eigenen Wikiseite.

Normalerweise muss ein User seine E-Mails beim IN-Berlin via IMAP oder POP3 selbst abholen. Dies hat allerdings den Nachteil, dass die Mails beim IN-Berlin dauerhaft gelagert werden (bis man sie löscht), u.a. auch im Backup. Daher wollen einige ihren eigenen Mailserver betreiben.

Wenn man seinen Mailserver aber zu Hause, und nicht im Rechenzentrum betreibt, hat man damit mehrere Probleme:

• der Mailserver ist nicht immer online, es gehen ggf. Mails verloren, wenn sie lange Zeit nicht zugestellt werden können.
• die IP ist eine öffentliche DSL-IP eines großen Providers. Die sind aber oft auf Spamlisten, da hier zu viele Zombierechner unterwegs sind, Mails werden abgelehnt.

Daher bieten wir an, Teilnehmern die Mails direkt zuzustellen. Dafür braucht der Teilnehmer entweder:

• eine statische IP (z.B. mit IN-VPN)
• einen statischen Hostnamen (z.B. mit DynDNS) und ein TLS-Zertifikat.

Diese IP bzw. dieses Zertifikat und den Hostnamen teilt man dann dem Support mit. Dann werden für die entsprechende Domain die IN-Berlin-Mailserver als MXer eingetragen, und alle Mails für diese Domain gehen erstmal an diese Mailserver. Wenn nun der Mailserver des Users online ist, werden sie direkt an ihn weiter zugestellt. Falls nicht, dann werden die Mails bis zu 90 Tage aufgehoben. Nach 30 Tagen gehen die ersten Warnungen an den Absender. Ist der User-Mailserver dann irgendwann online, kann er mit einem ETRN-Befehl (siehe SMTP) unsere Mailserver veranlassen, Mails an ihn zuzustellen. Die Mails vom IN-Berlin kommen aus dem Netz 192.109.42.0/27 bzw. 193.29.188.0/27.

Wichtig: Der IN-Berlin kann nicht bei der Einrichtung des eigenen Mailservers helfen! Hierfür sollte man ein wenig Erfahrung mitbringen.