E-Mail-Signaturen parsen
ohne den falschen Unterzeichner

Was der Signaturblock tatsächlich enthält

Eine Signatur ist ein kurzer Kontaktblock am Ende einer Nachricht, und kaum etwas an ihrem Aufbau ist standardisiert. Eine E-Mail hat sechs Teile, die für eine Extraktion relevant sind: den Header, die neue Nachricht, die Grußformel, den Signaturblock, einen etwaigen zitierten Verlauf und alles, was danach folgt. Der letzte Teil wird oft vergessen. Er kann ein Haftungsausschluss, ein Bannerbild, eine zitierte Antwort einer anderen Person oder gar nichts sein.

Nur ein Marker kann für sich beanspruchen, ein Standard zu sein: eine Zeile mit zwei Bindestrichen und einem Leerzeichen, der Usenet-Signaturtrenner, der im Jahr 2004 in RFC 3676 dokumentiert wurde. Er ist eine Konvention, keine Vorgabe, und viele Clients erstellen Signaturen ohne ihn. HTML macht die Grenze noch weicher. Eine als Tabelle gestaltete Signatur kann den Namen in einer Zelle, die Position in einer anderen und das Logo in einer dritten platzieren. Der Text ist vollständig vorhanden; die Lesereihenfolge entspricht dem, was der HTML-Quellcode vorgibt, und das ist nicht immer die Reihenfolge, die ein Mensch sieht.

Eine Signatur hat keinen vorgeschriebenen Eröffnungsmarker. Jede Extraktion muss raten, wo der Block beginnt.

Das Problem ist die Zuordnung, nicht der Musterabgleich

Der schwerwiegendste Fehler bei der Extraktion von E-Mail-Signaturen ist eine korrekte Signatur, die zu jemand anderem gehört. Vier Situationen führen zu diesem Ergebnis, und alle vier sind häufig genug, um sie einzuplanen.

Eine Antwortkette mit zwei Signaturen. Alice antwortet Bob. Ihre Nachricht steht oben; Bobs zitierte Nachricht und seine Signatur stehen darunter. Ein Parser, der den letzten Block nimmt, liefert Bob. Ein Parser, der den ersten Block nimmt, liefert Alice nur, wenn sie über dem Zitat geschrieben hat; hat sie darunter geantwortet, ist der erste Block ebenfalls Bobs. Beide Regeln sind positionsabhängig, und ein Thread gibt keiner der beiden Regeln eine stabile Position.

Ein gemeinsames Postfach oder eine Rollenadresse. Eine Adresse wie sales@ oder info@ kann von einer Person signiert sein, von einem Team-Block mit zwei Namen oder von einer Assistenz, die für eine Führungskraft schreibt. Ist Ihr Datensatzschlüssel die Absenderadresse, werden zwei Personen zu einem Kontakt. Ist Ihr Schlüssel der Name in der Signatur, wird eine Person zu zwei Kontakten, wenn sich das Namensformat ändert. In einem HubSpot Community-Thread von 2021 beschreiben CRM-Nutzer dasselbe Durcheinander: Die Anfrage kommt von einer generischen Adresse, die echten Kontaktdaten stehen im Textkörper, und jemand trennt die Person manuell vom Postfach (HubSpot Community).

Dasselbe Muster zeigt sich in E-Mail-Postfächern für Immobilien-Leads, wo eine Portal-Benachrichtigung und ein Anmeldeformular für einen Open House denselben Interessenten in zwei Formaten beschreiben.

Eine weitergeleitete Nachricht. „FYI, siehe unten“ enthält keine Signatur des Weiterleitenden. Die einzige Signatur im Textkörper gehört dem ursprünglichen Absender. Eine Zeile, die auf die Adresse des Weiterleitenden verweist, enthält nun die Telefonnummer von jemand anderem.

