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 
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.
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...
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
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.
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.
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)
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
