Moodle-Blog

Wir erhalten immer wieder Nachrichten, dass E-Mails aus Moodle nicht zugestellt worden sind.

In den meisten Fällen handelte es sich hierbei um Mailaccounts bei Freemail-Anbietern. Diese schieben Mails von unbekannten Absendern erst mal in das Spam-Postfach. Erst wenn man dort nachschaut findet man die Mails dann.

In zwischen erhalten wir immer öfter folgende Mails:

Hallo!

Ihre E-Mail ist eingegangen, wurde aber vom Antispamprogramm unter “unbekannter Absender” abgelegt. Bitte verifizieren Sie sich als Absender, indem Sie diese Mail einfach per “beantworten” wieder zurücksenden. Aufgrund des unten eingefügten Codes werden Sie dann beim Eingang dieser E-Mail als vertrauenswürdiger Absender im Antispamprogramm gespeichert. Es ist nicht notwendig, die ursprüngliche E-Mail noch einmal zu senden.

Vielen Dank!

Diese wirkungsvollen lokalen Anti-Spam Programme helfen ebenfalls die Spam-Flut einzudämmen. Sie lassen erst einmal nur Mailaeingänge zu wenn der Absender bereits bekannt ist, weil sie ihm eine Mail geschrieben haben, oder er sich bei Ihnen bestätigt hat. Dazu versenden sie an jede unbekannte Mailabsenderadresse eine Information. Erst wenn diese vom Absender bestätigt wird, wird die ursprüngliche Mail auch dem Empfänger zugestellt.

Das Verfahren:
1. Klaus M. meldet sich bei Moodle mit seiner Mailadresse an
2. Klaus M. erhält von Moodle eine E-Mail zur Bestätigung der Anmeldung
3. Das Anti-Spam-Programm kennt das Moodle-Programm und die Absenderadresse des Administrators noch nicht und hält es für Spam. Deshalb schickt es dem Admin eine Nachricht (s.o.)
4. Der Admin soll diese Mail bestätigen.
5. Danach wird Klaus M. erst in seinem Mailprogramm die ursprüngliche Bestätigung vorgelegt (siehe 2.).
Tut der Admin dies nicht, so bleibt die Bestätigungsmail aus Moodle im Spamordner von Klaus M. liegen.

Die Administratoren von Moodle können nicht täglich solche Mails durchsehen und werden sie daher meist ignorieren. Zusätzlich haben die Spammer die Existenz dieser Programmen inzwischen auch kennengelernt. Sie nutzen die Texte und versenden wahllos entsprechende Mails. Werden diese beantwortet, so erhalten Sie eine verifizierte E-Mail und können diese mit Spam versorgen.

Uns bleibt hier nur übrig, die Teilnehmer zu informieren, dass Sie ggfs. Mails aus Moodle erst einmal auch im Spam-Postfach suchen müssen.

In den letzten Wochen häufen sich in meinem Maileingang für die Domain ‘moodle.de’ Nachrichten aus fremden Moodle-Systemen. Dies passiert immer dann wenn jemand in seinem Moodle-System Nutzer anlegt und als Mailadresse ‘*@moodle.de’ einträgt. Meist handelt es sich dabei um Test- oder Dummy-User.

Ich halte das aus mehreren Gründen für problematisch:

• Andere Leute geht es nichts an, was in Euren Kursen passiert. Deshalb sollten sie auch keine Mails aus den Kursen erhalten.
• Es handelt sich um gängige Strategien der Spammer, mit falschen Mailadressen durch die Welt zu ziehen. Wird Eure Domain auf dem Wege bei einem Maildienstleister in die Blacklist eingetragen, werden u.U. auch Mails echter Nutzer gesperrt.
  Bsp.: Wenn innerhalb einer Woche z.B. bei aol.com mehrere Nutzer eine ankommende Mail von xy.com als Spam deklarieren, gerät der Absender xy.com auf die Spam Liste. Dies passiert auch automatisch wenn erfundene Namen z.B. ‘haenschenklein@aol.com’ genutzt wird, die vielleicht gar nicht existiert. Wenn nun aber der Schulleiter seine Mailadresse bei aol.com hat, werden ihm reale Mails auch nicht mehr zugestellt, da der Versender auf einer Blacklist steht und als Spamschleuder angesehen wird. Das kann also auch Eure Absenderadresse sein.
• Wer unbedingt Dummy-Nutzer benötigt, sollte sicher stellen, dass diese Mailadressen der eigenen Institution verwenden, die gezielt ausgefiltert werden können.

