Weiterleitung

Guten Tag,

ich weiß nicht, ob ich hier oder in der Installation mit meiner Frage richtig bin. Im Fall der Fälle bitte den Thread verschieben. Danke.

Gegeben sei
A-domain.de (dvise fx-12 aktueller Stand Juni 2016)
B-domain.net (exchange) (sekundär B-domain.de)

aus einer Anwendung heraus sollen die Mitglieder der B-domain.net eMails/Faxe über den David aus A-domain.de verschicken.
Ich habe also im David (A-domain.de) die user@B-domain.net angelegt und maile/faxe aus der Anwendung. Das funktioniert.

Da die User keinen direkten Zugriff auf den David Info Center haben (sollen/wollen), dachte ich mir, ich erstelle einfach eine Weiterleitung (Regel) im Postausgang an user@B-domain.de (sekundäre dom). Das funzt auch, nur erstellt mir David natürlich einen weitere Mail, die natürlich auch wieder versendet wird. (endloser Mailverkehr). Ich habe probiert Regeln zu setzen, die eigentlich den zweiten Versand (bspw. Mail an user@B-domain.net ignorieren) unterdrücken sollen. Diese Regeln greifen nicht.

So, dann habe ich eine Regel Verschieben an Ordner eingerichtet und in diesem Zielordner eine Weiterleitung installiert.
Damit bin ich die Endlosschleife der Mailerei zwar los, aber bspw. Umlaute in der Mail werden nicht richtig umgesetzt.

Ich habe hier zwar schon die Suchfunktion bemüht, habe auch ähnliche Themen gefunden, leider aber keine Lösung.

Hat jemand von euch eine Idee. Es wäre für mich kein Problem, die mir fremden user@B-domain.net auch nicht extra im David anzulegen, Hauptsache David verschickt die Mail und die Ausgansbestätigung(Kopie) an den entsprechenden exchange user.

Was nicht geht, das ist den exchange direkt anzusprechen. Die Mail/Fax/ECT ist aus der Anwendung rein auf die Tobit API ausgerichtet.

Danke schon mal fürs Lesen

Ahoj
-Uwe

Hallo Jens,

meine Konfiguration hier ist etwas schwierig. Von der Sache her habe ich etwa ein dutzend David_Server in verschiedenen Standorten/Städten stehen. In der Regel hat jeder Standort eine eigene Domäne.
Das Herzstück ist ein Terminal-Server, auf den alle Standorte zugreifen und unser Brot und Butter Programm fahren. Wird bspw. eine eMail aus dem WTS Programm erzeugt, weiß ich (als Programmierer) zu welchen externen David der Benutzer gehört und spreche den betroffenen David über die API an.
Info-Center und Tobit-Drucker sind je nach Benutzer dem zugehörigen David auf dem WTS ausgerichtet.

Nun habe ich einen neuen Standort, der einen Exchange Server betreibt. Ich habe von diesem Microsoft Produkt keine Ahnung, und mein erster Gedanke war, ich lege die Benutzer hier in meinem Zentral-David an (unter ihren user@domain.net). Des weiteren habe ich eine Regel im Ausgang erstellt, die an den user@domain.de (sekundäre Mailadresse des externen Standortes) eine Weiterleitung (x-media) schickt.
Da dieser Vorgang einen weiteren Eintrag im Ausgang erzeugt, der die Regel wieder greifen lässt, habe ich damit eine Endlosschleife. Schlau wie ich bin, habe ich die Regel so abgeändert auf das die Zieladresse user@domain.de ausgenommen ist.

Bildhaft
user@domain.net und user@domain.de ist effektiv ein Konto unter exchange
user@doamin.net ist als Benutzer im David eingetragen (nur Ausgang,
Posteingang ist der entfernte exchange)

user@domain.net schickt an user@t-online.de (ok) (Umlaute korrekt)
Im Ausgang wird die Mail als versendet eingetragen
Die Regel greift im Ausgang und verschickt als Absender
user@domain.net eine Mail an user@domain.de (ok)
Im Ausgang wird die Weiterleitung als versendet eingetragen
Jetzt sollte aber die Regel, wenn das Ziel user@domain.de ist, wirken,
und diese Weiterleitung nicht ausführen.

Macht er aber nicht, er verschickt und verschickt und ..
Auch hier habe ich (sofort ??) zumindest in den Wiederholungen Umlautproblem
Aus "Grüßen" wird dann sowas wie "Gr + + en" - oder in der Art (kein SMTP Header sichtbar)

So dann habe ich statt Weiterleitung eine Umleitung in Ordner aktiviert.
Die Mail wird vom Ausgang in den Ordner transportiert und danach mit einer Weiterleitungsregel an user@domain.de versendet. Das ist ok, bis auf Umlautprobleme

Wegen den Umlautprobleme kann ich mir nochmals genauer anschauen, vielleicht mache ich was falsch.

Es ist nur der erste von mir ausgeheckte Ansatz, ich weiß auch nicht was für Tücken der sonst noch birgt.

Anderer Ansatz: ich habe eh einen Mailrobot, der über POP3 Mails aus dem David fischt. Den könnte ich um das scannen des obigen Ordners erweitern und den user@domain.de ihre Ausgänge zumailt.
Aber was mach ich mit Ausgangsfaxen ?

