Mails direkt im Archiv

Zitat von andev

Es wäre absoluter Blödsinn, etwas zu ermöglichen, was der "falsche" Weg ist.

wenn man sich anschaut wann Tobit den POP3 Abruf direkt in der Konfiguration eines einzelnen Nutzers und dann auch in dessen Eingangsarchiv hinein, zu welchem Zweck gebaut hat kommt man nicht auf so eine Idee.

Das ganze wurde gebaut um im Fall von Konsolidierungen auch Altlasten ordentlich mit übernehmen zu können. seither wird das weiter mitgeführt, aber nicht mehr erweitert oder groß gepflegt.
Das ist im Grunde eine historische Altlast.

Das Feature MIS und dessen 2nd Scan, mit dem es jetzt ins Gehege gerät ist wesentlich jünger und soll systemweit funktionieren.

Selbst zu Zeiten wo es noch keinen 2nd Scan gab war es ein Fehler die Funktion ein einzelnes POP3 Postfach gezielt in den Eingang eines einzelnen Benutzers abzuholen so zu verwenden das man für jeden einzelnen Benutzer extern ein einzelnes POP3 Postfach anlegt und dieses dann direkt in den Eingang des jeweiligen Nutzer per grabbing Server importiert.

Merke, nur weil etwas technisch funktioniert ist das nicht auch ein korrekter Weg wie man etwas tun sollte.

Ich weiß, das viele es deswegen tun, weil sie so bei ihrem Provider auf ein catch all Postfach mit einem echten Wildcard verzichten können und damit Mails an nicht existierende Nutzer gleich beim Provider ablehnen können.
Allerdings hat das neben dem hier zu Tage tretenden Problem noch eine ganze Reihe weiterer negativer Folgen welche hier nun wirklich den Rahmen sprengen würden.
Wenn man schon partout beim Provider den Weg über lauter einzelne Postfächer gehen will, sollte man wenigstens den Import und die Auswertung lokal auf dem David Server wieder über die zentrale POP3 Konfiguration machen.

Einfacher und weniger Arbeit bei der Pflege auf der Provider Seite verursachend, sowie dort Ressourcen schonender ist es allerdings dann schlicht ein oder mehrere Namentliche POP3 Konten mit Aliasen für die restlichen Nutzer beim Provider anzulegen, damit vermeidet man die ungewünschten wildcards und lehnt Mails an nicht existierende Konten bereits durch den Provider ab, gleichzeitig muss man auf dem David Server nur so viele POP3 Abrufe anlegen wie es aufgrund der eventuell beim Provider vorhandenen Beschränkungen für die Anzahl der Aliase die ein Konto dort haben kann notwendig ist.
Auf dem David Server läuft damit das Mail Routing wieder zu 100% RFC konform und auch künftige Features werden damit mit sehr hoher Wahrscheinlichkeit keine Probleme haben.
Kommt dann ein neuer Nutzer auf dem David Server hinzu reicht es übrigens den Benutzer einzurichten und ihm eine Mail Adresse zu geben, ein POP3 Abruf braucht dort nicht mehr konfiguriert werden, anschließend noch beim Provider ein weiteres Alias hinzufügen und gut. Nur wenn keine Alias Einträge mehr beim Provider frei sind muss die Zahl der POP3 Abrufkonten mal um 1 erhöht werden.

Aber genug der Beratung zur Umsetzung für nicht gewünschte Wildcard Catch All Postfächer

Zitat von andev

Wenn es darum geht in 1 und/oder 2 das X-Envelope-To als auzuwertendes Feld zu nehmen, dann wäre die Frage, warum macht das David nicht von Haus aus, wenn das To Feld eh zu möglichen Fehlern führt. DAS könnte eine Möglichkeit für zukünftige, bessere Einrichtungen sein und bei Wartungen ggf beim Kunden nachgeholt werden. I agree....

Ganz simpel:
1. gibt es Mailserver auf Provider Seiten bei denen dieses Feld anders heißt, oder gar nicht erst existiert, deswegen muss es auch explizit konfiguriert werden wenn man einen zentralen POP3 Abruf einrichtet. Damit hat man die maximale Flexibilität seinen david Server korrekt mit jedem beliebigen Provider zusammenarbeiten zu lassen wenn man denn weiß was man da tut.

