Userdokumentation

Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
# E-Mail

## Zugang

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 [[passwoerter|Passwörter]] für die Verteilung der Passwörter). Wenn man keine Blacklist im [[ServiceInterface|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.

### Relaying denied

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.

## Webmail

Als Webmailer verwenden wir die Software [Horde](http://horde.org). 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.

### Address is missing domain.

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.

## Spamfilterung

### SpamAssassin

Wir setzen auf unserem Mailserver [[wd>spamassassin|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.

### Wo kann man den Spamfilter für sich filtern lassen?

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 Whitelisting

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.

## Urlaubsbenachrichtigung

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_(alte_Regeln_vor_2014)|Filter konvertieren]].
## Mailfilterung/Sieve

Die Mailfilterung beim IN-Berlin läuft über die Sprache [[https://de.wikipedia.org/wiki/Sieve|Sieve]]. Sieve kann man auf drei Arten konfigurieren:

 * über die Konsole mit dem Programm `sieve-connect` auf unserem [[Shell|Shellserver]] (nur für erfahrene Anwender empfohlen).
 * über verschiedene Clientprogramme, z.B. das Plugin *Sieve* für Thunderbird
 * über das [Webmail-Interface](https://webmail.in-berlin.de/).

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 einrichten

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_(alte_Regeln_vor_2014)|Filter konvertieren]].

### Filter konvertieren (alte Regeln vor 2014)

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 [[kontakt|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.

## Mailinglisten

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

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](https://in-vpn.de/))
 * einen statischen Hostnamen (z.B. mit [[DynDNS]]) und ein TLS-Zertifikat.

Diese IP bzw. dieses Zertifikat und den Hostnamen teilt man dann dem [[kontakt|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 [[wd>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.