MME – Moodle Mail Essentials
Aus Moodlesystemen werden viele Mails verschickt:
- Mails bei neuen Forenbeiträgen
- Mails nach Benutzerregistrierungen
- Mails für den Admin nach Backupläufen
- usw.
Je nach Größe des Moodlesystems können das sehr viele Mails sein – z.B. wenn der Admin im Nachrichtenforum eine neue Nachricht schreibt und alle Nutzer des Systems dieses Forum abonniert haben. Oft macht man dabei am Anfang die Erfahrung, dass ein Teil dieser Mails nicht ankommt. Daran ist sehr oft mitnichten Moodle schuld. Einige Anbieter schieben zusätzlich die Schuld auf Freemaildienste, bei denen die Mails „aus unerfindlichen Gründen“ im Spamordner landen würden. Die Gründe sind in den seltensten Fällen unerfindlich, sondern lassen sich durch eine Analyse der betreffenden Mail sehr leicht ermitteln. Es gibt also Aspekte des Mailproblems, die der Moodleadmin lösen kann und es gibt Aspekte, die nur der Provider zu richten vermag.
Fehler 1: Die Adresse des Moodleadmins
Die E‑Mailadresse des Moodleadmins kann nicht beliebig gewählt werden, da sie als Absenderadresse für Systemmails eingesetzt wird. Ein sehr häufiges Setup sieht dabei so aus:
Lehrer Lempel möchte in seinem Privatleben nicht von Moodlemails belästigt werden (obwohl er clientseitig ohne weiteres effizient filtern könnte). Lehrer Lempel hat ein Paket bei Supertollerprovider bestellt, das eine Domain und E‑Mailadressen für die Domain inkludiert. Unter der Domain läuft Lehrer Lempels privater E‑Mailaccount. Lehrer Lempel hat sich extra für die Schülerkommunikation einen Gmail-Account zugelegt. Diesen trägt er als Adminadresse ein.
Das geht schief. Die meisten Provider überprüfen, ob die Absenderadresse einer Mail auch zum versendenden E‑Mailserver passt. Dummerweise dürfen nur die Server von Gmail Mails im Namen von GMail verschicken. Unser armer Mailsserver bei Supertollerprovider darf das nicht.
Folge:
Die Mails werden nicht versandt. Im Idealfall akzeptiert bereits der ausliefernde Mailserver von Supertollerprovider die Mail nicht, weil er sich für die Domain „gmail.com“ nicht zuständig fühlt. Im schlimmsten Fall verschickt dieser die Mail brav und der empfangene Mailserver lehnt die Mail entweder ganz ab oder sortiert sie in den Spamordner, weil der Absender offensichtlich gefälscht ist, da der Server von Supertollerprovider keine Berechtigung besitzt, Mail unter der Domain gmail.com zu verschicken.
Abhilfe:
- Einen weiteren Mailaccount bei Supertollerprovider anlegen und diesen nutzen
- SMTP-Server konfigurieren (in diesem Fall den von Gmail – oh, geht ja gar nicht…) und nutzen
Fehler 2: Die Noreplyadresse
Hier gilt prinzipiell des Gleiche wie für die Adminadresse, nur in verschärfter Form, weil diese Adresse bei jedem neuen Forenbeitrag genutzt wird.
Fehler 3: Jeder muss alles per Mail erhalten
Das Erstaunliche ist immer, dass Lehrer Lempel sehr oift von den ganzen Mails, die er so bekommt, genervt ist, seinen SuS aber zumutet, jedes „Goil, eh!“ an Forenbeiträgen per Mail zugestellt zu wissen, indem er SuS zwangmäßig in Foren einträgt. Einerseits erhöht sich dadurch das Mailaufkommen, andererseits verringert sich dadurch die Chance, dass alle Mails ihr Ziel erreichen, weil viele Anbieter Limits einbauen: Sie akzeptieren von einem Mailserver nur z.B. 100 Mails pro Stunde gleichzeitig. Wenn von 500 SuS z.B. 120 eine E‑Mailadresse bei GMX besitzen und GMX hätte diese Limitierung, würden 20 Nutzerinnen und Nutzer die Nachricht aus dem Nachrichtenforum (erstmal) nicht erhalten. Wer einen SMTP-Server konfiguriert hat, bekommt noch weitere Probleme.
Abhilfe:
- Klären Sie Ihre SuS so auf, dass sie zielgerichtet eigenständig abonnieren
- Nutzen Sie die Zusammenfassung per E‑Mail
- Verwenden Sie die Feedmöglichkeit von Moodle wo immer möglich (RSS-Feed). Die SuS lernen dabei zusätzlich die Bedienung eines Feedreaders
Reduzieren Sie also das Mailaufkommen Ihres Systems! Mails, die gar nicht erst verschickt werden, können auch nicht verloren gehen.
Fehler 4: Anbieterwahl
Damit das Mailsystem von Moodle zufriedenstellend funktioniert, muss ein Anbieter gewisse Voraussetzungen erfüllen. Zu den wichtigsten gehört dabei der Zugriff auf eigene oder gemietete DNS-Server. Ein Indiz für das Vorhandensein eines solchen bietet das folgende Testverfahren:
- Suchen Sie sich eine beliebige DE-Domain, von der Sie wissen, dass Sie bei dem Anbieter liegt oder von ihm verwaltet wird.
- Lassen Sie sich auf http://www.denic.de die Whois-Daten dieser Domain anzeigen.
Unter der Rubrik „Tech‑C“ und „Zone‑C“ muss dort der Name Ihres anvisierten Anbieters auftauchen. Wenn unter der Rubrik „Technische Daten“ noch zusätzlich für die Nameserver ein Domainname auftaucht, den Sie ihrem Provider zuordnen können, ist das fast noch ein wenig sicherer.
Hintergrund:
Ein Zone‑C kann durch entsprechende DNS-Einträge dafür sorgen, dass die Wahrscheinlichkeit steigt, dass Ihre Mails aus dem Moodlesystem von anderen Anbietern aktzeptiert werden. Weiterhin ist der Eintrag unter Tech‑C fast ein Garant dafür, dass der Anbieter Domaindaten schnell und unkompliziert updaten kann – z.B. wenn ab jetzt der Schulleiter als Admin‑C für die Domain eingetragen werden soll. Auch ist die Wahrscheinlichkeit gegeben, dass ein gültiger RDNS-Eintrag für den Mailserver besteht.
Wichtig:
Wenn Ihr Anbieter diese Einträge nicht besitzt, heißt das nicht zwangsläufig, dass die Voraussetzungen für ein vernünftiges Mailhandling für Moodle nicht gegeben sind. Es heißt nur, dass Ihr Anbieter gewisse Vorprodukte von Dritten einkauft. Je nach Absprache zwischen Ihrem Anbieter und dem Dienstleister für das Vorprodukt kann ein gleichwertiger und gar besserer Service erreicht werden.
Umgekehrt kann auch ein Anbieter mit diesen Einträgen im Bereich des Mailhandlings schlechte Leistungen bieten.
Deswegen sind diese Einträge lediglich ein Indiz für eine gewisse Qualitätsstufe. Je mehr ich als Provider selbst regeln kann, desto schneller kann ich meine Kunden bedienen, da ich nicht auf Dritte angewiesen bin.
This work by Maik Riecken is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International