Neu TrackingMailProvider - anonymisierte Mails für DPD, DHL, & Co.

[Xantiva]

@Rico Giesler Falls das Posting nicht erwünscht ist, dann sorry und bitte löschen ...

Im Forum bin ich gerade wieder über zwei Beträge gestolpert bei denen es um die Weitergabe der Kunden-Mailadressen an den Versanddienstleister geht. Aktuell ist DPD unser Versanddienstleister, wir verwenden DPD Predict, somit hatten wir mit Einführung der DSGVO auch das Problem, was machen wir mit den Mailadressen?

Ich habe eine Lösung für uns entwickelt, so dass die Versanddienstleister nur eine anonyme Mailadresse bekommen und wir die Tracking-Mails an unsere Kunden weiterleiten. Ich bin im Sellerforum immer mal wieder angesprochen worden, ob ich das nicht weitergeben würde und habe daher meine Anwendung seit einiger Zeit als Open-Source Programm veröffentlicht:

TrackingMailProvider

Die Anwendung ist unabhängig von einer Wawi oder einem vergleichbaren System - Ihr müsst nur in der Lage sein, in Eurem System die Mailadresse zu erzeugen und in eine Textdatei zu exportieren. Dazu wird noch ein Catch-All Mailkonto benötigt. Mehr Details und ein Beispiel, wie das mit der JTL-Wawi umgesetzt werden kann, findet Ihr im Wiki.


Ciao,
Mike

 

[NETZdinge.de]

Eine sehr interessante Lösung, wie ich finde! Danke !

 

[m.toene]

Ich als Privatmensch fand das so Genial ... habe dir gerade 1€ gespendet

 

[gboehm]

Auch für mein Posting gilt @Rico Giesler, falls nicht gewünscht, bitte Bescheid geben und/oder löschen...

Das ist ja interessant! Ich habe vor ein paar Monaten für uns etwas ähnliches auf Basis eines Python Skripts realisiert.
Das Prinzip ist das gleiche. Es wird eine E-Mail Adresse im Format <auftragsnummer>@<meine domain> an den Logistiker weitergegeben. Antworten landen in einem Catchall Postfach.

Was macht das Skript:

• Es greift sich diese E-Mails aus dem catch all Postfach
• prüft ob der Absender in einer Whitelist steht, zB dhl.de - damit möchte ich verhindern, dass versehentlich Spam Mails an Kunden weitergeleitet werden
• fragt direkt die Wawi Datenbank nach der original Kunden E-Mail Adresse ab
• orig. Logistiker E-Mail wird dann an diese, sowie an eine BCC Adresse gesendet
  • warum auch an eine BCC?
    • ich möchte immer sehen, welche E-Mails rausgehen
    • für den Fall, dass ein Kunde sich beschwert, dass ich seine E-Mail Adresse unberechtigterweise weitergegeben hätte, kann ich mit der BCC nachweisen, dass es nicht so war. Evtl. auch wichtig, falls einem ein Datenschutzbeauftragter ans Bein pi.... will.

Voraussetzungen für das Skript:

• Python 3.5
• diverse Python Module (einfach schauen, was im Skript ganz oben importiert wird und mit "pip install <modul-name>" installieren)
• ODBC Verbindung zur Wawi

Das sollte es gewesen sein. Das Skript läuft auf meinem Wawi Server per Aufgabenplanung alle 30 Minuten und verrichtet fröhlich und zuverlässig seinen Dienst.