Nichts davon lässt sich durch ein besseres Muster beheben. Behoben wird es, indem Sie den Inhaber der Zeile vor der Extraktion festlegen: die Adresse der Nachricht, die verarbeitet wird, nicht der letzte Name im Textkörper. Wenn die Eingabe ein Thread ist, benötigen Sie außerdem die Nachrichtengrenze, nicht nur die Signaturgrenze. Namensformate erzeugen eine kleinere Version desselben Problems: Ein Header mit „J. Rivera“ und eine Signatur mit „Jordan Rivera, VP of Sales“ sind eine Person in zwei Formaten, und die Merge-Regel muss das wissen.

Ein Parser, der den letzten Block in einem Thread nimmt, liefert die zuletzt schreibende Person, nicht die Person, die die von Ihnen verarbeitete Nachricht gesendet hat.

Wo Regex versagt: Vier konkrete Fälle

Regex ist zuverlässig bei Feldern mit Interpunktion und unzuverlässig bei Feldern mit Bedeutung – und das betrifft den größten Teil einer Signatur. Teams, die E-Mail-Signaturen mit Regeln parsen, beginnen meist mit Telefonnummern, E-Mail-Adressen und URLs, weil diese Muster funktionieren. Die Fehler zeigen sich in den Zeilen drumherum.

Der Haftungsausschluss unter der Signatur. Ein Vertraulichkeitshinweis, ein eingetragener Firmenname und ein Firmensitz stehen oft unter dem eigentlichen Block. Eine Regel, die alles nach der Grußformel sammelt, liest den Hinweis als Adresse, und ein Suffix wie LLC oder GmbH darin kann als Firma erfasst werden. Ein semantischer Leser kann einen rechtlichen Hinweis von „Acme GmbH, Musterstrasse 1" trennen, weil der Hinweis ein Satz über die Nachricht ist und die Adresse ein Ort.

Die Telefonnummer, die zweimal auftaucht. Eine Textzeile kann „rufen Sie mein Mobil an" mit einer Nummer sagen, während die Signatur eine Festnetznummer, ein Fax und ein Mobil enthält. Ein Regex liefert den ersten Treffer, der eine Faxnummer oder eine in der Nachricht zitierte Kundennummer sein kann. Die Bezeichnung ist das Feld: Tel, Mobil, Fax oder 携帯 (Mobil auf Japanisch). Lassen Sie die Bezeichnung weg, liefert der Extraktor eine Nummer, ohne zu wissen, was sie ist.

Die Signatur, die nicht in englischer Reihenfolge steht. Englische Signaturen folgen meist Name, Position, Firma. Japanische Signaturen folgen Firma, Abteilung, Position, Name, oft ohne Leerzeichen zwischen den Wörtern. 部長 (Abteilungsleiter) ist eine Position, steht aber nicht in einem englischen Positionswörterbuch, und der Name wird möglicherweise mit Nachnamen zuerst geschrieben. Deutscher Geschäftsführer und französischer Directeur général erzeugen dieselbe Diskrepanz in umgekehrter Richtung. Eine Regel, die Großschreibung und ein Komma zwischen Position und Firma erwartet, hat nichts zum Abgleichen.

Der Block ohne Text oder fast ohne. Eine reine Bildsignatur enthält überhaupt keinen Text. Eine Telefonantwort kann nur „Gesendet von meinem iPhone" enthalten, was die Form einer einzeiligen Signatur hat und keines der Felder. Eine HTML-Tabelle kann die visuelle Reihenfolge von Name und Position umkehren, wenn Tags entfernt werden.

Ein clevereres Regex löst das nicht. Als Mailgun 2013 seine Talon-Bibliothek als Open Source veröffentlichte, nutzte es einen Machine-Learning-Klassifikator, um Signaturzeilen von Nicht-Signaturzeilen zu trennen. Bei einem Testset mit 2.912 Zeilen lag der Klassifikator bei 92 % korrekten Zeilen, was immer noch etwa eine von zwölf Zeilen falsch lässt (Mailgun). Das ist Zeilenklassifikation, keine Feldzuordnung. Forscher, die 2018 den HPI-E-Mail-Korpus annotierten, teilten Nachrichten in fünf Zonen auf, darunter die Signatur, weil die Aufgabe zuerst Segmentierung und dann Extraktion ist (Hasso Plattner Institute).

