Beiträge von riawie

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

tobit-user-24 das was Du Dir da vorstellst ist nicht möglich, denn an der Stelle wo diese @@Befehle ausgewertet werden hat der David Server gar keinen Zugriff auf die Adressbücher.

Die Logik bei der Auswertung von @@AN oder @@Nummer prüft auch rein ob sich in dem String danach ein @ befindet oder nicht, alles was kein @ enthält wird als Faxnummer behandelt, alles was ein @ enthält wird als eMail behandelt. Wenn so ein Auftrag allerdings über den Druckertreiber rein kommt wird immer eine Faxnummer erwartet.

Also entweder bringst Du Deiner Warenwirtschaft die FAX-Nummern bei, oder die Nummer muss immer mit eingetippt werden.

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 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:

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

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

Zitat von andev

Da 99,9% der Mails mit den "falschen" Einstellungen ja korrekt ge'2nd scannt und zugestellt werden, ist die Rechnung leider nicht so amortisierend.

Du hast das offensichtlich schon wieder falsch verstanden...

Es geht bei meiner Anmerkung zu den Kosten nicht darum das sich die Umstellung bestehend gegen Best practice und RFCs eingerichtete Benutzerkonten und Mail Server irgendwann amortisieren würde.

Es geht darum das es weniger aufwändig und damit kosteneffizienter ist einen neuen Benutzer auf die richtige Weise einzurichten als auf diese von hinten durch die Brust ins Auge Methode welche Ihr da - wie nicht wenige andere auch - bisher genutzt habt.
Die mögliche Amortisation des Aufwandes das nun mal zu korrigieren rührt also folglich daher das künftige Kosten bei neuen Nutzern die in solchen Systemen dazu kommen geringer ausfallen als bisher.
Weiterhin führt eine optimale Einrichtung natürlich auch zu einer Verminderung von Fehlerquellen und somit Supportkosten für solche Fehler.

Davon abgesehen sollte man einmal erkannte Fehler schlicht nicht ewig weiter machen, nur weil man das immer schon so getan hat und es schon irgendwie auch ging oder einfach nur nicht stark genug geschmerzt hat...

Zitat von andev

oder sämliche Abholungsmethoden umzubauen und ggf. noch Personal zu Schulen, das sie die Konten anders anlegen, als gewohnt.

wenn man das richtig macht spart das je neu einzurichtendem Konto relevant Arbeitszeit und damit Geld, was sich also durchaus auch so auswirkt das man diese Umstellung mittelfristig bis langfristig wieder amortisiert

Zitat von andev

Da hast du wohl recht. Diese Mails aus M$ System dürfen wirklich nicht ins System eingeleitet werden...

Weder im To als im X-Envelope-to sind ' vorhanden. Nur name@domain.de und dazu auch noch die richige.

Haha, LOL ich hatte die bisherige Darstellung so verstanden das bei Euch nur Mails welche die im To: Header ' enthielten im zentralen Archiv landeten.

Wenn das auch mit anderen Mails passiert deren Header völlig in Ordnung sind müsste man sich die Geschichte detaillierter anschauen, was dort im einzelnen die Ursache ist.

Allerdings ändert das nichts daran, das die Kombination aus: Wir holen Mails mit dem Grabbing Server explizit über POP3 Konten die in den Nutzer Daten definiert werden und damit unter Umgehung einer Auswertung der eigentlichen Empfänger Adresse ab um sie dann anschließend dem 2nd scan vorzuwerfen halt besonders Fehleranfällig ist.

Würde man sie über zentrale POP3 Abrufaufträge abrufen und dabei das X-Envelope-To: header Feld auswerten hätten sie zumindest mal ein klares Zustellungsziel das der Postman zuverlässig auswerten kann wenn er die Nachrichten vom 2nd Scan vorgeworfen bekommt.

Zitat von andev

Natürlich kann ich erwarten, das der Grabbing Server so modifiziert wird, das er die Mails an die im to/envelope-to adressierte Person abliefert.

Wenn im To: header eine fehlerfreie Adresse die so auch im system existiert eingetragen ist kannst Du das in jedem Fall erwarten.

Wenn Du aber Mails per Grabbing Server pro Nutzer über dessen Benutzerkonfiguration einsammeln lässt kannst Du in Bezug auf die Mail Adresse im X-Envelope-To: header schlicht gar nichts erwarten, denn Du hast den Grabbing Server ja explizit nicht angewiesen sie überhaupt zu beachten.