Folgendes Problem gibt es, mit dem auch die Lösung von Xantiva zu kämpfen hat. Wenn man die E-Mail Adresse der Lieferanschrift entsprechend ändert, kann es zu Problemen kommen, wenn man die Funktion Nachricht an Kunden aus der Verkaufsübersicht verwendet. Durch einen Bug (https://issues.jtl-software.de/issues/WAWI-35612) wird die E-Mail unter Umständen an die geänderte E-Mail Adresse aus der Lieferanschrift gesendet.

Ich hänge mal mein Skript für interessierte hier an. Konfiguration erfolgt über eine ini Datei und sollte weitestgehend selbsterklärend sein.

Disclaimer: Ich bin kein Programmierer. Also nicht schlagen, wenn es nicht optimal kodiert ist. Benutzung auf eigene Verantwortung

Edit: weiter unten gibt es eine lauffähige Exe, die keine Python Umgebung mehr benötigt. Den Quellcode lasse ich hier stehen. Wer Interesse hat, kann ja mal reinschauen.

 

[Rico Giesler]

Alles gut...
Find die Idee bzw die Ansätze super und es hilft ja auch anderen Händler.
Hab intern schon angefragt, ob wir andere User (die nicht so oft im Forum unterwegs sind) irgendwie darüber informieren wollen.
Leider hab ich dazu noch kein Feedback.

 

[hula1499]

Das ist sicher eine tolle Möglichkeit, finds auch toll, wenn sich Leute selbst um Sachen kümmern, die JTL nicht abwickeln will/kann.

ABER...he, ich bin DAU (wie sehr viele hier) was technische Tiefen betrifft.
Pyhton am Server jetzt noch zusätzlich installieren - ja find ich nicht so prickelnd.

Bitte nicht falsch verstehen, ich finds echt toll, dass ihr versucht, die Schwächen von JTL auszuräumen/zu umgehen. Find das echt spitze dass es auch geteilt wird, leider halt für die meisten (Mutmaßung) nicht so wirklich "einfach" einsetzbar.

 

[gboehm]

Pyhton am Server jetzt noch zusätzlich installieren - ja find ich nicht so prickelnd.

Kann ich nachvollziehen. Hatte bisher nur noch nicht (für mich) die Notwendigkeit gesehen, für alle meine Skripte eine .exe zu bauen. Hab's noch nie gemacht - muss aber mal schauen, ob ich das evtl. am Wochenende hinbekomme...

 

[gboehm]

Sodele, ich möchte zwar nicht Xantivas Thread highjacken - ich bin auch nicht sicher, ob und wo sich unsere Lösungen unterscheiden. Aber evtl. findet es ja der eine oder andere trotzdem praktisch..

Während die Tochter GNTM schaut, habe ich das Python Skript in eine exe gepackt. Sie läuft nun ohne dass man Python installiert haben muss. Sollte auf Win10 und Server2102R2 laufen - andere System habe ich nicht da.
Da die Datei zu groß ist habe ich sie hier abgelegt: https://www.dropbox.com/s/6s2zek8k9bbuz5f/ShipmentTracking.zip?dl=0 Bitte die exe und das config Verzeichnis herunterladen und irgendwo auf der eigenen HD ablegen. das config Verzeichnis muss da liegen, wo auch die exe liegt. Im config Verzeichnis die imap.ini öffnen und die Einstellungen für imap/smtp Server und wawi vornehmen. Funktion sonst wie oben beschrieben.

Den Quellcode lasse ich oben stehen. Wer Interesse hat, kann ja mal reinschauen.

 

[Xantiva]

Hi,

das ist ja lustig - zwei Dumme ein Gedanke.

Ich habe bei meiner Lösung explizit die Datenbankverbindung zu Wawi vermieden, damit das Tool auch von nicht JTL-Usern verwendet werden kann.

Ich nutze für die Entscheidung, ob eine Mail "valide" ist, nicht nur die Absender-Adresse, sondern erwarte auch einen validen SPF-Record. Ansonsten könnten Spam-Mails mit gefaktem Absender von dem Tool weitergeleitet werden.

@hula1499 Mein Tool setzt auf das .NET Framework 4.6.1 auf - da die Wawi inzwischen glaube ich mindestens 4.7.2 erfordert, sollte das bei jedem auf dem Server laufen.

 

[gboehm]

das ist ja lustig - zwei Dumme ein Gedanke.

Na ja, wenn man sich mal 5 Minuten hinsetzt und überlegt, liegt dieser Ansatz eigentlich direkt vor der Nase

Ich habe bei meiner Lösung explizit die Datenbankverbindung zu Wawi vermieden, damit das Tool auch von nicht JTL-Usern verwendet werden kann.

Da habe ich zum Zeitpunkt der Entwicklung evtl. etwas egoistischer gedacht. Wobei ich die DB Verbindung ursprünglich auch erst vermeiden wollte. Mir war dann aber der Aufwand eine Datei mit den Beziehungen der E-Mail Adressen zu verwalten zu groß. Man muss sie ja immer mal wieder aufräumen.

Ich nutze für die Entscheidung, ob eine Mail "valide" ist, nicht nur die Absender-Adresse, sondern erwarte auch einen validen SPF-Record

Oha! Ja, da hast Du recht. Eine Whitelist ist zu kurz gesprungen. Werde ich bei Gelegenheit noch einbauen

Was mich noch nervt, ist der Bug in Zusammenhang mit der "Nachricht an Kunden" Funktion. Wir nutzen sie recht intensiv. Im Issuetracker ist er auf mittelfristig gesetzt, was vermutlich bedeutet, nicht mehr in diesem Leben. Daher baue ich mir mal wieder mein eigenes Skript, was diese Funktion nachbildet.

 

[chummer]

@Xantiva: Also mit 1und1 kann ich das Programm irgendwie nicht betreiben. Imap Verbindung steht, Smtp kann keine Verbindung hergestellt werden:

2019-05-30 00:39:47.2232|ERROR|TrackingMailProvider.exe|1|An error occured during execution, for more details see log file. Error:
MailKit.Security.SslHandshakeException: An error occurred while attempting to establish an SSL or TLS connection.

One possibility is that you are trying to connect to a port which does not support SSL/TLS.

The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
1. The server is using a self-signed certificate which cannot be verified.
2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate.
3. The certificate presented by the server is expired or invalid.

See https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate for possible solutions. ---> System.IO.IOException: Fehler bei Handshake wegen eines unerwarteten Paketformats.
bei System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)