Regex liest Formen, keine Rollen. Eine Faxnummer und eine Mobilnummer haben dieselbe Form.

Welche Felder über Clients und Sprachen hinweg erhalten bleiben

E-Mail-Adresse, vollständiger Name, Unternehmen und Position bleiben in den meisten Signaturen erhalten; Telefon und Postanschrift bleiben nur erhalten, wenn der Extraktor die Bezeichnung beibehält, die sie identifiziert.

Das Muster ist einfach: Ein Feld bleibt erhalten, wenn seine Bedeutung aus einem Header oder einer Bezeichnung stammt, nicht aus seiner Position im Block. Eine Telefonnummer braucht ihre Bezeichnung; eine Postanschrift braucht ihre zusammengehaltenen Zeilenumbrüche.

Sprache ist der zweite Filter. Die eigene FAQ von SigParser reiht Englisch auf Platz eins, Deutsch auf Platz zwei, dann Spanisch, Französisch, Portugiesisch, Russisch und Niederländisch (SigParser). Das ist ein nützliches Eingeständnis: Viele Parser sind englisch-zentriert, und je weiter eine Signatur von englischen Konventionen abweicht, desto mehr verlässt sich das Tool auf ein allgemeines Sprachmodell statt auf eine Titelliste.

Die Original-Positionsbezeichnung behalten. Geschäftsführer während der Extraktion zu „Managing Director" zu übersetzen, ist eine Entscheidung, die Sie nicht rückgängig machen können, und sie kann für die rechtliche Rolle der Person falsch sein. Das Original speichern und später zuordnen.

Ein Header-Feld ist stabil, weil der Client es schreibt. Ein Signaturfeld ist nur stabil, wenn seine Bezeichnung erhalten bleibt.

Von einem Postfach zu einer Kontakttabelle

Die Tabelle entsteht in zwei Durchgängen: Eine Nachricht wird zu einer Zeile, dann werden die Zeilen nach E-Mail-Adresse unter einer expliziten Konfliktregel zusammengeführt. Beides gleichzeitig zu tun, lässt zwei Personen zu einem Kontakt verschmelzen. Die meisten Teams, die Kontaktdaten aus E-Mails extrahieren, beginnen mit dem zweiten Durchgang und stellen fest, dass der erste falsch war. Die Arbeit fällt meist einer Sales-Ops-Leitung oder einem CRM-Administrator zu und muss sowohl für den Vertriebsmitarbeiter, der die Mail weiterleitet, als auch für den Kontakt, dessen Daten gespeichert werden, Bestand haben.

Stille Konfliktbehandlung macht eine Kontakttabelle unglaubwürdig. Markieren Sie stattdessen die Zeile.

Wo ImageToTable.ai passt – und wo es endet

ImageToTable.ai kann den Extraktionslauf auf weitergeleitete Nachrichten ausführen und endet vor den Teilen, die einen Mailbox-Crawler oder ein CRM erfordern. Der Verarbeitungsmodus entscheidet, ob es funktioniert.

Email Inbox gibt jedem Konto eine eigene Adresse. Sie leiten eine Nachricht dorthin weiter oder richten in Gmail oder Outlook eine Regel ein, die passende Mail weiterleitet. Das Postfach hat drei Verarbeitungsmodi: nur Anhänge, nur Textkörper und Anhänge plus Textkörper. Für Signaturarbeit ist „nur Textkörper" der relevante, denn die Signatur steht in der Nachricht, nicht in einer Datei.