Damit der X-envelope-To: Header überhaupt beachtet werden kann musst Du den Abruf über die Systemweite POP3 Abrufkonfiguration veranlassen und dann das auswerten des gewünschten Header Feldes "X-Envelope-To:" dort auch einschalten.
Das hast Du aber laut Deinen Antworten auf meine Fragen nicht getan und lehnst es auch ab das zu tun.

Bitte verstehe mich nicht falsch.
Wenn man Fehler zu deren Beseitigung identifizieren will ist es halt schlicht notwendig sich sehr genau Mühe zu geben alle Umstände auch genau darzustellen und Nachfragen sowie Erklärungen von Leuten die einem dabei helfen möchten sehr genau zu lesen und nichts durcheinander zu würfeln.

Zitat von andev

Die fehlerhafte Zustellung hört auf, wenn man den 2nd Scan abschaltet. Nach deiner Theorie werden die zuvor vermeintlich fehlerhaften Header, bei der Abschaltung des 2nd Scan also wieder korrekt, weil das Problem an den Headern liegt?

Nein, das hast Du falsch verstanden.

Nur wenn 2nd Scan aktiv ist wird bei der Art wie Ihr Eure Mails abholt der To: Header überhaupt für die Auslieferung der Mails in die Nutzerpostfächer herangezogen.

Ohne 2nd Scan legt der grabbing Server die Nachrichten welche er abholt direkt im Postfach des Nutzers ab für den er sie abholt - weil der entsprechende POP3 Eintrag in dessen Nutzerdaten definiert ist.

Es wird also kein defekter Header wieder heile, er wird nur gar nicht erst genutzt

Mit 2nd Scan parkt der grabbing Server die abgeholten Nachrichten erst mal im Transit Ordner, wo sie nach ablauf der eingestellten Zeit vom 2nd scan behandelt und nach durchlauf durch den 2nd scan dann vom postman an ihr eigentliches Ziel verteilt werden.
Der Postman wertet nun den To Header aus und dann passiert der Fehler mit der falschen Ablage.

Hier gibt es zwei Möglichkeiten das Problem mit den To: Headern zu lösen:
1. man holt Mails anders ab und wertet dabei den X-Envelope-To: Header aus, damit beliben To: oder auch CC: Header unberücksichtigt und selbst Mails die ihren Empfänger nur via BCC erreicht haben können zugestellt werden.
2. Tobit programmiert den grabbing Server so um, das er - im Fall dessen das er Mails für einen definierten Benutzer einsammelt - die Mails im Transit so ablegt, als hätte er sie unter Auswertung von X-Envelope-To: header getan und klebt ihnen entsprechend ein Label mit dem im System tatsächlich existierenden Benutzer an, allerdings darf dafür aus verschiedenen Gründen auf keinen fall eine eMail Adresse verwendet werden, weil das sonst unter gewissen Umständen welche immer noch legale Konfigurationen und Mail Weiterleitungswege betreffen zu anderweitigen Problemen führt.

Technisch gesehen ist Lösung 1. nicht nur schneller zu realisieren, sie birgt auch weniger Risiken für weitere Fehler.

Es gäbe natürlich noch eine 3. Variante das Problem aus der Welt zu schaffen Tobit könnte 2nd scan schlicht für direkt über das Konto eines Benutzers eingesammelte POP3 Mails verweigern und das deutlich kommunizieren.
Das allerdings birgt das Risiko das viele David Administratoren das nicht verstehen und denken sie hätten 2nd scan aktiv obwohl sie es nicht haben :o

Womit ich dabei bleibe: Variante 1. ist die intelligenteste Lösung des Problems

Zitat von andev

Ok, mache von den Mails haben ein ' im To, die dürfen dann auch falsch zugeordnet werden.

Das sind aber nicht alle und zudem sollten die dann nicht in Unverteilt laden?

Das habe ich oben versucht zu erklären.

Nur Mails mit einem defekten To: Header oder solche bei denen der To: Header keine im system konfigurierte eMail Adresse enthält haben eine Entschuldigung nicht bei dem jeweiligen Nutzer im Postfach zu landen.
Von diesen Mails haben wiederum nur jene mit einem defekten Tö: Header einen Grund dann nicht zumindest im Unverteilt zu landen. Wobei dieser Grund allerdings in der Tat eine Fehlfunktion im David Server ist, denn wenn der seinen Job zu 100% korrekt machen würde müssten diese Nachrichten entweder im Unverteilt, oder im zentralen SPAM Ordner landen.

