Normaler Weise kann man das schon sehen,
Einfach im globalen Eingangslogbuch nachgucken welche Mail zuletzt im jeweiligen Postfach empfangen wurde, die nächste Mail in chronologischer Reihenfolge ist das dann eigentlich auch.
Wir hatten das auch noch nie bei einer legitimen Mail, das hat immer Mails betroffen welche man eh nicht haben wollte. kommt aber insgesamt zum Glück sehr selten vor.
Beiträge von riawie
-
-
Regeln in den jeweiligen Ausgängen sind da Dein Freund.
Wenn Du verhindern willst das die jeweiligen Nutzer diese Regeln ändern oder löschen entziehe ihnen für die archive.urt in ihrem jeweiligen Ausgang auf Dateisystemebene das schreibrecht.
Damit können sie dann natürlich auch nicht selbst eigene Regeln in ihrem jeweiligen Ausgang anlegen, was aber meist kein Problem darstellt, da die wenigsten Nutzer Regeln in ihren Ausgängen nutzen. -
Wobei das letztlich mit jedem System hätte passieren können welches rein digital arbeitet und auf Unterschriften - wie sie augenscheinlich nur die KVWL fordert - verzichtet.
Ähnliche Regress-Fälle hat es ja bereits einige unter anderen Voraussetzungen - welche ebenfalls als ungenügend angesehen wurden - gegeben.
Da ist es wohl eher eine nebensächliche Frage ob das ganze nun ausgerechnet mit chayns realisiert wurde, oder mit welchen Bausteinen sonst.
Relevant wird das für uns wohl nur dann wenn dieser (und/oder) andere Teststellenbetreiber deswegen irgendeinen Hebel haben sollte um Tobit als Lieferant in Regress zu nehmen und das dann für Tobit zu teuer werden sollte.
Die Frage bei der ganzen Geschichte ist aber halt eh wieviel von der ganzen Geschichte wir hier in dem Bericht nicht erfahren. -
wenn da noch der SQL-Express 2008 R2 läuft würde ich zuerst mal dessen Service Pack 3 installieren und anschließend das ganze auf SQL-Express 2017 upgraden, denn der 2008 R2 ist schon lange sowohl bei Microsoft, als auch bei Tobit nicht mehr unterstützt.
Soweit ich das verstanden habe hast Du ja bislang auch erst einen Trockenlauf durchgeführt um vorab zu testen was für Probleme auf Dich zukommen.
Da würde ich dann das SQL-Express 2008 R2 SP3 noch auf dem Windows Server 2012 installieren, dann das Inplace Upgrade des Windows Servers durchführen und als nächstes das Upgrade des SQL Servers auf Version 2017 durchführen.
Für das Upgrade des SQL Servers als solches gibt es aus der Zeit wo das aktuell war von stylistics hier im Forum auch ein kleines Video Tutorial:
SQL Migration vom 2008R2 auf 2017 Express
Um eventuelle Probleme das David Servers nach dem Windows Server Inplace Upgrade auf den SQL Server zugreifen zu können würde ich mich jedenfalls erst kümmern nach dem auch der SQL Server auf dem aktuell von Tobit vorgesehenen Stand 2017 angekommen ist, welcher auch von Microsoft noch zur Nutzung unter Windows Server 2019 freigegeben ist. -
Envelope-To werten wir aktuell nicht aus - korrekt.
ist in Eurer aktuellen Situation halt auch gar nicht möglich.
Allerdings wäre es sinnvoll den 1&1 Support mal drauf hinzuweisen das sie das Feld schlicht falsch behandeln. Da gehört schließlich nicht die Adresse eures catchall Postfachs rein, sondern trotz allem noch immer die Adresse für welche die Mail ursprünglich via smtp eingeliefert wurde. -
Ich sags ungern, aber das ist ganz klar noch ein Grund mehr Euren Vertrag bzw. euer Hosting Paket dort mal gegen was aktuelles zu tauschen.
Normaler Weise sollte der Mail Server Eures Providers den Envelope To: Header mit der Adresse füllen für welche die Mail per SMTP ursprünglich eingeliefert wurde und einen bereits vorhandenen Envelope-To: Header auch niemals überschreiben.
Bei der Chayns Mail müsste gemäß des ältesten Received Headers:
Received: from mail.tobit.software ([62.153.122.27]) by mx.kundenserver.de(mxeue101 [217.72.192.67]) with ESMTPS (Nemesis) id 1MRUpv-1rHadA015R-00KAMp
for <user01@domain.de>; Tue, 27 Feb 2024 11:01:05 +0100
Der Envelope To: Header folglich den Inhalt user01@domain.de bekommen wenn die Mail das erste mal auf mx.kundenserver entgegen genommen wird.
Statt dessen trägt der 1&1 Server dort die Adresse des Catchall Postfachs admin@domain.de ein, was vermutlich dadurch zu Stande kommt das von Euch genutzte Altsystem 1&1 das Altsystem hinter dem sein aktuellen System von 1&1 IONOS arbeitet. Dieses neue System scheint aber bereits einen Teil der Informationen zu haben und auch auszuwerten, welche eigentlich nur der letzte Mailserver des Providers auswerten sollte und somit der letzte Server die Mail bereits für das catchall Postfach übergeben bekommt, was zwangsläufig zu Problemen führen muss.
Allerdings ist Eure Situation da nicht der einzige Schuldige, denn wenn Chayns die Mail mit einem To: Header verschicken würde könnte Euer David Server sie dennoch korrekt zuordnen, da Ihr ihn ja scheinbar bislang gar nicht nach dem Envelope-To Header schauen lasst. -
da scheint es ein Problem mit der Einstelolung des eingestellten Headers welcher zur Verteilung der eingehenden Mails auf die einzelnen Nutzer verwendet werden soll zu geben.
Soweit ich es nicht durcheinander bringe seit Ihr das doch mit dem uralt 1&1 Hosting Vertrag.
Die Wahrscheinlichkeit auf jemanden mit genau der gleichen Konstellation zu treffen wird vermutlich eher gering sein...
Anonymisiere doch mal den Mailheader und stelle ihn hier rein, dann schreib dazu welchen Header Ihr in Eurem David Postman auswerten lasst um die Mails aus dem catchall Postfach an die Nutzer zu verteilen -
wenn es nicht das Standard Kennwort der Site-ID ist wird wohl schon mal jemand einen Chayns Login mit der Site-ID durchgeführt haben und dort ein neues Kennwort gesetzt haben.
Entsprechend ist dann das dort vergebene Kennwort auch hier zu nutzen. -
aber es ist alles ziemlich umständlich und teilweise ziemlich kostenintensiv, da wir auch Mail Business Lizenzen benötigen für ein paar Postfächer (10 Stück kosten z.B. 25€ / Monat)
Das klingt in der Tat etwas wild, wenn man bedenkt das Ihr einen David Server habt.
Wir haben unsere Domains bei Strato gehostet und sind dort sehr zufrieden.
Dort lassen sich problemlos alle nötigen DNS Einträge verwalten, Mail Postfächer mit Basis Funktionen wie man sie braucht wenn man eh einen eigenen Server betreibt kosten nichts extra und bieten dennoch Virenscan + selbst definierbare Filter zum abweisen unerwünschter Nachrichten.
Was die kosten angeht kann ich da nicht recht mitreden.
Wir haben ein Paket mit 20 Domains gebucht welches uns 22€/ Monat kostet, dafür aber auch einen Haufen Mail Postfächer + jede Menge anderer Funktionen zu Verfügung stellt.
Wir sind nun schon mehr als 25 Jahre Strato Kunde und ich kann das uneingeschränkt empfehlen.
Ein Umzug von einem Provider zu einem andere ist übrigens nichts was mich schrecken würde, gut vorbereitet und durchdacht ist das ohne nennenswerte Serviceunterbrechung zu bewerkstelligen.
Der letzte solche Umzug den ich gemacht habe fand im letzten Sommer statt und führte obwohl mitten am Tag durchgeführt und obwohl die Mails von der Domain damals über Exchange online bei Microsoft aufliefen, zu keiner einzigen vermissten mail und zu keiner relevanten Service Unterbrechung. Ich schicke in solchen Fällen immer selbst im 10 Sekunden Takt Testmails während des Umzugs an die umzuziehende Domain und kann daher sehr genau sagen das da keine Empfangslücke war. Dabei ist übrigens das Ziel wohin man umzieht wichtiger als die Quelle von der man kommt wenn es um eventuell untergehende Mails geht.
Kurzum, wenn IONOS 1&1 das nicht sinnvoll und zu vertretbaren Kosten intern für Euch verbessern kann, such Dir einen neuen Provider aus, informiere Dich gut, bereite das gründlich vor und zieh das Ding um. Dann hast Du für die Zukunft eine solide Basis
-
ammermueller das muss dann aber schon echt steinalt sein
, denn TXT Records konnte man bei 1&1 schon vor 20 Jahren selbst hinterlegen.
Ich würde ja bei 1&1 anfragen ob es da nicht eine Möglichkeit gibt ohne Downtime für die Dienste innerhalb von 1&1 auf ein moderneres Paket zu wechseln.
Sowas wird Euch ja sonst immer wieder mal einholen... -
wie gesagt, wir haben die Domain bei 1&1 NICHT ionos.
Leider habe ich bei 1&1 absolut keine Möglichkeit irgendwas an der Domain zu ändern ... was leider sehr ärgerlich ist
die adminoberfläche ist sehr rudimentär
Oh, sorry, durcheinander gebracht :o
Das ich mal eine Domain bei 1&1 betreut habe ist schon eine ganze Weile her, aber soweit ich mich erinnere ging es damals durchaus dort selbst txt DNS Einträge zu setzen.
Hängt das vielleicht am konkreten Produkt welches dort gebucht wurde?
Ansonsten wäre der Weg bei 1&1 in etwa wie folgt:
1. beim 1&1 Konto anmelden
2. "Domains und SSL" öffnen
3. zu der Domäne navigieren welche als email Domäne genutzt wird
4. unter "Aktionen" den Punkt "DNS" auswählen
5. "Record hinzufügen" klicken und "TXT" auswählen
6. unter Hostname den Wert aus dem David Administrator Feld "Bezeichnung des DNS Eintrags" einfügen. Wenn dort nur nach einem Präfix gefragt wird, dann nur den vorderen Teil endend mit "._domainkey" einfügen.
7. unter Wert wird der Inhalt aus dem David Administrator Feld "Öffentlicher Schlüssel" welcher sich dort mit einem Knopf ins Clipbord kopieren lässt eingefügt.
8. Speichern klicken und fertig. -
wobei wir noch nie von einem Sicherheitsvorfall rund um Tobit David gehört haben, oder?
Mal davon abgesehen das wir nicht wissen ob Tobit einfach immer nur schnell genug reagiert hat, das Produkt zu sehr Niesche ist als das sich schon ernsthaft damit beschäftigt worden wäre, oder bei Tobit einfach Programmierer sitzen (bisher gesessen haben?) welche schlicht nach security by design Prinzipien programmieren, oder einfach bislang nur viel Glück im Spiel war.
Ist es halt eine gewagte Wette sich bei so einem Produkt mit derart offenkundiger Angriffsfläche, welches direkten Kontakt zur Außenwelt hat nicht abzusichern eventuelle Sicherheitsupdates umgehend zur Verfügung zu haben wenn sie dem Rest der Welt zur Verfügung gestellt werden. -
Also wies aussieht, schauen wir bei 1&1 (nicht ionos) weiterhin in die Röhre bzgl. DKIM / DMARC
Im Kundenportal gibts keine Möglichkeit etwas zu konfigurieren und Support hält auch die Füße still.Hast Du bei ionos tatsächlich keine Möglichkeit txt records im dns für Eure Domäne zu setzen?
Oder ist Dir nur nicht klar das ein DKIM Record letztlich nichts anderes ist als ein txt Record im dns der jeweiligen Domäne? -
Das passiert halt aus Effizienzgründen nicht.
War aber halt schon immer so und betrifft eben nicht nur den Papierkorb. -
caddo wir hatten das Thema mit der gemischten Verknüpfung von verschiedenen Bedingungen mittels UND + ODER hier vor Monaten schon mal im Forum. Damals war ich selbst noch der Meinung, das es gehen würde, wurde aber eines besseren belehrt und kann das hier in unserer Installation auch ganz klar nachvollziehen. sobald ich hier ein ODER in einer Regel nutze werden andere mit UND verknüpfte Bedingungen nicht mehr ausgewertet wenn eine mit ODER verknüpfte Bedingung zutrifft.
Wenn ich das Beispiel von Dir nachbaue wird nur für den ersten Absender zusätzlich geprüft ob die Mail eine Rundsendung ist.
Bei allen anderen löst die Regel auch dann aus wenn es sich nicht um eine Rundsendung handelt. -
die verschweinden mit der nächsten Datenbereinigung
Erst wenn sie auch tatsächlich aus dem Papierkorb gelöscht wurden.
So lange eine Mail noch in irgendeinem anderen Ordner vorhanden ist bleiben die eigentlichen Dateien weiterhin an ihrem Ursprungsort erhalten. -
graef-edv ja, man kann beliebig viele UND Verknüpfungen in einer Regel haben.
Beliebig viele ODER Verknüpfungen gehen auch.
Das hatte ich in meinem ersten Kommentar aber auch bereits geschrieben
Nur so wie in dem Beispiel von caddo oben UND mit ODER kombinieren liefert halt komische bzw. unerwartete Ergebnisse.
Und ich hatte eigentlich genau diese Kombination von UND + ODER angesprochen -
deinstalliere mal beide Clients einmal komplett.
Dann installiere den Client neu mit dem "david-client.exe" genannten Installationspaket, das ist das größte der Installationspakete mit rund 280 MB und wähle dabei die 64 Bit Version aus. -
graef-edv ich glaube irgendwie haste mich missverstanden :o
UND ist in dem Fall richtig.
Aber David wertet UND + ODER in ein und der selben Regel halt nicht etwa so aus:
"Identifizierung = Rundsendung" UND ( "Absender != abc@dom.tld" ODER " Absender != yxz@dom.tld" )
sondern so:("Identifizierung = Rundsendung" UND "Absender != abc@dom.tld") ODER " Absender != yxz@dom.tld" )
Darauf muss man halt achten und sich anderweitig überlegen was man tun möchte.
Konkret bedeutet das das man nicht sagen kann verschiebe alle Rundsendungen welche >nicht< von einer bestimmten Absenderliste kommen in ein anderes Archiv, weil es keine Möglichkeit gibt eine ganze Liste von Absendern anzugeben.
Man kann aber sehr wohl sagen schiebe alle Nachrichten welche als Rundsendung identifiziert wurden und von einem bestimmten Absender (das kann auch eine ganze domäne sein) stammen in ein anderes Archiv. Und man kann diese Regel beliebig oft mit jeweils einer weiteren Adresse anlegen.
Anders ausgedrückt, geht damit nur Whitelisting, aber kein Blacklisting. -
Soweit mir bekannt geht Bedingungen verknüpfen grundsätzlich nur mit UND oder ODER, beide Verknüpfungsvarianten zusammen in einer Regel gehen nicht.
In dem Beispiel muss man also für jeden Rundsendungsabsender eine eigene Regel bauen, wenn man in einer Regel mehr als nur die Absenderadresse zur Entscheidung ob etwas zu tun ist heranziehen will.