Als Nächstes folgt Custom Column Extraction: Sie geben die gewünschten Spaltennamen ein, und die AI findet jeden Wert anhand der Bedeutung. Die Namen werden zu den Überschriften der Ausgabetabelle. Für eine Signatur bedeutet das vollständiger Name, Position, Unternehmen, Festnetz und Mobil, wobei der Spaltenname vorgibt, dass der Wert aus dem Signaturblock des Absenders stammen soll, nicht aus einem zitierten. Jede Nachricht wird eine Zeile. Ergebnisse lassen sich als Excel, CSV oder JSON exportieren, und das Google-Sheets-Add-on schreibt Zeilen in das geöffnete Sheet, sodass das Zusammenführen dort geschieht, wo die Liste bereits liegt.

Der Review-Modus lässt Sie eine Zeile öffnen, eine Zelle prüfen, den ursprünglichen Wert der AI sehen und eine Änderung zurücknehmen. Er ist die manuelle Prüfung für die Zeilen, die die Merge-Regeln markieren, und günstiger als den Fehler erst nach einem Import zu entdecken.

Drei Grenzen sind wichtig. Es gibt keine Postfachanbindung und keinen historischen Crawl: Das Tool liest, was Sie ihm senden, nicht die letzten zehn Jahre eines Gmail-Kontos. Es gibt keinen garantierten Signaturblock-Erkenner: Es liest die Nachricht und füllt die von Ihnen benannten Spalten, was bedeutet, dass ein weitergeleiteter Thread mit drei Signaturen weiterhin ein Dokument ist und die Zuordnung schiefgehen kann. Und es gibt keine Deduplizierung oder CRM-Synchronisierung: Zwei Nachrichten derselben Person ergeben zwei Zeilen, sofern Sie sie nicht zusammenführen. Die Ausgabe ist eine Tabelle, kein Kontaktdatensatz.

Dasselbe Feldproblem tritt auf Papier auf: Ein Visitenkartenfoto ist ein Signaturblock ohne die E-Mail drumherum.

Die Datenschutzregeln, die Sie übernehmen

Eine geschäftliche E-Mail-Adresse, eine Position und eine Durchwahl sind in der EU und im UK personenbezogene Daten, daher übernimmt die Kontakttabelle eine Rechtsgrundlagen- und Aufbewahrungspflicht. Dass die Daten in einer geschäftlichen E-Mail sichtbar waren, bedeutet nicht, dass Sie sie einfach behalten dürfen.

Viele Teams stützen sich bei geschäftlichen Kontaktdaten auf berechtigte Interessen. Die Leitlinien des ICO besagen, dass Geschäftskontakte eher erwarten, dass ihre beruflichen Angaben verarbeitet werden, doch die Rechtsgrundlage ist nicht automatisch gegeben: Sie benötigen eine dokumentierte Abwägung der berechtigten Interessen, einen Erforderlichkeitstest und einen Abwägungstest. Das Widerspruchsrecht ist bei Direktwerbung absolut, das heißt ein Widerspruch muss die Tabelle erreichen, nicht nur der Abmeldelink in einer Kampagne (ICO).

Datenminimierung ist der praktische Teil. Erfassen Sie die Felder, die Sie verwenden werden, nicht jedes Feld, das die Signatur bietet. Eine private Mobilnummer und ein Social-Media-Profil sind für die Weiterleitung eines B2B-Kontakts nicht erforderlich, und ihre Speicherung erhöht die Kosten eines Löschantrags. Halten Sie das Quelldatum fest, legen Sie eine Aufbewahrungsfrist fest und stellen Sie sicher, dass der Postfachinhaber von der Tabelle weiß. Wenn Sie Kontakte für einen Kunden verarbeiten, müssen Vertrag und Datenschutzhinweis dies abdecken. Dies ist eine Checkliste, keine Rechtsberatung.

Erfassen Sie die Felder, die Sie verwenden werden, dokumentieren Sie ihre Herkunft und löschen Sie sie, wenn der Grund entfallen ist.