Mein dringender Rat von oben die Art der Abholung der Mails vom Provider umzustellen hat nur ein einziges Ziel und das ist es schlicht zu verhindern das defekte To: Header sich überhaupt auswirken können. denn wenn man X-Envelope-To auswertet ist es schlicht völlig egal was im To: Header steht und damit auch egal ob der Header fehlerfrei aufgebaut ist oder nicht.

Für alles weitere erscheint mir eine detailliertere Analyse der sich bei Euch zeitweilig im zentralen Archiv wiederfindenden Mails vor Ort dringend geboten.

Allerdings ist es schon aus datenschutzrechtlichen Gründen nicht möglich das hier über das Forum zu tun. Denn dazu bräuchte man Zugriff auf vollständige Mail Header die nicht anonymisiert werden dürfen, weil man nur so wirklich sehen kann ob sie fehlerfrei sind oder eben nicht und wenn ja, welche Fehler sie enthalten. Das aber schließt sich aus Datenschutzgründen für ein öffentliches Forum aus.
Da ich auch generell keinen Support gegen Bezahlung anbiete, weil das nicht der Businesscase meines Arbeitgebers ist kann ich Dir aus rechtlichen Gründen auch schlicht nicht konkret helfen,es sei Denn Du selbst identifizierst die weiteren Fehler in den Headern der betroffenen Mails, aber dann würdest Du hier nicht um hilfe fragen wenn Du das könntest, sondern hättest Informationen geliefert auf was andere achten sollten
Aalso nichts für ungut, aber Du brauchst jemanden der konkret auf Dein System guckt um den Fehler zu identifizieren.

Einstweilen kann ich Dir nur den oben bereits genannten Workarround anbieten.
Oder Du lebst schlicht damit das Ihr auf den 2nd Scan verzichtet und trainierst Deine Anwender um so gründlicher wie sie bösartige Mails von guten Maisl unterscheiden lernen und nimmst hin das dies nennenswert Arbeitszeit kosten kann.

Und nur so am rande zur Frage: braucht man den 2nd Scan oder nicht?
In unserem Unternehmen könnte man durch die eingesparte Arbeitszeit welche die Nutzung von MIS in Verbindung mit 2nd Scan ergibt durchaus einen Mitarbeiter bezahlen der hauptberuflich alle eigehenden Mails vor Zustellung an die eigentlichen Empfänger sichtet und nur ungefährliche verteilt. Wenn der dann auch gleich noch unnütze Mails mit aussortieren würde könnte man ihm noch eine Kollegin geben damit die zusammen das Volumen auch zeitnah genug abarbeiten können um mit dem 2nd Scan mitzuhalten.
Kurzum: brauchen vielleicht nicht, aber der Einsatz von MIS in Kombination mit 2nd Scan erhöht die profitabilität unseres Unternehmens doch messbar.
Aber: das kann in jedem Unternehmen unterschiedlich sein

andev da kann man jetzt trefflich drüber streiten.

Zunächst sind die eMails über welche wir hier reden so sehr defekt ins Weltweite eMail System eingeleitet worden, das sie eigentlich bereits vom ersten empfangenden Server hätten abgelehnt oder verworfen werden müssen, denn einfache Hochkommata sind schlicht unzulässig im To: Header.
Würden alle transportierenden Mail Server auf dem Weg ihren Job korrekt gemacht haben gäbe es folglich gar kein Problem auf Eurem David Server, weil diese Mails ihn nie belästigen würden.
Dummer Weise haben viele Mail Transport Programmierer sich aber dazu entschieden das es unerwünscht ist Müll schlicht wegzuwerfen und versuchen das Zeug doch irgendwie zuzuordnen und wieder gescheit loszuwerden. Das ist schade, denn so haben die produzenten derart defekter Mails ja keinen Anreiz dazu das mal zu korrigieren

Wenn nun der David Server alles richtig machen würde müssten solche defekten Mails die explizit für einen Nutzer eingesammelt wurden eigentlich in dessen SPAM Ordner landen, denn diese Mails enthalten einen fundamental defekten Header.

Würde der Verwalter des jeweiligen David Servers seine Arbeit richtig gemacht haben und den Transport der Mails von seinem Provider zu seinem David Server sinnvoll eingerichtet haben würde der Fehler welchen eigentlich mal der Absender der Mail eingebaut hat gar nicht mehr auf den David Server durchschlagen und die Mails würden durchgängig zweifelsfrei dem richtigen Nutzer zugeordnet. Womit sie dann - aufgrund des Wunsches das Admins die Message Identifikation zu bemühen - wiederum als fundamental defekte Mails im SPAM Ordner des betreffenden Nutzers landen sollten.