Zugangsdaten stimmen und man kann sich einloggen, das habe ich mit dem Mailprogramm gegengecheckt.


Das sagt mir 1und1 was eingestellt werden muss:

Posteingangsserver imap.ionos.de
Posteingangs-Port (SSL muss aktiviert werden) 993
Postausgangsserver (SMTP) smtp.ionos.de
Postausgangs-Port (TLS muss aktiviert werden) 587
Postausgangsserver erfordert Authentifizierung Ja

 

[Xantiva]

Hallo @chummer

One possibility is that you are trying to connect to a port which does not support SSL/TLS.

The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
1. The server is using a self-signed certificate which cannot be verified.
2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate.
3. The certificate presented by the server is expired or invalid.

Möglichkeit 1: Der Port unterstützt kein SSL/TLS ...

Der Port 587 ist ein Standardport, hast Du mal versucht mit dem SSL-Port 465 zu arbeiten?

https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate

 

[chummer]

Hallo @chummer



Möglichkeit 1: Der Port unterstützt kein SSL/TLS ...

Der Port 587 ist ein Standardport, hast Du mal versucht mit dem SSL-Port 465 zu arbeiten?

https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate
Den Anhang 33435 betrachten

Danke dir, das wars. Mit 465 funktioniert es.

 

[chummer]

@Xantiva: So, die ersten Emails von DPD laufen hier rein, werden aber scheinbar nicht weitergeleitet:
"The message header doesn't contain a SPF record."

Die Mails kommen direkt von info@paket.dpd.de und landen dann im unknown verzeichnis.

Was kann ich nun tun bzw kann man die SPF Prüfung abstellen?

 

[Xantiva]

Kannst Du mir bitte mal einen Mail-Header zusenden? (ggf. als PN) Wir versenden ja auch über DPD und bei mir funktioniert es.

 

[chummer]

PN ist raus.

 

[Arkin]

Hi, @Xantiva

Wir versenden derzeit ebenfalls mit DPD und würden gern dein Tool verwenden.

