Datev Upload Mail über AWS SES scheitert!

[#1]

... werde es wohl heute und morgen nicht mehr verstehen, warum man als Software-Entwickler 'über sieben Brücken gehen' muss (oder heißt es 'Krücken ?'), um zu einem Buchungsstapel im Datev-Format zu kommen ... 

[#2]

Wie leitest Du um in Outlook? Das geht imho nicht. The Bat konnte das mal, was nutzt Du?

[#3]

Ich dachte eigentlich daran aus der Anwendung direkt via Exchange Online zu senden, und nicht erst nach ExOn und dann nach Datev.

[#4]

---

@OliverFrank schrieb:

Wie leitest Du um in Outlook? Das geht imho nicht. The Bat konnte das mal, was nutzt Du?

---

Mit Microsoft Exchange Regeln unter Nachrichtenfluss im ECP so wie im Screenshot von @jankammerath. 

[#5]

---

@siro  schrieb:

Ich dachte eigentlich daran aus der Anwendung direkt via Exchange Online zu senden, und nicht erst nach ExOn und dann nach Datev.

---

Das geht leider nicht. Die Exchange Online API erfordert OAuth für das Postfach und über SMTP/TLS geht natürlich und richtigerweise aus AWS heraus nicht.

[#6]

---

@metalposaunist  schrieb:

Der Unterschied zwischen umleiten und weiterleiten ist Dir aber bewusst? Ich habe den Hilfe Center Eintrag auch noch nicht ganz verstanden aber als Tipp: 

Wenn Du umleiten einstellst, wird der E-Mail Header nicht umgeschrieben und landet 1:1 bei DATEV, wobei DATEV den ablehnt. Heißt: E-Mail kommt von kunde@kunde.de und wird an rechnung@lodgea.de geschickt und Du stellst eine Umleitung von rechnung@lodgea.de an uploadmail@datev.de ein, so landet kunde@kunde.de bei DATEV. 

Um das zu umgehen nutzt man weiterleiten, weil dann als Header rechnung@lodgea.de in der E-Mail steht, die bei DATEV autorisiert wurde. 

Ich hoffe, ich habe das jetzt nicht verdreht aber wenn ich Mails umleite, werden die Mails 1:1 so wie sie geschrieben worden sind z.B. per Regel einem anderen Postfach zugestellt und dort steht der Absender des "echten" Absenders drin. Beim Weiterleiten steht im Falle von E-Mail Regeln immer das Empfängerpostfach drin, dass weiterleitet; die eigentliche Absenderadresse erscheint aber auch im Outlook nicht mehr. 

---

Entschuldigen Sie bitte, dass ich jetzt technisch etwas konkreter werden muss und Sie hier korrigiere, bitte nicht persönlich nehmen. Der sog. "Envelope Sender" ist keine Kopfzeile (engl. "Header"), sondern das MAIL FROM Kommando im SMTP-Handshake. Umleitungen oder Weiterleitungen (sind nach RFC am MTA identisch) beinhalten immer den Originalen Sender des Umschlags (engl. Envelope).

Einige Agenten (Mail-Agents wie z.B. Outlook, iMail etc.) bieten die Möglichkeit die E-Mail als "Forwarding" (Weiterleitung) an einen anderen Nutzer zu senden. Dabei wird die E-Mail jedoch nicht weitergeleitet, sondern als neuer Umschlag (Envelope) mit einer Köpie der Anhänge (Mime-Multiparts bzw. Attachments) sowie dem Körper (entsprechende HTML/Text Multiparts) versendet. Das ist rein die Sache des Mail Agent und Outlook.com bietet als web-basierter Mail-Agent das eben auch als Regel an.

Weil eben technischer Versender und Versender in den Kopfzeilen ("From"-Header) häufig nicht identisch sind, gibt es ja eben SPF und DKIM zur teilweisen, aber ausreichenden Überprüfung der Identität. Der korrekte Weg von DATEV wäre hier: Empfang der E-Mail, Überprüfung des FROM-Headers und Prüfung des MX oder SPF im DNS sowie entsprechend DKIM falls vorhanden.

So wie das von DATEV aktuell implementiert ist, muss man feststellen: Umleiten oder Weiterleiten von E-Mails gemäß entsprechender RFCs ist bei DATEV Upload Mail grundsätzlich nicht möglich.

[#7]

Alright 💪! Wieder was gelernt 🤓. Ihren Beitrag speichere ich mal für die Zukunft ab 😊. Danke!

[#8]

---

@metalposaunist  schrieb:

Alright 💪! Wieder was gelernt 🤓. Ihren Beitrag speichere ich mal für die Zukunft ab 😊. Danke!

---

Gern geschehen und Danke für die Unterstützung! 😊

Wichtig hinzuzufügen wäre mir noch, dass durch die beschriebene Tatsache grundsätzlich keine E-Mails aus den Netzen von Amazon Web Services, Microsoft Azure oder Google Cloud Platform versendet werden können. Die dort vorhandenen oder empfohlenen E-Mail-Dienste arbeiten alle als Relay und verwenden entsprechend das, was hier als "Umleitung" beschrieben wird (Relaying). Das Verwenden eines anderen, externen Mailservers ist grundsätzlich nicht möglich, da die meisten Cloud-Anbieter und auch RZs den SMTP-Port, richtigerweise zur Spam-Abwehr und Reputationssicherung, sperren.

Das hat zur Schlussfolgerung, dass es keinerlei Möglichkeit für moderne Software-Anwendungen gibt, Rechnungen automatisiert an DATEV zu übermitteln ohne vorher ein aufwändiges Prüf- und Zertifizierungsverfahren bei DATEV durchlaufen zu müssen. Sofern dies überhaupt gestattet wird. Der Belegtransfer ist eine Win64-Anwendung ohne dokumentierte APIs und der Rechnungsdatenservice erfordert eine, wie auch immer geartete, Zertifizierung.

[#9]

---

@siro  schrieb:Ich würde einen Blick auf die Datenservices Rechnungswesen werfen

---

Kurzer Nachtrag zum DATEV Rechnungsdatenservice: der Rechnungsdatenservice ermöglicht keine automatisierte Übertragung von Daten. Vor jeder Übertragung muss OAuth2 mit Unternehmen Online ausgeführt werden. Das bedeutet auf Deutsch: jedes Mal, wenn man Daten mit Rechnungsdatenservice übertragen möchte, muss sich ein Menschen mit mindestens SmartLogin anmelden und der ausgestellte Token ist nur 15 Minuten gültig.

Damit gibt es ganz offensichtlich bei DATEV, bis auf Mail Upload mit vorbenannten Einschränkungen, überhaupt keine Möglichkeit Belege vollautomatisch zu importieren.

[#10]

Falls es Jemanden interessiert, ich habe unseren Import jetzt über Microsoft Power Automate gelöst. Ist sicherlich nicht schön, aber funktioniert jetzt wenigstens vollautomatisch.

[#11]

Gefällt mir 😎!

Dann lege ich Dir ans Herz : Schnittstellen zu Powerautomate bzw. LogicApps 👍 ich nehme an, da geht auch im DATEV Umfeld / Programmen noch einiges. 

[#12]

Nachtrag:

... mich würde interessieren, ob die Signatur von Herrn Kammerath noch der Community-Netiquette entspricht oder schon als Werbung für eine gewerbliche Web-Präsenz zu betrachten ist.

Vielleicht könnten wir ja auch alle unsere anklickbaren Homepage-URLs in die Signatur setzen mit einem selbstgewählten Titel, z.B. "Premium-Steuererklärungen" oder so ähnlich.

Ich erinnere mich dunkel, dass es vor kurzem Proteste gegen die Werbe-Aussagen mehrerer anderer Community-Mitglieder gab.

Nachtrag 2:

... vor kurzem ist mir auch ein Post über den Weg gelaufen mit der Signatur eines direkten Wettbewerbers der Datev

... da dürfte es dann allmählich eng werden mit der Toleranz (von Seiten der Datev) 😉 

[#13]

Ich glaub da ging es um das penetrante Anpreisen von Dienstleistungen. Ein Link auf die eigene Unternehmenspräsenz sollte hier wohl legitim sein.

[#14]

Also egal wie man es dreht und wendet, die Zusammenarbeit mit DATEV bleibt besch... schwierig! 

Die großen Cloud-Anbieter sind sehr bemüht möglichst viele und einfach APIs anzubieten um damit möglichst viele Entwickler zu ermutigen Lösungen um ihre Produkte herum zu bauen. So entstehen digitale Ökosysteme die für alle beteiligten einen Mehrwert bieten. Man sollte meinen das DATEV dasselbe Ziel verfolgt. Aber durch die sehr mangelhafte Umsetzung von DATEV-Upload-Mail schließt DATEV alle Partner aus die ihre Lösung bei modernen Cloud-Anbietern hosten. Damit sind nicht nur die Hyper-Scaler wie AWS, GCE und Azure gemeint. Wenn IONOS oder Hetzner mal einen SES Clone anbieten werden, dann werden diese ebenfalls den Envelope-From überschreiben und somit werden diese Dienste ebenfalls unbrauchbar sein um Sie für DUM zu nutzen. 

Und dabei könnte es so einfach sein. Ich kapiere einfach nicht warum DATEV nicht die MX, SPF und DKIM Einträge aus einem öffentlichen DNS validieren kann. Kriegen die das fachlich nicht auf die Kette? Haben die Fackräftemangel? In dem Fall könnte ich weiterhelfen. Meine Kunden vermitteln IT-Fachkräfte!