Dead Letter Email Validator API + Plugin

  • Hallo,


    ich freue mich, euch über die aktuellste Entwicklung unterrichten zu dürfen: Dead Letter Email Validator API


    Was ist das?


    Im Rahmen einiger Experimente vergangener Tage, habe ich eine API entwickelt, mit deren Hilfe sich E-Mail-Adressen auf Plausibilität (Gültigkeit) prüfen lassen. Außerdem wird anhand einer Datenbank (die sich anhand verschiedener Faktoren semi-automatisch selbst pflegt) versucht festzustellen, ob es sich einer angegebenen E-Mail-Adresse um eine Wegwerf-Adresse handelt, oder nicht. Last, but not least wurde StopForumSpam in die Schnittstelle eingearbeitet, sodass man neben den genannten Checks auch prüfen kann, ob es sich um eine bekannte Spam-E-Mail-Adresse handelt.


    Was kostet es?


    Nichts. Zwar habe ich anfänglich überlegt, zumindest gewisse Einschränkungen zu definieren, allerdings ist die API noch viel zu ungetestet, als dass ich für die Nutzung irgendetwas verlangen sollte. Wer sich dennoch finanziell einbringen möchte, darf dies gerne hier tun.


    Die Multihunter-Erweiterung für das WCF / WSC kann das mit den Wegwerf-Adressen doch schon?


    Korrekt. Allerdings gibt es hier zwei wesentliche Unterschiede zwischen der Multihunter-Integration und meiner API:

    • Für die Nutzung entstehen euch keinerlei Kosten.
      Da es sich bei dem Multihunter um ein kommerzielles Produkt handelt, müsst ihr zumindest einmalig zahlen, um ein derartiges Feature nutzen zu können.
    • Die Datenbank umfasst nur wenige Tage nach Start des Projektes bereits 5123 Domains von Wegwerf-E-Mail-Anbietern.
      Das sind 4197 Domains mehr als vom Multihunter derzeit erkannt werden.


      Zudem lernt die hier genannte API selbst, wogegen beim Multihunter sämtliche neuen Domains händisch eingepflegt und gewartet werden müssen.

    Wie kann ich es nutzen?


    Für diese API (und weitere, künftige Projekte dieser Art) nutze ich das Entwickler-Portal Mashape. Diese stellen unter Mashape - Free API Management Platform & Marketplace eine Platform zur Verfügung, über die man sowohl kostenpflichtige, als auch kostenfreie (free + freemium) APIs "konsumieren" kann. Dazu ist lediglich eine kostenlose, in wenigen Sekunden durchgeführte Registrierung unter https://market.mashape.com/signup notwendig.


    Nach der Registrierung (und einer eventuellen Aktivierung per Mail-Link) findet ihr die API unter https://market.mashape.com/sof…ad-letter-email-validator die hier beschriebene API, die ihr auf dieser Seite ausprobieren und konsumieren könnt.


    Kann man das Ganze vorher testen?


    Auch das ist möglich. Wer bei Mashape registriert ist, kann die API direkt dort ausprobieren. Wer das Ganze lieber vorher testen möchte, kann dies unter https://www.dead-letter.email/docs/api/endpoints tun, wobei es hier im "Demo-Modus" ein paar Einschränkungen gibt, damit niemand auf dumme Gedanken kommt ;)


    Wie kann ich das Ganze im WCF / WSC nutzen?


    Wie der Themen-Titel erahnen lässt, gibt es für das WCF bzw. WSC eine Erweiterung, die die API zumindest partiell (d.h. ohne Verwendung der StopForumSpam-Integration - aus Gründen) integriert. Diese Erweiterung gibt es zum gegenwärtigen Zeitpunkt allerdings noch nicht zum Download. Dies sollte aber in Kürze der Fall sein. Wenn es soweit ist, erfahrt ihr es natürlich sofort :) Bis dahin könnt ihr euch allerdings auch schon den benötigten API-Schlüssel bei Mashape abholen, da dieser für den Einsatz der Erweiterung zwingend notwendig sein wird.


    Kann ich das Ganze auch für ein Nicht-WoltLab-basiertes Projekt (z.B. Wordpress) nutzen?


    Selbstverständlich. Es handelt sich hier um eine "handelsübliche" JSON-API, die in so ziemlich jeder Programmiersprache angesprochen werden kann (sogar via Javascript - Hoffe ich ^^). Ich habe zudem ein nutzungsfertiges Beispiel in PHP auf Basis der Unirest-Library veröffentlicht. Dieses findet ihr unter https://github.com/SoftCreatR/…etter-email-validator-php


    --


    Ich würde mich freuen, euch bald als Konsumenten dieser API bei Mashape begrüßen können zu dürfen. Feedback ist selbstverständlich auch erwünscht.

  • Guten Morgen,


    ich habe die API soeben (unter Anderem) um einen Blacklist-Check erweitert. Bei einer (nicht zwischengespeicherten) Abfrage werden die gängigsten Blacklist-Server wie etwa CBL und Spamhaus abgefragt. Dadurch hat man nun einen weiteren Indikator für potentielle Spammer. Außerdem werden ab sofort auch die IP-Adressen der jeweiligen MX-Server zurückgegeben (sowohl ipv4, als auch ipv6).

  • Hallo,


    es wurden drei neue Properties hinzugefügt:

    • isCatchAll
      Impliziert, ob es sich hierbei um eine Catch-All-Adresse handelt, oder nicht.


    • isDeliverable
      Impliziert, ob E-Mails (nach intern durchgeführtem MX- und SMTP-Test) zustellbar sind, oder nicht.
      Diese Information könnte auch dazu verwendet werden, abgelaufene E-Mail-Konten von Mitgliedern ausfindig zu machen und diese dann ggf. zu deaktivieren, bis eine neue E-Mail-Adresse bestätigt wurde. Beachtet, dass dieser Wert nicht zu 100% akkurat sein MUSS. Zwar ist davon auszugehen, dass E-Mails an nicht erreichbare SMTP- bzw. MX-Server nicht zustellbar sind (wenn auch nur temporär, z.B. bei Ausfall eines normalerweise laufenden SMTP-Servers), allerdings kann es umgekehrt immer noch passieren, dass E-Mails nicht zugestellt werden können (z.B. bei vollen Postfächern, etc.).


    • isGibberish
      Impliziert, ob der lokale Teil (vor dem @) einigermaßen Sinn macht. Um dies zu ermitteln, wird eine sog. Markow-Kette angewandt.

    Zudem wurde ein Fehler behoben der dazu führte, dass reine MX-Hosts (d.h. keine A- oder AAAA-Records, aber MX, z.B. upcmail.nl) nicht korrekt erkannt- und stattdessen als "nicht gefunden" deklariert wurden.


    Bitte beachtet, dass die Demo stark eingeschränkt ist. Wer die API in vollem Umfang nutzen bzw. testen möchte, benötigt einen kostenfreien Mashape-Account und kann die API hier vollkommen uneingeschränkt verwenden.

  • Guten Morgen,


    die API ist umgezogen. Das macht aber nichts, da sich am API-Endpoint (https://dl.p.mashape.com) nichts geändert hat. Die neue URL lautet https://www.dead-letter.email.


    Bei Zeiten baue ich noch eine ordentliche Webseite mitsamt Doku drumrum.

  • Hallo,


    die Webseite steht nun. Ich werde zeitnah eine brauchbare Dokumentation verfassen. Im Anschluss daran kommt die WoltLab - Erweiterung. Was ich auch noch gedenke einzuführen ist ein Formular zum Beantragen von Delistings, sollte ein Host mal fälschlicherweise als Wegwerf-Anbieter deklariert sein.


    Außerdem habe ich noch 5 weitere Blacklists hinzugefügt.


    Dead Letter Email Validator | dead-letter.email

  • Hallo,


    leider dauert das Verfassen der Dokumentation doch etwas länger, als erwartet, da ich durch steigende Anforderungen immer mal wieder Änderungen an der gesamten Webseite vornehmen musste. Jetzt sollte es allerdings vorwärts gehen und bald fertig sein.


    Es gab an der API eine nicht-rückwärts-kompatible Veränderung (welche auch entsprechend dokumentiert ist):


    Alle für die jeweilige API-Anfrage relevanten Properties wurden in data gruppiert, d.h.:


    Vorher:

    Code
    1. {
    2. "apiVersion": 1,
    3. "knownHosts": 5132,
    4. "lastUpdate": "2017-07-06T13:16:19+02:00"
    5. "status": 200,
    6. "links": {
    7. "self": "https://dl.p.mashape.com/stats"
    8. }
    9. }

    Nachher (aktuell):

  • Guten Abend,


    der Groß- und zeitgleich wichtigste Teil der Dokumentation ist fertig und kann ab sofort unter API Documentation: Getting Started | dead-letter.email bewundert werden.


    Im Zuge dessen gab es auch wieder eine Neuerung innerhalb der API: Die Property location innerhalb des host-Blocks wurde um eine Vielzahl weiterer Informationen erweitert:


    Code
    1. countryCode
    2. countryName
    3. regionCode
    4. regionName
    5. city
    6. zipCode
    7. timeZone
    8. latitude
    9. longitude
    10. metroCode

    Wer's braucht :P

  • Hallo,


    ich bin gerade dabei, die Seite vollständig statisch zu machen und dann auf Cloudfront auszulagern. Durch die notwendigen Umbauten kann es vereinzelt zu Darstellungsfehlern kommen. Dafür wird das Ganze am Ende aber unbeschreiblich schnell.


    Danach verschiebe ich die Api auf einen anderen Server, da die TFFB doch recht hoch ist, was zu unnötig verlängerter Antwortzeit führt, welche zumindest für eine derartige API eher ungünstig ist.

  • Hallo,


    da es seit Donnerstag kein Update mehr gab, dachte ich, ich könnte mich ja nun mal wieder melden :) Da die API allerdings noch nicht aktiv genutzt wird, spare ich mir etwaige Changelogs und komme direkt zum wichtigen Teil: Die Webseite ist fertig!


    Wie schon öfter erwähnt, war das Ganze nie wirklich als großes Projekt geplant, sondern eher als kleine API wie etwa die SteamID-API oder dergleichen gedacht. Allerdings kam es ganz anders und nachdem ich nun mehrere Tage mit der Dokumentation und der "Sandbox" zugebracht habe, bin ich froh darüber, dass ich mir die Mühe gemacht habe. Denn auf lange Sicht hat das Projekt durchaus Potenzial, auch weit außerhalb der WoltLab-Welt erfolgreich und zielführend eingesetzt zu werden. Und wer weiß, ob das Ganze am Ende nicht sogar noch gewinnbringend ist.


    Jetzt, wo das Ganze so weit fertig ist, kann ich mich an die Umsetzung bzw. Fertigstellung der Erweiterung machen. Je nachdem, was mir hier noch einfällt, könnt ihr euch ab dem Zeitpunkt der Installation effektiv vor Nutzern von Trash-Mail-Anbietern schützen. Ob und welche zusätzlichen Features ich noch einbauen werde, weiß ich zum gegenwärtigen Zeitpunkt nicht.


    Was ich allerdings weiß ist, dass ich mich im Anschluss auch an die Umsetzung einer Wordpress-Erweiterung versuchen werde. Mal schauen, wie's wird =)


    Wie initial bereits geschrieben, kann das Ganze ohne vorherige Registrierung vollkommen unverbindlich ausprobiert werden. Besucht dazu die Seite API Documentation: Endpoints | dead-letter.email. Dort findet ihr auch Verweise zum Rest der Dokumentation.

  • Hallo,


    entgegen meiner ursprünglichen Planung habe ich die API nun doch noch etwas erweitert:


    sfsAppearance ist ab sofort eine collection und kein boolean mehr, d.h. es gibt bei Vorkommnissen in der StopForumSpam-Datenbank ab sofort weiterführende Informationen:

    • appears : Impliziert, ob die gesuchte E-Mail-Adresse bei StopForumSpam gelistet ist, oder nicht.
    • frequency : Impliziert, wie häufig die gesuchte E-Mail-Adresse innerhalb der letzten 365 Tage gemeldet wurde.
    • lastseen : Impliziert das Datum der letzten Meldung.
    • confidence : Ein "Risiko-Score" auf Basis der Anzahl der Reports innerhalb der letzten 365 Tage und dem Datum des letzten Reports (siehe auch Konfidenzintervall für die Erfolgswahrscheinlichkeit der Binomialverteilung – Wikipedia)
  • Jetzt wäre das WBB Addon interessant, um das ganze mal live im Einsatz zu erleben :D

  • Unterm Strich wird die Erweiterung nur einen Bruchteil der Informationen verwerten, die zur Verfügung stehen.


    Zudem stört mich an der API die Geschwindigkeit, sodass ich wohl noch die Moeglichkeit einführen werde, gewisse Checks deaktivierbar zu machen.

  • Unterm Strich wird die Erweiterung nur einen Bruchteil der Informationen verwerten, die zur Verfügung stehen.

    Hauptsache es gibt die Möglichkeit auf die Emails zurück zu greifen.
    Oder wie stellst du dir das vor?


    Was für Infos meinst du sollten nicht im WBB gezeigt werden?
    Aber doch sicherlich wenn man sich bei dead letter mail einloggt?

  • Intention der API ist und war hauptsächlich die Erkennung von Nutzern von Wegwerf-Adressen. Grund dafür, diese nicht zuzulassen, kann vorallem Sicherheit sein, da es sich um öffentlich- und für Jedermann zugängliche Postfächer handelt. Wenn da mal (ausschließlich für den jeweiligen Benutzer bestimmte) Zugangsdaten hingehen, ist das eher ungünstig.


    Das Plugin wird also zumindest die Aufgabe übernehmen, Nutzer derartiger Dienste zu erkennen und den Admin darüber zu informieren oder - bei Bedarf - die Registrierung nicht zuzulassen.


    Vorher muss ich allerdings größere Umstellungen bei der API vornehmen, da das aktuell noch zu viel Arbeit mit Flatfiles an Stelle einer Datenbank ist.

  • Das Plugin wird also zumindest die Aufgabe übernehmen, Nutzer derartiger Dienste zu erkennen und den Admin darüber zu informieren oder - bei Bedarf - die Registrierung nicht zuzulassen.

    Klingt doch ganz gut !;)

  • Guten Morgen,


    nachdem ich nun fast den ganzen vergangenen Tag dafür aufgebracht habe, die API zu optimieren und so viele Informationen wie möglich in eine Datenbank auszulagern (bzw. von dort zu beziehen), gibt es eine kleine Neuerung:


    Durch Setzen des Parameters serverchecks kann bestimmt werden, ob zusätzliche Server-Checks (MX/SMTP/Catch-All) durchgeführt werden sollen, oder nicht. Da diese Überprüfungen mehr als 50% der gesamten Ladezeit der API in Anspruch nehmen, kann durch Deaktivieren dieser Überprüfungen ein signifikanter Zeitgewinn erreicht werden.


    Auch neu ist der Parameter socialvalidation, der bei Bedarf dafür sorgt, dass soziale Profile (z.B. Gravatar) nicht validiert bzw. abgefragt werden. Auch durch Deaktivierung dieser Funktion kann etwas Zeit gespart werden.


    Bei allen anderen Funktionen konnte ich keine großen Geschwindigkeitsprobleme feststellen. Dies ist u.A. dadurch begründet, dass beispielsweise Geodaten & StopForumSpam intern auf dem Server abgefragt werden und durch Verwendung lokaler Datenbanken keinerlei externe Kommunikation stattfindet. Sollte ich dennoch irgendetwas finden, was signifikante Performance-Einbußen verursacht, werde ich auch dies entweder gänzlich deaktivieren oder optional deaktivierbar machen. Spätestens mit V2 der API lässt sich sowieso nahezu jede einzelne Funktion deaktivieren.


    Die neuen Parameter stehen ab sofort auch in der Sandbox zur Verfügung und sind hinreichend dokumentiert.