FAQ

Kann man E-Mail-Signaturen mit Regex parsen?

Für E-Mail-Adressen, Telefonnummern und URLs ja. Für Namen, Positionen und Firmennamen nicht zuverlässig. Regex kann die Form eines Werts erkennen, aber nicht unterscheiden, ob eine Zeile eine Position oder eine Abteilung ist, ob eine Nummer ein Fax oder ein Mobil ist oder ob der Block zum Absender oder zu einer unten zitierten Person gehört.

Warum wählt ein Parser die falsche Person aus einem Thread?

Weil ein Thread mehr als eine Signatur enthält und eine positionsbasierte Regel kein Konzept für Nachrichtenbesitz hat. Der letzte Block gehört meist der letzten Person, die geschrieben hat – das kann die zitierte Person sein, nicht die Person, deren Nachricht Sie verarbeiten. Leiten Sie eine Nachricht pro Zeile weiter, wenn die Zuordnung wichtig ist.

Welche Felder kann ich zuverlässig aus einer E-Mail-Signatur extrahieren?

E-Mail-Adresse, vollständiger Name, Firma und Position sind der zuverlässige Kern. Telefon ist nur zuverlässig, wenn die Bezeichnung erhalten bleibt, verwenden Sie also getrennte Spalten für Festnetz, Mobil und Fax. Eine Postanschrift ist das unzuverlässigste Feld, weil Zeilenreihenfolge und Position der Postleitzahl je nach Land variieren.

Funktioniert die Signaturanalyse für Japanisch, Deutsch oder Arabisch?

Das hängt davon ab, ob das Tool Bedeutung liest oder englische Muster abgleicht. Japanische Signaturen folgen oft Firma, Abteilung, Position, Name ohne Leerzeichen, und Titel wie 部長 fehlen in englischen Titellisten. Deutsche und französische Titel haben dasselbe Problem umgekehrt, und Rechts-nach-links-Schriften brechen die Annahmen zur Zeilenreihenfolge. Ein semantisches Modell kommt damit besser zurecht als eine Stichwortliste, aber die Ausgabe muss trotzdem geprüft werden.

Kann ImageToTable.ai mein ganzes Postfach scannen?

Nein. Es verarbeitet Nachrichten, die Sie an Ihre E-Mail-Postfach-Adresse weiterleiten, oder Mail, die durch eine Weiterleitungsregel dorthin geleitet wird. Es gibt keine Postfachverbindung, keinen historischen Crawl und keinen Zugriff auf Mail, die Sie nicht weitergeleitet haben.

Ist es legal, Kontaktdaten aus E-Mail-Signaturen zu speichern?

In der EU und im UK in der Regel unter berechtigten Interessen, wenn Sie die Bewertung dokumentieren, nur erheben, was Sie brauchen, eine Aufbewahrungsfrist festlegen und Widersprüche beachten. Widersprüche gegen Direktwerbung sind absolut. Außerhalb der EU und des UK gelten andere Regeln, prüfen Sie also die Jurisdiktion Ihrer Kontakte.

Die Signatur ist eine Konvention, kein Formular

Eine Signatur wurde entworfen, um eine Nachricht höflich zu beenden, nicht um eine Datenbank zu füllen. Deshalb hat der Block keine zuverlässige Markierung und deshalb kann dieselbe Person über fünf E-Mails wie zwei Datensätze aussehen. Der Extraktionsschritt lässt sich automatisieren; die Entscheidung, wem eine Zeile gehört und welcher Wert aktuell ist, bleibt eine Einschätzung zum Postfach.

Senden Sie eine weitergeleitete E-Mail mit einer Signatur, die Sie kennen, benennen Sie die Spalten, die Sie tatsächlich brauchen, und prüfen Sie, ob die Zeile der erwarteten Person gehört. Der erste falsche Unterzeichner ist dort günstiger zu finden als in einem CRM-Import.

An einer E-Mail testen