2. hat derjenige, welcher explizit einen POP3 Abruf für einen einzelnen Nutzer in dessen Benutzerkonfiguration angelegt hat damit schlicht eine Entscheidung getroffen das so abgeholte Mails nur und ausschließlich im Eingang dieses einen Benutzers landen dürfen.
Es wäre auch Datenschutzrechtlich sehr problematisch da hinterher noch irgendein Adressierungsfeld auszuwerten.
Und genau deswegen schrieb ich auch oben das die einzig korrekten Varianten wie Tobit diesen unerwünschten Seiteneffekt beheben kann jene wären das David solchermaßen abgerufene Mails vom 2nd Scan ausschließt, oder ihnen ein eindeutiges Schild mit dem zu erzwingenden Ziel anpappt.
Wenn Tobit den zweiten Weg wählt müssten sie allerdings zudem noch sicherstellen, das kein anderer Nutzer des Systems diese Nachrichten im transit Ordner sehen kann.

Zitat von andev

z.B. das Schulungsteam von Tobit. Ich hab gerade noch einmal in meiner Doku nachgesehen...

Das allerdings ist mehr als peinlich, dürfte allerdings historische Ursachen haben und schlicht noch nicht aufgeräumt worden sein, weil es keinem wirklich aufgefallen ist und state of the art eigentlich Catch all wäre, wenn man nicht gleich Mails via smtp annimmt...

Zitat von andev

Fakt ist, ich/wir haben bei 99% unserer Kunden, wie auch bei uns, NICHT die "X-Envelope-To Auswertung" an, weil das kein Standard ist

Ich gehe darauf jetzt nur noch mal gezielt ein, weil das jetzt wegen meiner obigen Anmerkung zum Thema warum Tobit beim David Server nicht "X-Envelope-To" standardmäßig auswertet noch mal wieder falsch verstanden werdne könnte

Richtig ist, das es in der Tat bei David nicht Standard ist "X-Envelope-To" bei per Grabbing Server eingesammelten Nachrichten auszuwerten.

Ein Standard bei im Internet eingesetzten Mail-Servern ist es allerdings schon, allerdings einer von mehreren möglichen für die man sich als Programmierer von solchen Mailservern entscheiden kann und damit halt auch ein Standard auf den man als Kunde eines Providers treffen kann, allerdings eben ein Standard von mehreren möglichen.

Wie eben geschrieben, nur zur Klarstellung, weil man sonst das Wörtchen "Standard" in dem Zusammenhang der Diskussion bis hierher doch noch wieder missverstehen könnte

Zitat von andev

Fakt ist, wenn MIS + 2nd Scan + "nicht RFC Zeichen" im To oder machmal auch eben nicht ?!?, dann wird die Mail von David falsch abgelegt.

Ja, aber wie geschrieben eben nur dann wenn man die Mails direkt in das Postfach eines einzelnen Nutzers einsammeln lässt, statt das über einen zentralen POP3 Abruf mit Ziel des zentralen internen Mailroutings zu tun und dabei die vom Provider bereitgestellten Daten aus der ursprünglichen SMTP Kommunikation zu verwenden.

Zitat von andev

Damit liegt der Ball - meiner Meinung nach - zur Lösung eines besseren Handlings bei "nicht RFC" Headern bei Tobit. Und sei es Unverteilt.

irgendwie schon, dann aber doch nicht so wie Du das gerade darstellst :o

Denn wenn eine Nachricht für einen bestimmten Nutzer abgeholt wurde darf da schlicht gar nichts mehr ausgewertet werden. Die Mail hat genau in dessen EIngang zu wandern und sonst nirgends hin.

Folglich ist das in der Tat ein Fehler im David Server den Tobit korrigieren muss!
Nur eben nicht so das sie da was am Routing verändern, sondern so das sie da Routing ganz klar unterbinden

Ich bin mir im übrigen sicher das man auch bei dem Mails welche kein ' im To enthalten und die bei Euch dennoch ab und an im zentralen Archiv landen wenn 2nd Scan aktiv ist Fehler im To Header finden würde, welche das Verhalten erklären, wenn man sich damit ausreichend auskennt und sehr genau hinschaut.