Oder es gibt einen ganz anderen Ansatz, den ich vor lauter Bäume nicht sehe ?

Diesen einen Standort zu regulären David Benutzer einrichten, das wäre keine gesunde Option ...
Das sind alles outlooker und exchanger

Danke für Dein Interesse
-Uwe

Hallo Jens,

wenn ich einfach zusätzlich per BCC rausgehe, so weiß der Versender noch lange nicht, ob diese Mail an To auch ankam. Das ist der Sinn dieser Aktion mit den Regeln. Einen David Server denen hinstellen, das geht im Moment nicht. Dieser Standort ist recht neu in unserer Firmengruppe aufgenommen, da muss noch vieles zusammen wachsen....

Aber Dein Hinweis mit dem neuen David MX hat meine Neugierde geweckt. Hast Du einen Link über dieses Produkt ? Ich habe hier nur sehr oberflächlich gesucht und einen Tipp von 2009 gefunden. Da weiß ich nicht ob alt oder neu David MX.

Danke Dir
-Uwe

Hallo Jens,

vorab vielen Dan für Deine Mühen.
Ich dachte der neue David MX wäre ein (Programm) Addon von euch, daher kam meine Frage .

Ausgangslage
domain.net und domain.de sind MX für entfernten exchange Server
Die Benutzer von domain.net sollen über unseren David Mails verschicken dürfen.

Der (Fremd) Benutzer hat die Kennung user@domain.net im David
Der David ist aber kein MX für domain.net, es wird nur für doamin.net versendet

domain.net wird von unserem David als Ziel domain.de angesprochen (Endlosschleife vermeiden)

Mittlerweile bin ich ein Stück weiter, die Ausgangsregel habe ich nun am laufen.
Wenn Empfänger ist ungleich user@domain.de und Status ist gleich versendet dann leite an user@doamin.de weiter.

Damit verschickt der David genau einmal die Ausgangsbestätigung, und die Bestätigung der Ausgangsbestätigung wird unterdrückt.

Das Problem habe ich weiterhin mit den Umlauten. Über die API wird eine Mail erzeugt und versendet.
Der HtmlText wird als utf-8 angelegt und kommt auch sauber beim Empfänger an. Über HexEdit/Notepad++ habe ich die 0tx überprüft.

Die Weiterleitung aus obiger Regel verwandelt die Umlaute (original in utf-8 codiert) nach irgendwas unbekanntes.

Seltsamerweise werden weitergeleitete Mails, die aus dem Info Center direkt erstellt wurden, korrekt übermittelt.

Ich werde morgen mal aus der API Hilfe das erzeugen/versenden "HTML Mail mit Anhang" (C++) so weit es geht 1:1 inkludieren. Text natürlich mit Umlauten. Mal schauen was er daraus macht.

Zumindest sehe ich zu meinem Code nicht _den_ Unterschied, aber der Teufel liegt wie immer im Detail .

Falls alle Stricke reisen, dann werde ich BCC verwenden müssen.

> Ob die Mail auch ankommt, weiß man als Absender doch nie,...

Ich kenne meine Benutzer. Die Qualität der abgespeicherten Adressen lässt doch hin und wieder zu wünschen übrig, bzw. sind exotisch, oder der Account hat beschnittene Anhangsgrößen. Da empfinde ich einen Hinweis über nicht ausgehende Mails hilfreich (die Benutzer fragen u.U nicht nach, und der eigentliche Empfänger denkt sich "die haben es wohl nicht nötig auf mein Anfrage zu antworten"). Dies wäre dann die zweite Regel, die ich noch anlegen möchte.

Wie schon erwähnt, der ganze Aufwand betrifft nur die reinen nichtTobitler.

Eventuell kann der exchange von sich aus den David über POP3 abfragen? Das wäre auch noch eine Möglichkeit

Ich weiß, alles ein bisserl kompliziert mit mir

Einen schönen Abend
-Uwe

Hallo Jens,

die Umlaute gehen jetzt auch.

Ich ziehe eine Vorlage und hole den body mit

pVorlageFormattedText->get_HTMLText(&bstrTemp);

überarbeite das BSTR noch ein wenig und schiebe danach den Inhalt nach

pMailFormattedText->put_HTMLText(bstrTemp);

Das meinige Problem hierbei, das get_HTMLText() beinhaltet unter anderem auch TAGS aber keine HTML Kodierung für Umlaute/Sonderzeichen, stattdessen den utf-16 Code für das entsprechende WCHAR. Ich habe das als normal angesehen, und das ganze lief auch rund 15 Jahre rund um die Uhr. Zumindest solange, bis ich auf die Idee mit der Weiterleitungsregel kam. Der David_Server selber will unbedingt HTML kodierten Text haben. Also muss ich nun jedes mal die die Vorlage nach dem get_HTMLText() mit einem Parser nachbearbeiten.

Der API ist es scheinbar egal ob, ob man Ü oder "Ü" übergibt. Sie verarbeitet beides richtig.

Nun verabschiede ich mich bis zum nächsten Tobit Problem.
Danke fürs Zuhören und Geduld mit mir

Ahoj
-Uwe