Gedanken zu Mailadressen-Verschleierung

Vorweg: Ich diskutiere mit einem Kollegen grad das Thema “Mailadressen-Verschleierung” als Anti-Spam-Maßnahme. Den technischen Hintergrund dazu gibts auf techblog.tilllate.com.

> Die Frage ist nicht, ob sie [Anm.: die Spammer] theoretisch dazu in der Lage
> wären, sondern ob sie es [Anm.: das Dekodieren verschleierter Mail-Adressen]
> auch wirklich tun. :) Und scheinbar scheint der Trick das Spamaufkommen
> zumindest zu reduzieren.

Es ist richtig, dass es da einen Unterschied gibt. Allerdings sehe ich es nicht als Aufgabe eines Links an, Spam zu verhindern. Denkt man konsequent auf diesem Weg weiter müsste man ja zu dem Schluss kommen, dass es sinnvoll wäre, überhaupt keine E-Mail-Adressen mehr auf Websites zu schreiben, denn das würde Spam ja noch wirkungsvoller verhindern. Man führt so den Zweck des Internets, nämlich die Kommunikation — und die will man doch, ad absurdum.

Auch die in dem Blog-Post genannten Methoden finde ich ehrlich gesagt albern. Das sind alles nur Krücken. Was für Verrenkungen will man sich von Spammern denn noch aufzwingen lassen? Die ewig nervenden CAPTCHAs gehören für mich zur gleichen Kategorie, nur gibt es noch keine Alternative zu denen.

Spam zu verhindern ist die Aufgabe eines dedizierten Spam-Filters auf dem Mailserver. Nur so ist Spam einigermaßen wirkungsvoll beizukommen. So mache ich das seit über 10 Jahren und ich habe kein Problem mit Spam. Die Leute, die mir schreiben wollen, sollen das tun. Wie sie an die Mailadresse kommen ist mir egal, abschreiben, automatisiert auslesen… egal. Wenn mir jemand Spam schreibt, bleibt er im Spam-Filter hängen und fertig ist die Geschichte.

Maillink-Obfuscation macht auch mehr Probleme als dass sie welche löst. Insbesondere das Verschleiern mit Javascript. Was ist z.B., wenn ein Rechtsanwalt in Abmahn-Stimmung aufs Impressum geht, wo eine verschleierte Mailadresse steht und er “aus Prinzip” JavaScript abgeschaltet hat – schon gibts *aus seiner Sicht* einen Abmahngrund.

Computer und das Internet sind dazu da, den Menschen zu bereichern und ihm die Arbeit zu erleichtern. Mail-Adressen zu verschleiern macht dagegen nur unnötig Arbeit und macht nichts besser als ein guter Spam-Filter — daher mein Fazit: Nein zur Mailadressen-Verschleierung! :)

Elektronischer Datenaustausch: Lassen Sie uns das per CSV machen…

Ich bin immer wieder erstaunt darüber, wie oft ich auf Projekte stoße, bei denen Daten in völlig ungeeigneten Formaten elektronisch ausgetauscht werden oder werden sollen. Ohne nähere Spezifikation natürlich. CSV ist so ein Klassiker. Das läuft dann so:

Ich: “Wie sollen die Daten denn ausgetauscht werden?”

Kunde: “Per CSV.”

Ich: “Haben Sie eine genaue Spezifikation des Formats?”

Kunde: “???”

Es ist weiter kein Problem, wenn der Kunde sich von mir beraten lässt und wir dann eine geeignete Lösung finden. Bei CSV-Daten ohne Spezifikation ist natürlich Ärger vorprogrammiert. CSV-Daten kann man nicht vernünftig validieren, man kann keine Typen definieren und standardisiert ist es im Grunde auch nicht.

Auch der elektronische Datenaustausch via Excel- oder generell Office-Dateien ist problematisch, und ganz besonders dann, wenn der Austausch bidirektional ist. Aus eigener, schmerzhafter und zum Glück bereits etwas zurückliegender Erfahrung weiß ich, dass das nicht gut geht — außer man hat eine Middleware zur Verfügung, die das nachweislich kann und einfach in einen automatischen Prozess integriert werden kann.

Was sind geeignete elektronische Austauschformate?

Weitschweifige philosophische Betrachtungen, wie sich XML zu EDI verhält oder ob XML disjunkt zu EDI ist oder auch nicht, lasse ich hier mal außen vor. Darüber kann man nämlich lange streiten. Klassisches EDI ist bei meinen Kunden bislang kein Thema.

XML. XML. XML. XML. XML. Ein XML-Format ist bisher eigentlich immer meine Empfehlung gewesen. XHTML, RSS und ATOM sind wohl die derzeit am häufigsten eingesetzten XML-Formate. Es ist auch relativ einfach, selbst ein Format zu definieren, zum Beispiel per DTD oder XSD. XML ist flexibel, einfach zu definieren und zu validieren.