Eigentlich sollten sich diese Fehler aber auch alle durch entsprechendes sanitizing beheben lassen.

Allerdings gehören sie eben nur dann behoben wenn die entsprechende Mail via zentralem POP3 Grabbing außerhalb einer Benutzerkonfiguration eingesammelt wurden, denn nur da sind sie von tatsächlichem Belang.

Zitat von andev

Um das Problem, bei den betroffenen Kunden zu beheben, werde ich da wohl die Einstellungen anpassen. Das verschiebe ich persönlich aber auf 2021

Kluge Entscheidung, das dann doch mal anzugehen (y)

Zitat von andev

Vielleicht gibbet ja bis dahin noch nen Rollout.

Bestimmt sogar mehrere!
Allerdings würde ich nicht drauf setzen das einer davon dieses Verhalten hier ändert, immerhin besteht es schon so lange wie es den 2nd Scan gibt und es ist Tobit auch schon mindestens fast genau so lang bekannt :p

PS: es gibt da noch andere nette Effekte wenn man Mails via POP3 Grabbing Eintrag in Benutzerkonfigurationen einsammeln lässt und gleichzeitig MIS mit 2nd Scan aktiv hat.

Immer wieder gern genommen ist auch was passiert wenn der Benutzer für den die Nachricht eingesammelt wurde gar nicht im To: oder CC: Feld steht, weil er die Nachricht nur als BCC erhalten hat

Auch das was dann passiert zeigt wieder nur, das solcherart eingesammelte Nachrichten auf keinen fall dem lokalen Routing zugeführt werden dürfen und damit so lang der aktivierte 2nd Scan eben genau dazu führt das anschließend lokal geroutet wird eben 2nd Scan mit solcherart eingesammelten Mails unverträglich ist...

riawie wir haben das bei usn auch ebenfalls so mit den einzelnen pop3 Fächern beim Provider. Wir hatten meine ich in einem anderen Thema auch schon mal darüber gesprochen. Ich habe die pop3 auch im grabbing Server eingetragen wo man Zugang testen kann, also nicht dort im Benutzer Konto direkt die pop3 Adressen eintragen kann.

stylistics war bei usn diese Woche nochmal auf dem serve rund sagte das es standard sei bei den einzelnen Benutzern die pop3 abfragen abzulegen...

Wir kommt es denn das der sogenannte Standard nun unterschiedlich ist?

Bei usn sind es auch nur 7 Benutzer(7 pop3 Fächer) , bzw in der zweiten Firma die über den gleichen David läuft noch mal 3 pop 3 Fächer die auch zu drei der 6 Benutzer in den Posteingang gestellt werden.

Zitat von lycra

wir haben das bei usn auch ebenfalls so mit den einzelnen pop3 Fächern beim Provider. Wir hatten meine ich in einem anderen Thema auch schon mal darüber gesprochen. Ich habe die pop3 auch im grabbing Server eingetragen wo man Zugang testen kann, also nicht dort im Benutzer Konto direkt die pop3 Adressen eintragen kann.

hast Du denn auch die Auswertung des Empfängers aus einem Header für die Verteilung aktiviert?
Also z.B. nach X-Envelope-To: falls Euer Provider den Header liefert, oder sonst einem anderen zuverlässigen Header, wie z.B. hier zu sehen:

Zitat von andev

Gibt es eine spezielle Schreibweise für das auszuw. Adressfeld?

Groß/Klein, mit/ohne :

groß/klein sollte theoretisch egal sein.

der abschließende Doppelpunkt muss mit angegeben werden.

idealer Weise kopiert man den Feldbezeichner schlicht aus einem original Header einer tatsächlich über den jeweiligen Provider eingegangenen Mail, damit sollte auch die Frage der Schreibweise geklärt sein, denn dessen Mailserver Software wird das normaler Weise nicht irgendwann ändern.

Zitat von riawie

hast Du denn auch die Auswertung des Empfängers aus einem Header für die Verteilung aktiviert?
Also z.B. nach X-Envelope-To: falls Euer Provider den Header liefert, oder sonst einem anderen zuverlässigen Header, wie z.B. hier zu sehen:

Ne das haben wir so gar nicht drin. Wir haben bei Zieladresse die Empfängeradresse eingetragen bspw info@domain.de und dan im Jeweiligen Benutzerkonto dann die Emailadressen hinterlegt