Dass das auch einmal ins Auge gehen könnte, zeigte sich letzte Woche. In meinem Maileingang befand sich eine Mail an solch einen Dummy-Nutzer. Inhalt war die Information über die Struktur der Loginnamen und der Passwörter für das Moodle-System der Schule. Adressiert war es an einen Lehrer, der in seinem Profil eine Mailadresse *@moodle.de eingetragen hatte und die E-Mail prompt bei mir landete.
Inzwischen versuche ich, mit kleinem Aufwand die Absender zu ermitteln und weise diese auf das Problem mit einem Standardbrief hin.

Ich möchte noch auf eine kleine Nuance hinweisen. Ich führe immer wieder mal die Diskussion, besonders im Schulbereich, über das Anlegen von Mailaccounts mit erfundenen Namen für Schüler.
Wenn die Schüler dann diese Mailaccounts auch in Moodle-Systemen nutzen und die Mailaccounts irgendwann vergessen, so werden weiterhin Mails an diese Accounts versendet. Werden die Accounts irgendwann vom Anbieter aufgehoben endet der Mailversand nicht. Ganz schnell ist auch auf diesem Wege das Moodle-System auf die Blacklist geraten.
Unabhängig davon habe ich erhebliche Bedenken bei Fake-Adressen, da sie zum Missbrauch verleiten und im Netz zu immer mehr Komplikationen führen.

Für manch einem mag der Begriff Captcha ein Fremdwort sein. Deshalb zuerst eine kurze Erklärung. Bei vielen Online-Diensten muss man beim Anlegen eines Accounts eine Ziffernfolge, die leicht verfremdet angezeigt wird eintippen. Damit soll verhindert werden, dass neue Nutzer durch automatische Scripte angelegt werden, um dann evtl. Spam verbreiten zu können.

Viele Moodle-Systeme lassen das Anlegen neuer Nutzer über eine Selbstanmeldung nicht zu. Daher stellt sich das Problem gar nicht.

Überall dort wo sich Teilnehmer jedoch selber einen Zugang anlegen sollen erhalten Sie per Email eine Bestätigung. Erst wenn der darin enthaltene Link bestätigt wird, ist der Zugang aktiv geschaltet. In aller Regel verhindert dieses Verfahren wirkungsvoll, dass Unfug angestellt wird. Unbestätigte Accounts werden vom System automatisch wieder gelöscht.

Dennoch ist es zum Jahreswechsel vereinzelt vorgekommen, dass durch Scripte neue Nutzer angelegt wurden. Im Einzelfall waren das mehrere hundert neue Nutzer. Inn nahezu allen Fällen konnten diese Nutzer das System nicht nutzen und leicht wiedser entfernt werden.

Der Schutz durch Captcha-Systeme ist technisch wirkungsvoll, da bei entsprechender Verfremdung die Ziffern und Buchstaben nicht durch Texterkennungsprogramme ausgelesen werden könne, um sich anzumelden.

Nachteil ist jedoch, dass es vielen Menschen ebenfalls schwer fällt, diese Texte und Ziffern zu erkennen. Unschärfe, durchgestrichene, tanzende Buchstabune und geringe Farbkontraste erschweren es vielfach die richtigen Buchstaben zu erkennen. Menschen mit Einschränkungen im Sehbereich (Blinde, Farbenblinde) haben dann keine Chance.

Moodle legt immer größeren Wert auf die Erfüllung der Anforderungen zum barrierefreien Zugang. Seit einigen Tagen gibt es in der aktuellsten Version auch eine Unterstützung für den Captcha-Schutz.

Dabei wird ein Verfahren gewählt, das sich nicht nur auf eine bildhafte Darstellung beschränkt. Alternativ kann man sich den Text auch vorlesen lassen und dann die Ziffern und Zahlen eintragen.

Die Funktionalität ist in der Version 1.9.+ enthalten.

Passend nur Veröffentlichung der Version 1.9 von Moodle haben André Krüger, Urs Hunkler und Ralf Hilgenstock das Handbuch zur Installation und Adminsitration von Moodle aktualisiert neu aufgelegt.

Auf nunmehr 180 Seiten informieren Sie über alles, was zum eigenen Betrieb eines Moodle-Systems erforderlich ist. Ein ausführliches Stichwortverzeichnis hilft beim Finden.

Preis 30,- € zzgl. Versand.

Bestellung über DIALOGE Verlag: info@moodle.de.

Service: Versuchte Spam-Angriffe auf Moodle-Systeme