Ich habe mir dein Programm noch nicht installiert aber deine Anleitung bereits intensiv durchgelesen und werde es morgen installieren und versuchen einzurichten.
Der Mail Account und Catch-All Teil ist eindeutig und klar.

Jedoch habe ich ein Problem mit den Headern. Hier ist ja immer der Header der eingehenden Mail ausschlaggebend, richtig? Also von XYZ@dpd.de in meinem Fall.
Ich habe mir dazu mal die Header von "do_not_reply@dpd.de" (hier schreibst du im Wiki "no_reply@dpd.de")
sowie von "info@paket.dpd.de" angesehen.

info@paket.dpd.de enthält keine SPF Einträge ausschließlich dkim-Signature, welches auch in deinem Beitrag zum Programm mit auftaucht aber keine Verwendung hat, SPF und "Authentication-Results" fehlt hier gänzlich.

"do_not_reply@dpd.de" enthält weder SPF Einträge noch DKIM-signature im Header.

Von "pickup@paketshop.dpd.de" habe ich keine Mail, also kann ich mir den Header leider nicht anzeigen lassen
und keine Aussage treffen.

Kannst du hier nochmal einsteigen und Hilfestellung geben? Oder sollte ich dazu mit der IT-Abteilung von DPD Kontaktaufnehmen?

Viele Grüße und besten Dank schonmal vorab!

 

[Xantiva]

Hi @Arkin ,

Mails haben "von sich aus" auch keine SPF Einträge. Diese werden von Deinem Mailserver bei der "Eingangsprüfung" der Mails erstellt - vorausgesetzt, Du hast das auf Deinem Server aktiviert?

Wenn Du keine SPF-Einträge in den Mails findest, liegt das also an Deiner eigenen Serverkonfiguration und nicht am Absender. Der kann / muss nur den SPF-Eintrag bei Seiner Domain vornehmen.

Ciao,
Mike

 

[Arkin]

@Xantiva

habe mit unserem Mail-Hoster gesprochen. SPF Records sind bei uns tatsächlich derzeit deaktiviert.

Die Rückantwort bzgl. der Aktivierung der SPF-Header für die volle Funktion des Tool lautete von unserem Mail-Hoster:
Die SPF Checks sind ja als SPAM-Abwehr gedacht. Die Wahrscheinlichkeit bei der Verwendung von "None", dass ein Spammer die von JTL generierten Mailadressen vollspammt bei 0,X % liegt und vermutlich ohnehin durch die Spamprüfung vom Mailserver bereits vorher abgelehnt wird.

Kannst du bei dieser Aussage mitgehen? Oder siehst du das als große Gefahr für die Funktionsweise des Tools bzw. als SPAM-Gefahr für die Kunden?

Viele Grüße vorab.

 

[Xantiva]

Für meinen privaten Account würde ich die Spamprüfung per SPF auch aktivieren, aber für den geschäftlichen Account mache ich das nicht. Leider gibt es immer noch zu viele "unbedarfte" Firmen, die keine SPF-Header für ihre Domain ausliefern. Bevor mir daher Mails verloren gehen, habe ich auf dem Server zwar die Prüfung aktiviert, aber lasse nicht alle löschen, nur dann wenn die SPF-Prüfung fehlschlägt: "E-Mails abweisen, wenn Ergebnis der SPF-Abfrage "fail" ist (verweigern)"
Also nur wenn ein SPF-Header ausgeliefert wird und die Mail von einem nicht autorisierten Server kommt, wir die blockiert.

Abgesehen davon - auch wenn es nur 0,9% sind - dafür, dass das eigentlich nur "ein Klick" ist, würde ich das nutzen. Wie hoch ist die Wahrscheinlichkeit für einen kleinen Online- Shop durch einen DDOS-Angriff lahm gelegt zu werden? Auch klein, oder? Aber in den letzten Tagen waren viele von dem DDOS-Angriff auf das Rechenzentrum indirekt betroffen. Ich gehe eher den Weg mögliche Sicherheitsfunktionen zu nutzen, insbesondere wenn das mit sehr wenig Aufwand verbunden ist.