Ein Medienbruch zwischen zwei Systemen ist immer mit Kosten verbunden, egal ob nun CSV, Excel oder XML zum Einsatz kommt. Die Frage ist nur, mit welchem Format die Kosten am niedrigsten sind. Meine Erfahrung ist, dass ein Medienbruch mit einem vernünftig definierten XML-Format wesentlich kostengünstiger ist als mit einem anderen Format.

Noch kostengünstiger wäre es natürlich, Medienbrüche ganz zu vermeiden.

Online-Erlebnis bereichern — ohne den IE6

Slashdot meldet, dass Youtube seit kurzem offenbar Internet Explorer 6-Nutzern ein Banner anzeigt. Auf dem steht:

Führe ein Upgrade auf einen modernen Browser durch, um dein Online-Erlebnis zu bereichern. Der Support für Internet Explorer 6 wird nach und nach eingestellt. Führe am besten jetzt ein Upgrade durch.

Danach folgen Links — verständlich als zu Google gehörendes Unternehmen — zu Chrome, aber auch zum Internet Explorer 8 und zu Firefox 3.5.

Slashdot berichtet von “jubilation breaking out all over the Net”. Dem schließe ich mich spontan an.

Magento: Mail-Templates anpassen

Magento ist sehr flexibel und man kann vieles frei einstellen. Es gibt natürlich auch bei diesem Shop-System “Leichen im Keller”, die verwundern. Ein Beispiel dafür ist der Mail-Template-Editor, der ohne Vorkenntnisse schwer zu durchschauen ist.

Eine eine kurze Anleitung

Wenn man in Magento die Seite

System -> Transaktions-E-Mails

aufruft, sieht man zunächst rein gar nichts und wundert sich, wo nun die Templates abgeblieben sind.

Wo sind sie hin, die Vorlagen?

Im Prinzip ist das System einfach, wenn man sich an folgendes Paradigma hält:

Magento verfügt über eine ganze Reihe interner Mail-Vorlagen. Das sind die Standard-Vorlagen mit Magento-Logo und generischen Grußformeln. Diese Vorlagen werden immer benutzt, es sei denn, der Shop-Betreiber erstellt eigene und lässt Magento diese diese Vorlagen verwenden.

Vorgehensweise

Lassen Sie uns eine Bestellbestätigung anpassen.

Schritt 1: Rufen Sie den Mail-Vorlagen-Editor auf unter

System -> Transaktions-E-Mails

und klicken Sie auf “Neue Vorlage”. Unter Vorlage wählen Sie “New Order” oder “Neue Bestellung” und klicken auf “Vorlage laden”. Die Vorlage wird nun geladen und ist bereit für Ihre Anpassungen. Vor dem Speichern geben Sie der Vorlage noch einen eindeutigen Vorlagenamen. Die Vorlage wird dann oben rechts mit “Vorlage speichern” gesichert.

Schritt 2: Noch wird die Vorlage nicht automatisch verwendet. Man muss dem Shop nun mitteilen, dass er nicht die Standard-Vorlage, sondern eine angepasste verwenden soll. Unter

System -> Konfiguration -> Verkäufe -> Verkaufs-E-Mails -> Bestellung

finden Sie die Möglichkeit, das einzustellen. Bei “Neue Bestellbestätigung” wählen Sie den Vorlagennamen aus, den Sie für die eigene angepasste Vorlage verwendet haben und klicken dann auf “Konfiguration speichern”.

Das wars. Jedenfalls für eine Vorlage.

Torschlusspanik?

Was gestern und heute nicht alles in neuen Versionen erschienen ist: PHP, VirtualBox, Firefox, Netbeans, Mono, Python… Da sollten wohl Termine eingehalten werden.

OK, das kann ich auch: Scope, die “Haus-Suchmaschine” von Dr. Web, ist heute in der Version 2.0 online gegangen. Die neue Version wurde komplett neu geschrieben. Die wichtigsten Eigenschaften:

  • Scope ist nun ein WordPress-Plugin und
  • basiert auf Zend_Search und Lucene.
  • Der Index wird vollständig transparent verwaltet,
  • Suchergebnisse werden hervorgehoben und
  • können sortiert werden.
  • Der Neuaufbau des Index wurde um den Faktor 2 bis 3 beschleunigt.

Die alte Scope-Version hatte nun einige Jahre auf dem Buckel — da war es an der Zeit, mal ordentlich durchzupusten.

Ausprobieren kann man das neue Scope drüben bei Dr. Web.de mit seinen 4300+ Beiträgen und auch auf dieser Website.