Das Problem mit dem 2cnd Scan scheint aktuell so zu sein, das der Grabbing Server Mails die er für einen speziellen Nutzer einsammelt dem 2nd Scan ohne ein Schildchen dran für welchen Nutzer er sie eingesammelt hat vorwirft. Anschließend darf der postman nach durchlauf durch den 2nd scan raten wem er die Nachrichten zustellen soll und trifft auf den fehlerhaften To: header welcher eine email Adresse enthält die auf keinen einzigen User bzw. keine bei einem Nutzer im System eingetragene eMail Adresse matcht. Aufgrund eines weiteren Fehlers im Postman matcht diese Mail wohl allerdings auf den zentralen Archiv Knoten und entsprechend landen die Nachrichten dann dort, statt wie man erwarten würde im Unverteilt Ordner oder noch besser im zentralen SPAM Ordner.

Natürlich kann man nun drauf warten das Tobit den Grabbing Server so modifiziert, das er die Nachrichten stets mit einem Schildchen welchem User sie gehören, oder das Tobit den Postman so modifiziert, das er den To Header trotz der dort klar verbotenen Hochkommata korrekt auswerten kann.

Man kann aber natürlich auch einfach seinen David Server mal korrekt an seinen Provider anbinden und somit auch gleich dafür sorgen das nicht nur dieser Fehler welcher sich in To: Headern verbergen kann, sondern auch weitere dort schlummernde Fehler ein für alle Male entschärft werden und damit im Ergebnis nicht nur das Problem sofort los ist, sondern auch mal selbst eine RFC konforme Installation betreibt

Zitat von andev

zu 1) Mails kommen via POP3 über den Grabbing Server.

zu 2) Zuordnung lt. David Standard (Eingetragene Adressen im Benutzer)

Soll heißen Ihr holt für jeden Benutzer seine Mails separat vom Provider ab?

Oder holt Ihr die Mails über ein gemeinsames POP3 Konto beim Provider für alle dort eingehenden Mails (Catch All) ab und lasst die dann vom David Server auf die Nutzer verteilen?

Meine zweite Frage bezog sich auf den letzteren Fall und das dabei von Euch zur Auswertung im zentralen POP3 Konto des Grabbing Servers eingetragenen Feld bei Verteilung, was im Idealfall wie folgt aussehen sollte:

Meiner Erfahrung nach kommen die fehlgeleiteten Mails im zentralen Archiv vor allem dann vor, wenn man nicht mit einem catch all Postfach und entsprechend auch nicht mit Auswertung eines vom Provider genutzten Headers für den tatsächlichen Empfänger, wie z.B. "X-ENVELOPE-TO:" arbeitet.
Bei Auswertung des "X-ENVELOPE-TO:" Header Adressfeldes eingehender Nachrichten sollten nämlich auch ausschließlich RFC konforme Empfängeradressen auftreten.

Selbst wenn man aus "Gründen" kein Catch All Postfach nutzen wollen würde wäre mein Weg daher stets alle POP3 Abrufe direkt in der POP3 Postfächer Datenbank des Grabbing Servers anzulegen um dort die Möglichkeit zu nutzen die Empfänger Adresse über das "X-ENVELOPE-TO:" Adressfeld oder ein anderes vom eigenen Provider befülltes Adressfeld auszuwerten.

wie kommen Eure Mails rein bzw. wie holt ihr sie bei Eurem Provider ab und welches Header Adressfeld wertet Ihr bezüglich der Erkennung der lokalen Empfänger aus?

wie kommen Eure Mails rein bzw. wie holt ihr sie bei Eurem Provider ab und welches Header Adressfeld wertet Ihr bezüglich der Erkennung der lokalen Empfänger aus?

wir haben das Problem ebenfalls nicht, nutzen aber sehr wohl den 2nd Scan des MIS

es scheint da also zumindest kein generelles Problem zu geben

Zitat von lycra

Bei Telekom mit 0,49€ / Fax ist das ja doch relativ teuer?!

Wer zahlt denn freiwillig 0,49€ für ein Fax?
Wir sind zwar nicht bei der Telekom, sondern bei Vodafone, aber Fax ist letztlich auch nur eine Telefonverbindung und somit von der normalen Flatrate abgedeckt...

Zitat von nordtech