ALso unter System ->Benutzer -> Benutzername auswählen ->Allgemein -> Emailadressen

Dort sind die Eingehenden und Ausgehenden eingetragen

Zitat von lycra

Ne das haben wir so gar nicht drin. Wir haben bei Zieladresse die Empfängeradresse eingetragen bspw info@domain.de und dan im Jeweiligen Benutzerkonto dann die Emailadressen hinterlegt

O.K. in dem Fall kann ich ehrlich gesagt nicht sagen wie sich das System dann verhält wenn man MIS mit 2nd Scan dann aktiviert.
Den Fall hab ich mir noch nicht angeschaut, insbesondere nicht wenn es sich um Mails mit entweder nicht im lokalen System vorkommenden eMail-Adressen oder fehlerhaften Adressen im To: Header Feld handelt.
Dem Umstand nach Das Du hier mit in den Thread von andev eingestiegen bist allerdings wohl ähnlich wie bei ihm.
Leider fehlt mir aktuell die Zeit jetzt auch diesen Case noch just for fun mal in allen Einzelheiten durchzutesten, daher muss ich bei der Konstellation passen...

Moin riawie wir nutzen MIS gar nicht daher habe ich auch gar kein Problem

Ich wollte nur wissen wie das best practice für David eigentlich wäre

lycra best practice wäre eigentlich das entsprechende Header Feld was für Euch passt für das Routing auswerten zu lassen, es sei denn in dem dort eingesammelten Postfach kommen garantiert auch wirklich nur eMails für genau diese eine von Euch als Zieladresse angegebene email Adresse an und damit ist nicht gemeint das sie alle für genau diesem empfänger sind, sondern das sie dort auch wirklich mit genau der gleichen eMail Adresse als eMpfänger hereingekommen sind und nicht etwa unter umständen auch mit anderen Mail Adressen. Denn wenn in dem POP3 Postfach möglicher Weise auch mails an andere Adressen auflaufen würden diese Mails ansonsten im David nicht den Tatsachen entsprechend dargestellt werden. In den meisten Fällen wäre das zwar unproblematisch, es gibt aber Szenarien - welche hier den Rahmen sprengen würden - wo das relevant und durchaus auch problematisch sein kann. Wenn in so einem Postfach auch Mails für mit verschiedenen anderen Empfänger Mailadressen auftauchen können ist es dann allerdings nötig diese im David auch den entsprechenden Nutzern zuzuordnen, damit die Mails auch wirklich ankommen wo sie sollen.

Ich wollte schon lange mal unsere einzelnen pop3 Accounts auf catchall umstellen. Bisher habe ich das immer vor mir hergeschoben.

Nun da aber das hiergenannte Problem auftrat, habe ich den Schritt nun endlich gewagt. Und ich muss sagen, die Umstellung ging echt flott und es läuft nun alles perfekt.

Danke an alle hier im Thread Beteiligten!

Jetzt gibt es nur noch einen Catchall-Pop-Account und die Verteilung übernimmt David über X-Envelope-to.

Nun habe ich aber doch noch eine Frage: Kann ich David so konfigurieren, dass Emails an nicht genutzte Adressen abgelehnt werden? Also der Empfänger eine Antwort nach dem Motto "Mail undeliverable" bekommt?

Zitat von georg2006

Nun habe ich aber doch noch eine Frage: Kann ich David so konfigurieren, dass Emails an nicht genutzte Adressen abgelehnt werden? Also der Empfänger eine Antwort nach dem Motto "Mail undeliverable" bekommt?

Rein technisch ginge das zwar.

Sollte man aber auf keinen Fall tun. entweder sorgt man dafür das solche Nachrichten auf smtp Ebene abgelehnt werden, oder man tut es gar nicht und kümmert sich lokal drum sie zu entsorgen, oder Tippfehler manuell bzw. mit Verteilregel zuzuordnen wenn sie denn legitim sind.

