Termineinladungen beantworten - Mail geht nicht raus

ging die Anfrage an eine Mailadresse die keine User zugeordnet ist sondern einem Archiv?
Oft ist es so, dass über die Mailadresse dann nicht versendet werden kann oder der David Server versucht direkt raus zu schicken statt über Provider.
Du müsstes mal auflisten welche Mailadresse an welche Mailadressen eine Anfrage stellt und wem die Mailadressen zugeordnet sind.

Beispiel.
Ich bekomme eine Anfrage von externer@firma1.de

an meine hinterlegt Mailadresse User1@meinefirma.de
und zugleich an info@meinefirma.de

die info@meinefirma.de ist keine User zugeordnet und wird nur an ein Archiv verteilt. Ebenso gibt es hierfür keine Sendemethode.
Dann passieren genau solche sachen wie du es beschrieben hast.

Aber am besten du postest mal, was das Postman Log dazu sagt, wenn du auf solch eine Anfrage antwortest.

Hallo zusammen,

das Problem kann ich bestätigen und es tritt schon seit Längerem auf (ist also nicht auf die aktuellste DAVID mit Sitecare beschränkt):

Kommt von extern eine Termin-/Besprechungsanfrage herein, die im AN-Feld mehrere Empfänger aufweist (Empfänger-Adressen aus unterschiedlichen Domänen), dann nimmt DAVID als Absender-Adresse für eine Antwort immer die erste Adresse aus dem AN-Feld, auch wenn die mit dem internen Empfänger oder der eigenen Domäne nichts zu tun hat. Als Ergebnis wird diese Email vom eigenen Provider abgelehnt, wenn eine Überprüfung der Absenderadresse stattfindet. Alternativ lehnt der Empfangsserver die Nachricht ab, weil Absender-Adresse und -Domäne nicht übereinstimmen.

Korrekt macht der DAVID das nur, wenn es nur einen (internen) Empfänger für die Besprechungsanfrage gibt, oder wenn per Zufall der interne Empfänger an erster Stelle im TO:-Feld steht.

Ein ziemlicher Bock meiner Meinung!

dann sollte man dies Tobit mitteilen.

Die Tests dazu konnte ich bei einem großen Kunden erst letzte Woche machen und mittlerweile auch bei anderen Kunden mit/ohne Sitecare nachprüfen.

Das Problem ist schon an TOBIT weitergegeben, eine Antwort steht allerdings noch aus. Der Fehler besteht aber mindestens schon seit einem Jahr, denn so alt war die älteste DAVID-Version (ohne Sitecare), mit der ich das testen konnte.

Ich muss dieses alte Thema nochmal hervorholen, weil wir aktuell genau das gleiche Problem haben, dass von wlconsult in Post Nummer 6 beschrieben wurde.

wlconsult Konntet ihr das Problem beheben oder gab es ein Update von Tobit? Aktuell wird hier eine noch eine ältere Version eingesetzt (12.00a - 3533), in welcher das Problem definitiv noch vorhanden ist.

David verschickt Antworten auf Besprechungsanfragen immer mit der ursprünglichen Verteilkennung der Anfrage als Absender. Hintergrund ist wohl, damit der Sekretär eine Anfrage an seine Chefin beantworten kann.
Ihr müsst also dafür sorgen, dass bei Mails an mehrere Empfänger die richtige Verteilkennung gesetzt wird. I.A. ist das bei den Pop3 Postfacheinstellungen das auszuwertende Adressfeld (x-delivered-to: bspw.) oder der Eintrag einer Zieladresse.

Zitat von wlconsult

Korrekt macht der DAVID das nur, wenn es nur einen (internen) Empfänger für die Besprechungsanfrage gibt, oder wenn per Zufall der interne Empfänger an erster Stelle im TO:-Feld steht.

Ein ziemlicher Bock meiner Meinung!

Wenn das hier schon noch wieder aufgewärmt wird...

Zitat von Wizzard

Ihr müsst also dafür sorgen, dass bei Mails an mehrere Empfänger die richtige Verteilkennung gesetzt wird. I.A. ist das bei den Pop3 Postfacheinstellungen das auszuwertende Adressfeld (x-delivered-to: bspw.) oder der Eintrag einer Zieladresse.

Das ist ein weiterer Grund warum es keine wirklich gute Idee ist die Postfächer seiner Benutzer beim Provider einzurichten und für jeden Nutzer separat den Posteingang via einzelnem POP3 Eintrag vom Grabbing Server abholen zu lassen.

