EmailAddressExtractor

Der E-Mail-Adressextraktor „Have I Been Pwned“.

Ein Projekt zum schnellen Extrahieren aller E-Mail-Adressen aus allen Dateien in einem bestimmten Pfad

Hintergrund

Dieses Projekt soll eine brandneue Open-Source-Version einer grundlegenden Codebasis sein, die ich fast ein Jahrzehnt lang verwendet habe, um E-Mail-Adressen aus Datenschutzverletzungen zu extrahieren, bevor ich sie in HIBP lade. Die meisten Verstöße liegen im .sql- oder .csv-Format vor, entweder in einer einzelnen Datei oder in mehreren Dateien in einem Ordner, und die Extraktion erfolgt nach einem einfachen Prozess:

1. Extrahieren Sie alle Adressen per Regex
2. Wandeln Sie sie in Kleinbuchstaben um
3. Ordnen Sie sie alphabetisch
4. Speichern Sie sie in einer Ausgabedatei
5. Erstellen Sie einen Bericht darüber, wie viele eindeutige Adressen in jeder Datei enthalten waren

Der von mir verwendete reguläre Ausdruck lautet wie folgt: b[a-zA-Z0-9.-_+]+@[a-zA-Z0-9.-_]+.[a-zA-Z]+b

Die Validierung von E-Mail-Adressen per Regex ist schwierig, muss aber für diesen Anwendungsfall auch nicht perfekt sein. Fehlalarme sind äußerst selten und die Auswirkung ist vernachlässigbar, nämlich dass eine Zeichenfolge, die keine echte Adresse ist, in HIBP geladen wird oder dass eine echte Adresse in einem ungewöhnlichen Format geladen wird. Im Großen und Ganzen lässt sich dieser reguläre Ausdruck wie folgt zusammenfassen: „Auf beiden Seiten eines @-Symbols eine TLD aus Alpha-Zeichen einfügen“.

Praktische Überlegungen

Bei der Betrachtung von Parsing-Regeln hat die Diskussion unweigerlich dazu geführt, dass die Einhaltung von RFC im Vergleich zur praktischen Verwendung bestimmter Zeichen steht. Hier gibt es zwei Hauptüberlegungen:

1. Wenn der RFC ein Zeichen wie ein doppeltes Anführungszeichen zulässt, sollte es als gültiges Zeichen betrachtet und in Adressen zulässig sein
2. Es ist wahrscheinlicher, dass ein Zeichen wie ein doppeltes Anführungszeichen aufgrund eines Analysefehlers vorhanden ist und nicht aufgrund einer legitimen Verwendung

Anekdotischerweise ist Punkt 1 im Vergleich zu Punkt 2 selten wahr. Die fälschliche Ablehnung einer legitimen, spezifikationskonformen Adresse hat zur Folge, dass sie nicht in HIBP landet (dh geringe Auswirkungen). Das Zulassen von Adressen, die tatsächlich nicht existieren, hat zur Folge, dass Junk-Datensätze in HIBP eingeführt werden (ebenfalls geringe Auswirkungen). Insbesondere wenn man die Wahrscheinlichkeit berücksichtigt, dass eine Adresse mit unklaren Zeichen praktisch verwendet wird (z. B. in ein Registrierungsformular aufgenommen und nicht abgelehnt), ist es insgesamt vorzuziehen, Zeichen abzulehnen, die wahrscheinlich auf Analysefehler zurückzuführen sind.

1. Beim Extrahieren von Adressen

Realistisch gesehen ist es unwahrscheinlich, dass in E-Mail-Adressen obskure Muster verwendet werden

Beiträge

Ich habe Kontakt aufgenommen und um Unterstützung gebeten und werde die Dinge über ein oder zwei Schlüsselpersonen in Gang bringen und dann um breiteren Input bitten. Ich bin besonders daran interessiert, den Dienst für größere Datensätze und nicht textbasierte Dateien zu optimieren, insbesondere angesichts der steigenden Zahl von Dokumenten, die von Ransomware-Teams abgelegt werden. Ich werde damit beginnen, Issues für die Teile zu erstellen, die erstellt werden müssen.

Testdaten

Unter Verwendung des SQL-Datengenerators von Red Gate steht eine Beispieldatei mit 10 Millionen Datensätzen typischer Sicherheitsverletzungsdaten zum Download bei Mega zur Verfügung. Diese Datei führt dazu, dass mit der aktuellen Version dieser App genau 10 Millionen E-Mail-Adressen extrahiert werden. Hinweis: Die Testdatendatei befindet sich derzeit in Version 2, wobei die frühere Version aufgrund des Vorhandenseins ungültiger Domänennamenmuster zu etwas weniger als 10 Millionen eindeutigen Adressen führt.

Ausführen des Adressextraktors

Syntax: AddressExtractor.exe -? Syntax: AddressExtractor.exe -v Syntax: AddressExtractor.exe <input [[... input]]> [-o output] [-r report]

Hauptoptionen

Option	Beschreibung
-? , -h , --help	Druckt die Befehlszeilensyntax und -optionen
-v , --version	Druckt die Versionsnummer der Anwendung
Eingang	Ein oder mehrere Eingabedateinamen oder -verzeichnisse
-o , --output Ausgabe	Pfad und Dateiname der Ausgabedatei. Standardmäßig ist „addresses_output.txt“
-r , --report Bericht	Pfad und Dateiname der Berichtsdatei. Standardmäßig ist „report.txt“
--recursive	Aktivieren Sie den rekursiven Modus für Verzeichnisse, der untergeordnete Verzeichnisse durchsucht
-y , --yes	Bestätigen Sie automatisch die Aufforderung zum WEITER, ohne zu fragen
-q , --quiet	Mit weniger Ausführlichkeit ausführen, Fortschrittsmeldungen werden nicht angezeigt

Leistung/Debugging

Option	Beschreibung
--debug	Aktivieren Sie den Debug-Modus für eine fein abgestimmte Leistungsprüfung
--threads num	Verwendet mehrere Threads mit Kanälen zum Lesen aus Dateien. Standardmäßig ist 4
--skip-exceptions	Fordert automatisch „WEITER“ auf, wenn eine Ausnahme auftritt