Ausführliche Beschreibung wie man erkennt, ob man betroffen ist und was man dann tun kann oder wie man sich wirkungsvoll schützt.

Mehrfach auf verschiedenen Veranstaltungen wurden im Laufe des Dezember SOA-Konzepte für Lernumgebungen gefordert. Beide Male waren es CIOs, die diese Forderung aufstellten, beide male kamen sie aus Dortmund.

Der eine Dr. R. Yahyapour ist CIO der Uni Dortmund, der andere Manfred Langguth ist CIO der Stadtverwaltung Dortmund und Vorsitzender der AKDN IT-Leiterkonferenz kommunaler Rechenzentren in NRW. Langguth erklärte aufbauend auf einer Untersuchung von Prof. Dr. Breiter (Institut für Informationsmanagement, Bremen, dass SOA-Konzepte künftig auch für die Schulen von zentraler Bedeutung seien.

Breiter hatte zuvor berichtet, dass bei der Untersuchung des Softwareeinsatzes in Schulen einer nicht genannten Großstadt folgendes herauskam: Es gibt kein Software- und Lizenzmanagement. niemandweiß welche Software mit welchen Lizenzen einegesetzt. die Detailuntersuchung führte dazu, dass man feststellte, es werden an allen Schulen dieser Stadt 1.800 unterschiedlche Softwareprogramme eingesetzt. Aus der sich eines kommunalen Rechenzentrums ist das der Alptraum schlechthin.
Vergleichszahlen einer Kommune zeigen, dass dort weniger als 200 unterschiedliche Anwendungen im Einsatz sind. Jede Software ist im Blick eines Rechenzentrum ein Kostenfaktor, da die Software Ressourcen in Form von Recherkapazität, Lizenzverwaltung und Support erfordert. So betrachtet sind 1.800 Programme eine pure Zumutung.

Ziel der Rechenzentren in NRW sei es künftig SOA-Konzepte für die Schulen mit zentralem Support durchzusetzen. Man betrachte die Schulen als informationstechnisches System.

Was ist nun SOA? SOA steht für service-orientierte Architektur von Software. Einfach ausgedrückt geht es darum, dass Softwareleistungen, die von mehreren Anwendungen benötigt werden nicht mehr in jeder Anwendung bereitgestellt werden, sondern einmalig als zentraler Service bereitgestellt werden auf den die Anwendungen zugreifen. Solche Services sind z.B. Nutzerverwaltung, Druckdienste, Maildienste etc… Der Gedanke ist attraktiv, weil jede Anwendung sich auf einen Kern spezialisieren kann und alle weiteren Dienste von zentraler Stelle bekommt. Man kann sich dann einen Arbeitsplatz als Bausteinsystem aus verschiedenen kleinen Applikationen vorstellen.

Langguth kritisierte unter solcher einem Gedankengebilde Moodle als wahres Monster, da es alle Dienste selber mitbrächte, was vollständig überflüssig sei.

Moodle bietet an mehreren Stellen Schnittpunkte, um sich in SOA-Architekturen einzubinden und an weiteren Datenaustauschpunkten wird gearbeitet. Das ist nicht der wesentliche Punkte. Bleiben wir exemplarisch einmal in Langguths Heimatstadt Dortmund, um die Fragen eines SOA-Konzeptes für die Schulen in Dortmund genauer zu betrachten.

Dortmund hat 600.000 Einwohner und ca. 4.500 Beschäftigte in der Stadtverwaltung. Statistisch dürften etwa 90.000 Schüler in Dortmund leben.

Eine Lernplattform für Dortmund mit SOA-Anbindung benötigt eine Nutzerverwaltung für 90.000 Schüler und ihre Lehrer. Gehen wir realistisch einmal von 50 % aus, so sind das immer noch die zehnfache Zahl der aktuellen Nutzer in der Stadtverwaltung.

Derzeit wird die Softwarewartung und -distribution individuell an den Schulen von den Lehrern gemacht. Diese sind Landesbedienstete und verursachen bei der Stadt Dortmund keine Personalkosten.

Bei der Integration der Schulsoftware in ein zentrales Konzept würden beide Bereiche (Nutzerverwaltung und Softwareverwaltung) nicht unerheblichen Leistungsaufwand in der kommunalen IT verursachen.

1.800 Softwareanwendungen sind tatsächlich ein Graus. Realistisch dürfte es sein, dass bei einer schulinternen Inventur vermutlich 2/3 der Anwendungen als nicht mehr in Gebrauch deklariert und gelöscht werden können. 600 Anwendungen sind bei ca. 150-200 Schulen mit vielen fachlich sehr unterschiedlichen Ausbildungsgängen wiederum nachvollziehbar. Ein Berufskolleg mit 3.000 Schülern und 40 Ausbildungsberufen ist nun mal auch softwaretechnisch komplexer als eine Stadtverwaltung.

Um nun zu einer Reduzierung der Software zu kommen, benötigt man einen schulinternen und einen schulübergreifenden Abstimmungsprozess über die einzusetzende Software. Angesichts der allgemeinen Autonomisierung und des Wettbewerbs von Schulen ist dies zumindest widersprüchlich.

Die wörtlich gefallene Aussage, man betrachte Schulen als ‘informationstechnisches System’ ist zumindest missverständlich. Schulen sind primär ein Bildungs-, Qualifizierungs- und Erziehungssystem. Eine Konfrontation der Schulen mit dem Zitat garantiert Widerspruch bis Widerstand. Dahinter steckt jedoch mit Sicherheit ein Übersetzungsproblem. Hier kollidieren zwei Welten, die unterschiedliche Sprachen sprechen und sich nicht verstehen.

Aus meiner Sicht offene Fragen:
Haben die Kommunen das Geld, diese Infrastrukturen aufzubauen und neue Services und Support bereitzustellen?
Ist die technische Infrastruktur (Netze, Hardware, Betriebssysteme) dazu ausreichend, kann sie aktuell gehalten und gepflegt werden?
Wie gestaltet sich der Kommunikations- und Vermittlungsprozess in die Schulen hinein? Wie wird sichergestellt, dass die schulische Autonomie in pädagogischen Fragen gestärkt und nicht geschwächt wird (faktisch und emotional)?
Stehen die SOA-Modelle auf dem Papier oder sind sie zum nächsten Schuljahr umsetzbar? Mit welchen Services? Mit welchen Contents? Mit welchem Qualifizierungsaufwand? Mit welchem Migrationsaufwand?

Und noch ein paar andere Aspekte:
Nicht alle Schulen sind öffentliche Schulen. Steht dieser Service auch privaten und kirchlichen Schulen zur Verfügung? Zu welchen Konditionen? Hier in Bonn sind etwa 30 % der Schulen nicht in öffentlicher Trägerschaft. Bundesweit ist der Trend zu privaten Schulträgern stark.
Aus der Softwareperspektive ist SOA keine Bedrohung. Aber eine Lernplattform wie Moodle kann SOA unterstützen ohne sich darauf verlassen zu können, dass überall SOA-Architekturen existieren. Mir ist bisher keine Schule bekannt, die an einem kommunalen SOA-Netz hängt. Ein rein SOA-basiertes Moodle wäre als noch gar nicht einsetzbar.

Was tut sich in Version 1.9 für die Administration?

Für die Liebhaber der Oberflächengestaltung gibt es ein neues Theme mit runden Ecken. Praktisch zu sehen ist es bereits unter http://moodlemoot.de.

Nun ist es auch möglich zusätzlich zu den Kursbereichstiteln beschreibende Texte hinzuzufügen. In der aktuellen Developer-Version ist dies noch mit einem Fehler behaftet. Dieser wird aber in den nächsten Wochen noch eliminiert.

In der Sprachverwaltung werden nun standardmässig alle Änderungen automatisch in einer lokalen Sprachversion gespeichert. dadurch ist ein versehentliches Überschreiben beim Update nicht mehr möglich.

Der größte Produktivitätssprung entsteht jedoch in der Nutzerverwaltung. Die Funktion Bulkupload zum Import von Nutzern über eine CSV-Datei wurde wesentlich erweitert. Beim Import können standardmässig Profilfeldeinträge vordefiniert werden. Das manuelle Nacharbeiten bestimmte standardwerte, z.B. zum Mailversand, entfällt dadurch.

Besonders wichtig ist jedoch die Funktion beim Bulkupload auch Teilnehmer im System wieder zu löschen. dazu wird in der CSV Datei eine Spalte mit dem Wert “deleted” eingefügt. Der Eintragswert “1″ löscht einen Nutzer aus dem System.

Im Administrationsmenu gibt es dann nun auch eine erweiterte Suchfunktion für Nutzer mit der Möglichkeit Gruppen von Nutzern zu löschen.

Löschen bedeutet bei Moodle immer, dass ein Lösch-Kennzeichen in der Datenbank gesetzt wird. Der Nutzer kann sich somit nicht mehr einloggen.