Denn, wenn man einmal per smtp durch den Provider angenommene Mails doch noch ablehnt und zurückschickt öffnet das SPAM Versendern und anderen bösen Buben Tür und Tor als Relay missbraucht zu werden, indem sie so tun als würden sie der angebliche Absender sein und an eine nicht bekannte Mail Adresse bei Euch senden, Euer System würde dann die Bounce Mail dem unwissenden eigentlichen Zeil in dem Spiel schicken und wenn die ursprüngliche Mail gut gemacht ist könnte das Opfer dadurch schon eine valide Falle gestellt bekommen. Mal ganz davon abgesehen das man so auch DOS Attacken fahren kann.

Kurzum, lass das besser!

Wenn Du solche Mails tatsächlich nicht annehmen willst solltest Du besser wie von mir weiter oben recht ausführlich erklärt statt mit einem echten catch all Postfach beim Provider eines oder mehrere mit Aliasen anlegen, so das dort alle tatsächlich existierenden Empfänger bei Euch abgebildet sind.
Dann lehnt wieder der Provider direkt beim Empfang per SMTP Protokoll live ab und die Mail wird gar nicht erst übertragen.

Wir machen das bewusst nicht, weil wir geschäftlich Zeitvorteile erzielen wenn wir auch Tippfehler Mails annehmen und sie so den gewünschten empfänger erreichen noch bevor der Absender sonst gemerkt hätte das er einen Fehler gemacht hat. besonders bei eingehenden Anfragen ist das besser, denn oftmals machen sich Absender bei mehreren Empfängern gar nicht mehr die Mühe zu klären warum wer von den angefragten seine Mail nicht erhalten hat und man wäre schon raus aus der Bieterrunde bevor man drin war. Kurzum, wir nehmen lieber alles an und löschen schlicht was nicht sinnvoll verteilbar ist

Aber rein technisch könntest Du

Danke @rawie für die schnelle uns ausführliche Antwort!

Dann werde ich das so lassen und mal schauen, welche Emails nun so in Unverteilt landen.

Ich hatte nur kurz Bedenken, dass ich nun selbst viel Spam in Unverteilt abarbeiten muss, aber das sollte ja eigentlich MIS für mich übernehmen.

Zitat von riawie

Wenn in so einem Postfach auch Mails für mit verschiedenen anderen Empfänger Mailadressen auftauchen können ist es dann allerdings nötig diese im David auch den entsprechenden Nutzern zuzuordnen, damit die Mails auch wirklich ankommen wo sie sollen.

das ist bei uns eigentlcih nicht der Fall.

7 Benutzer

jeder hat eine E-mailadresse, bzw 3 Benutzer erreichen von einer zweiten Firma mit 2. DOmain auch eine personifizierte E-Mail.

Ich habe beim E-Mailprovider jeweils für jeden Benutzer seiner E-Mailadresse eine Aliasadresse erstellt mit einem POP3 und die werden abgerufen.

Über Regeln lassen wir uns aber auch bsüw info@domain an mehrere Benutzer verteilen.

Können wir das System so weiter laufen lassen oder sollten wir auf das best practice mit der catchall umstellen?!

lycra das kannst Du ruhig so weiter laufen lassen, mit dem Setup hast Du die meisten Stolpersteine weg, wie geschrieben, könnte man das noch an der Stelle mit der Zeile auszuwertendes Adressfeld statt Zieladresse optimieren, aber generell sollte das auch so o.k. sein, so lang die oben von mir beschriebenen Bedingungen gewahrt bleiben und entsprechend die Auswertung eines Adressfeldes wie z.B. X-ENVELOPE-TO: eh immer das gleiche Ergebnis wie der derzeitige Eintrag in Zieladresse ergeben würde.

andev WTF? Nee, da bin ich jetzt vor allem sprachlos

Ich konnte das was du oben anfänglich beschrieben hast zu 100% provozieren und reproduzieren, aber das hier ist mir nun schleierhaft...

Da wird wohl ein tieferer Blick ins System fällig werden um dahinter zu kommen :o

Hallo alle,

Ich habe diese erfahrung mit verteilregeln die berichte nach ein archiv kopieren oder verschieben das nicht mehr existiert (also gelöscht ist).

Gruss,

Arjan.

Zitat von ArjanM

Ich habe diese erfahrung mit verteilregeln die berichte nach ein archiv kopieren oder verschieben das nicht mehr existiert (also gelöscht ist).

Ja, sowas hat natürlich im Ergebnis die gleiche Folge, guter Hinweis