Mich persönlich stört es nicht übermäßig; am wichtigsten ist für uns, dass im Ausgang ersichtlich ist, ob die Mails aus der Warenwirtschaft ordnungsgemäß versandt wurden. Wenn man dann das angehängte PDF auch noch öffnen könnte, statt nur die base64-Codierung anzuschauen, wäre das natürlich praktisch.

Wenn Du das nur im Einzelfall mal prüfen willst ist das simpel, einfach die Nachricht mit der Maus aus dem entsprechenden Postausgangsarchiv z.B. auf den Desktop ziehen und dort dann mit einem Texteditor öffnen. vor der ersten Leerzeile nach "Content Type" suchen, diese Zeile + die darauf folgende löschen, das ganze speichern und fertig. anschließend lässt sich die Nachricht per Doppelklick mit dem David Client Viewer öffnen und die Anhänge lassen sich zu Prüfzwecken anschauen.

Eigentlich muss Tobit an dem Verhalten seines Systems eigentlich nur eine Kleinigkeit ändern.

Entweder lassen sie bei rein nach extern weitergeleiteten Mails diese zwei HeaderZeilen weg, welche eh nicht Standardkonform sind.

Oder sie werten beim betrachten solcher Mails auch die Original Headerzeilen aus und verhalten sich so wie fast alle anderen Mail User Agents, wo immer der letzte gefundene "Content Type" Header gewinnt.

Aus logischen Gründen wäre ich natürlich für die erste Variante

Zitat von lycra

Ich hab es nicht gemeldet weil ich nicht einmal weiß was ich genau melden soll kann es aber gerne tun wenn ich es gesagt bekomme

Einfach mit eigenen Worten beschreiben was stört und dann die Rückfragen beantworten

Nee, im Ernst, ich melde ja im Normalfall auch nur was uns persönlich stört.
Was so wie dieses Problem völlig unterm Radar schwimmt melde ich auch nur wenn ich es hier mitbekomme und merke das der Leidensdruck bei anderen groß ist und es helfen könnte wenn es mehr Leute melden.

bisher hat mich das nicht gestört, weil es halt bei dem Empfängern lesbar ankommt.

Aber ich guck mir das gerne mal im Detail an.

Die Mails jedenfalls sind bei uns intern recht leicht lesbar zu machen, es müssen nur 2 Zeilen aus dem Header gelöscht werden, schon ist die Nachricht im David Editor ganz normal lesbar.

Der David Server hängt beim externen weiterleiten der per SMTP erhaltenen Nachrichten einen eigenen Content Type Header vorne an, welcher allerdings aussagt das es sich um eine plain Text Nachricht handeln würde.
Dummer Weise wertet der David Mail Client / Editor nur den ersten dieser Content Type Header aus um zu entscheiden wie er den Rest der Nachricht behandeln soll.
Löscht man diesen ersten Content Type Header kann die Nachricht sowohl vom David Client, als auch von allen anderen Mail Readern normal behandelt werden.
Die meisten anderen Mail Reader werten alle im den Header Zeilen enthaltenen Content Type Header aus und der letzte gewinnt, daher stellen sie das ganze dann auch korrekt dar

Es gibt da noch einen weiteren Fehler in der von David beim smtp forwarding erzeugten Mail, welcher für die Anzeige durch den David Client und wohl auch die meisten anderen Clients nicht von Bedeutung ist, allerdings dennoch klar gegen geltende Standards verstößt und von daher bei anderen Mail Programmen eventuell zu fehlern führen kann.
Und zwar findet sich eine Leerzeile zwischen den Headerzeilen welche bis einschließlich der Annahme per smtp durch den David Server entstanden sind.

Ich denke mal das wird man bei Tobit melden müssen, damit sie es korrigieren und genau das wird bislang noch niemand getan haben.

Zitat von bic

Sorry, dass ich mich hier um 21/2 Jahre verspätet einklinke, aber wir stehen auch vor diesem Problem. Aber nachdem nun das Thema hier als erledigt abgehakt ist, ich in den Beiträgen jedoch keine Lösung erkennen kann, wollte ich darum bitten, mir diese nochmals mitzuteilen.

Vielen Dank!

Das verwundert nicht, das Du in den Beiträgen keinen Lösungsweg findest, denn damals hat man augenscheinlich herausgefunden das es sich nur um ein kosmetisches und kein reales Problem handelte...

LOL, bei mir geht es einwandfrei im DvAdmin Portal, ich hab das noch nie im Browser gemacht :o