Richtet man beim Provider statt dessen ein Catch All Postfach ein, lässt den David Server dieses Postfach zentral abholen und richtet dann die Verteilung so ein, das die vom eigenen eMail Provider hinterlassene Kennzeichnung des ursprünglichen smtp envelope to ausgewertet wird - in unserem Fall bei Strato ist das dann "X-ENVELOPE-TO:" - stimmt auch die Verteilkennung bei solchen Einladungen immer korrekt.

Die oben beschriebenen Probleme handelt man sich ausschließlich dann ein, wenn man dem David Server die Chance nimmt zu erkennen für wen auf dem lokalen Server die Nachricht eigentlich wirklich bestimmt war.
Der Grabbing Server beachtet das nämlich - absolut korrekter Weise - nicht wenn er mit dem Auftrag alles gefundene in einem bestimmten Eingang bereitzustellen mails aus einem im jeweiligen Benutzer Konto hinterlegten POP3 Account einsammelt.

Zitat von riawie

Das ist ein weiterer Grund warum es keine wirklich gute Idee ist die Postfächer seiner Benutzer beim Provider einzurichten und für jeden Nutzer separat den Posteingang via einzelnem POP3 Eintrag vom Grabbing Server abholen zu lassen.

Richtet man beim Provider statt dessen ein Catch All Postfach ein, lässt den David Server dieses Postfach zentral abholen und richtet dann die Verteilung so ein, das die vom eigenen eMail Provider hinterlassene Kennzeichnung des ursprünglichen smtp envelope to ausgewertet wird - in unserem Fall bei Strato ist das dann "X-ENVELOPE-TO:" - stimmt auch die Verteilkennung bei solchen Einladungen immer korrekt.

Zu erstmal danke für die Erläuterung, klingt alles soweit Schlüssig.

Zitat von riawie

Der Grabbing Server beachtet das nämlich - absolut korrekter Weise - nicht wenn er mit dem Auftrag alles gefundene in einem bestimmten Eingang bereitzustellen mails aus einem im jeweiligen Benutzer Konto hinterlegten POP3 Account einsammelt.

Wenn ich das Ganze richtig verstanden habe, könnte ich zum Testen, ob das unsere Problematik behebt, einmal folgendes machen:

• bei zwei Benutzern den POP3 Eintrag aus dem Benutzerkonto entfernen
• für die beiden E-Mail Adressen im Grabbing Server händisch einen Eintrag anlegen, in welchem das Adressfeld (bei uns "X-Original-To:") ausgewertet wird
• zwei Verteilregeln anlegen, welche die entsprechende E-Mail Adresse an den jeweiligen Benutzer zustellt

Dann sollte für diese beiden Benutzer das genannte Verhalten nicht mehr auftreten, richtig? Oder habe ich noch was falsch verstanden?

Wenn das dann keine Probleme mehr bereitet würde ich alles umstellen, mit Catch All Postfach beim Provider.

Edit: Habs einfach mal ausprobiert. Das behebt die Ganze Problematik und der Absender der Besprechungsantwort wird korrekt ausgewählt.
Danke für die Hilfe!

TSEP Grundsätzlich solltest Du das in der Tat so testen können. So lang die jeweiligen eMail Adressen - welche da im "X-Original-To:" Header ausgewertet werden - bei den beiden Benutzern in deren Einstellungen auf der Seite Allgemein bereits als Hauptadresse, oder unter weitere als eingehende eMail Adressen, eingetragen sind braucht es keine Verteilregeln mehr. Verteilregeln bräuchte es nur für im System nicht bekannte Adressen, welche es in einem korrekt konfigurierten System aber nicht geben sollte, wenn man eh kein catch all Postfach beim Provider hat. Was Du dann allerdings unter Umständen noch einrichten musst ist ein Weg zum versenden von Mails, denn aktuell nutzt der David Server bei Euch vermutlich die Einstellungen welche in der Benutzerkonfiguration der POP3 Konten der einzelnen Nutzer hinterlegt sind auch für den Versand.
Mit einer Catch all Konfiguration muss dann natürlich - auch wenn man sie im Grunde erst mal nur simuliert - in der Postman Konfiguration auf der Seite Provider ein Smarthost eingetragen werden, über welchen Mails versendet werden sollen, alternativ müsste man Mails direkt an die Server der Empfänger ausliefern, das allerdings erfordert noch etwas mehr Vorbereitung, da einige Voraussetzungen zu schaffen sind.
Grundsätzlich empfehle ich solche Änderungen nur mit den nötigen Kenntnissen und nach gründlicher Planung der Abläufe und dann auch Systemweit durchzuführen.

riawie Danke, habe das Ganze getestet und hat funktioniert. Zum Senden habe ich übergangsweise einfach nur manuell eine Sende Methode für die beiden E-Mail Accounts im PostMan angelegt, welche die Mails über den Provider verschickt.