Mails direkt im Archiv

Hab gerade mal bei mir nachgeschaut und hab tatsächlich auch eine Handvoll Mails dort gefunden. Die älteste aus Juli, die neueste von heute. Verschiedene Absender, verschiedene Emfpfänger, kein Muster erkennbar.

Das merkwürdigste war eine Mail von gestern an die ich mich gut erinnere, die war gestern noch in meinem Eingang, jetzt ist die im Root-Verzeichnis. Ich habe die aber definitiv nicht verschoben.

Heute waren wieder zwei Emails im Root-Verzeichnis. Ich kann mir das nicht erklären.

Grad mal geguckt bei mir ist das (zum GLück) nicht der Fall...

Hilft nicht aber zumindest scheint es kein generelles Problem zu sein

Hab das bis Dato auf einer Installation gesehen, meist wenn der Betreff: bla bla bla "bla bla" enthält.

Es kommen aber auch eMails richtig an die ähnlich Aufgebaut sind...

Zitat von andev

Hab inzwischen mit dem Support raus, das es am 2nd Scan des MIS liegt.

Schaltet man den 2nd Scan aus, laufen da keine Mails mehr rein.

Deswegen haben auch nicht alle das Problem. Nur die, die dafür bezahlen

Sauber!

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

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?

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.

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

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

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