Interne eMails mit Login-Name als Absender und nicht mit info@...

BuggerT

Wir haben hier einige Benutzer, die über keine eigene externe eMail-Adresse verfügen. Sie versenden nach außen eMails von unserer info@...-Adresse. Realisiert haben wir das, indem wir im David Administrator beim jeweiligen Benutzer eine Include-Datei als Abschluss hinterlegt haben, in der dann @@von info@...@@ vermerkt ist.

Nach außen funktoniert das wunderbar. Problem: Es funktioniert auch bei internen eMails...

Wenn ich von einem dieser Benutzer also eine eMail intern erhalte, sehe ich als Absender auch nur "info@...". Hier wäre schön, wenn ich den Benutzernamen sehen würde. Wenn der Benutzer also User1 heißt, sollte als Absender bei internen eMails user1@... stehen (zur Klarstellung: diese eMail-Adresse gibt es extern nicht!).

So war das, bevor wir unser System umgezogen und auf David.FX 12 umgestellt haben. Ich weiß leider nicht mehr, ob wir damals auch mit der Include-Datei gearbeitet oder ob wir das anders gelöst haben.

Hat jemand einen Vorschlag, wie ich es am einfachsten realisieren kann, dass diese Benutzer intern mit ihrem Benutzernamen versenden, extern aber über unsere info-Adresse?

Vielen Dank.

QWERTZ

Moin, auch für den internen Versand braucht der Benutzer eine E-Mail Adresse.

Bei den Include-Dateien ist das Problem, dass das generell immer angewendet wird, also auch immer der Absender per @@-Befehl gesetzt wird.

Du könntest das lösen, indem du bei den Vorlagen der Benutzer ein @@von user@domain@@ hinzufügst und die Include-Datei als "Vorab-Include" hinterlegst.

Dann wird der Befehl in der Include-Datei von dem neuen Befehl in der Vorlage überschrieben.

wlconsult

Ich habe das bei einem Kunden so gelöst, dass ich den Mitarbeitern, die keine eigene Emailadresse haben, jeweils eine nur intern vorhandene Adresse als Hauptadresse und die info@... als Zweitadresse gegeben habe:

User mit Emailadresse: max.mustermann@domain.de (Hauptadresse)

User ohne Emailadresse:lisa.mustermann@domain.local (Hauptadresse) und info@domain.de als Zweitadresse für Versand

Untereinander kann dann jeder jedem Emails schreiben und ist auch eindeutig identifizierbar (sowohl im internen Adressbuch, als auch z.B. beim Verteilen, ...)

Den externen Versand habe ich genauso wie bei Dir mit @@-Befehlen in den Vorlagen erledigt. So ist sichergestellt, dass User ohne eigene Adresse immer mit der richtigen Adresse, nämlich der info@domain.de verschicken.

Um zu verhindern, dass trotzdem Emails mit einer nur intern vorhandenen Adresse nach draussen gehen (es gibt immer Spezialisten, die die Steuerbefehle löschen, sich selbst Vorlagen und Textbausteine ohne die passenden Befehle machen oder schlicht vergessen, auf die info@domain.de umzustellen) habe ich verschiedene Sende-Methoden definiert:

Wenn Absender = *@domain.de ist, dann Versand über den Smart-Host des Providers

Wenn Absender = *@domain.local, dann denselben Eintrag, nur mit irgendeinem SMTP-Server eines Großproviders und mit falschen Zugangsdaten

Emails mit *@domain.local als Absender kommen dadurch sofort mit der Fehlermeldung "Ungültiger Absender" zum jeweiligen User zurück.

Das funktioniert so allerdings nur, wenn Ihr über den Smarthost des Providers versendet, nicht wenn der DAVID direkt der MX ist. Diese Lösung ist zwar nicht ganz "sauber", aber praxistauglich und stabil. Und die User merken sofort selbst, wenn sie etwas verbockt haben

QWERTZ

Zitat von wlconsult

Ich habe das bei einem Kunden so gelöst, dass ich den Mitarbeitern, die keine eigene Emailadresse haben, jeweils eine nur intern vorhandene Adresse als Hauptadresse und die info@... als Zweitadresse gegeben habe:

Macht für mich auch mehr Sinn.

Denn dann können deine User intern auch die Live-Comments nutzen.

Also als Eingehende aus Ausgehende Adresse bei den Benutzern die Benutzer-Adresse eintragen.

Durch die Include werden sonst alle Mails sowieso mit der info@ versendet; und für die internen Mails sollen die ne andere Vorlage (besser: Textbaustein) nutzen, in der per @@-Befehl die eigene Adresse eingetragen wird.

Wenn du über nen Provider sendest, ist die Lösung von wlconsult auch gut.

Jetzt mitmachen!