Beiträge von Ritana

    Hier mal das was die KI dazu sagt......

    Der Ausnahmecode 0xc0000005 steht für eine Access Violation, also einen unzulässigen Speicherzugriff des Prozesses. Dass als fehlerhaftes Modul ntdll.dll angegeben wird, bedeutet nicht zwangsläufig, dass die Windows-DLL selbst die Ursache des Problems ist. ntdll.dll ist eine zentrale Windows-Systemkomponente und kann lediglich die Stelle sein, an der der Absturz bzw. die Exception von Windows registriert wurde.

    Besonders auffällig ist der installierte Patchstand von SQL Server 2017.

    Bei Build 14.0.1000.169 handelt es sich um den ursprünglichen RTM-Stand von SQL Server 2017 aus dem Jahr 2017. Das System läuft somit auf dem ursprünglichen Basisstand der SQL-Server-Version und verfügt nicht über die zahlreichen später veröffentlichten Cumulative Updates und Fehlerkorrekturen.

    Auffällig und aus technischer Sicht deutlich kritischer ist jedoch, dass SQL Server noch mit dem ursprünglichen RTM-Build 14.0.1000.169 betrieben wird. Vor einer tiefergehenden Analyse von ntdll.dll sollte deshalb zunächst der SQL Server auf einen aktuellen Patchstand gebracht bzw. zumindest geprüft werden, ob der Absturz bereits durch ein späteres SQL-Server-Update behoben wurde.

    Nimm doch einfach mal einen SQL 2019 oder 2022

    Leider erleben wir aktuell eher die umgekehrte Situation: Viele David Kunden kommen bereits mit dem Wunsch nach einer Microsoft-Lösung zu uns, weil sie davon ausgehen, dass dort grundsätzlich alles moderner oder besser ist.

    Unsere Aufgabe besteht dann darin, sachlich zu erklären, warum ein Wechsel zu Microsoft 365 beziehungsweise Exchange nicht automatisch die bessere Lösung darstellt und weshalb es – abhängig von den tatsächlichen Anforderungen des Unternehmens – sinnvoller sein kann, bei David zu bleiben.

    Diese Argumentation wird allerdings zunehmend schwieriger, da Microsoft mit der engen Verzahnung von Outlook, Teams, Microsoft 365 und weiteren Cloud-Diensten ein sehr umfassendes Gesamtpaket anbietet. Umso wichtiger ist es, die konkreten Vorteile von David herauszuarbeiten.

    Ich bin und bleibe David Fan (ich hasse Outlook und das Microsoft Portal)

    Hier eine wichtige Ankündigung von Tobit.......

    TeamDavid inklusive SideKick Server

    Mit dem nächsten Rollout am 1. September kommt jede TeamDavid-Installation mit einem eigenen SideKick Server – DSGVO-konform, europäisch gehostet und vollständig unter Kontrolle des Unternehmens. Die Nutzung von SideKick bleibt weiterhin optional und pro User aktivierbar, wird für TeamDavid-Kunden aber deutlich günstiger:

    • Keine Anschaffungskosten für SideKick Server: 1.490,00 € gespart
    • Geringere mtl. KI-Kosten pro User: 4,65 € zzgl. Credits statt pauschal 28,50 €
    • Kostenfreies Credit-Pack: Eine Million Credits im ersten Monat ohne Berechnung

    Damit haben TeamDavid-Kunden einen doppelten Preisvorteil: keine Anschaffungskosten und ein User-Preis von 4,65 € statt 17,65 € bei SideKick als separater Lizenz.

    Mit der kompletten Integration von SideKick in TeamDavid wird die sitecare-Lizenz moderat um durchschnittlich 3,16 % angepasst. Je nach Unternehmensgröße liegt der Preis künftig zwischen 3,83 € und 8,25 € pro User und Monat. Weitere Infos finden Sie unter https://tobit.com/teamdavid-und-sidekick.

    Also ich habe mal kurz mit meinem Kollegen (KI) gesprochen der sagt:

    Der entscheidende Fehler ist hier:

    Zitat

    550 5.7.509 Access denied, sending domain versender.invalid does not pass DMARC verification and has a DMARC policy of reject.

    Das bedeutet:

    • Die Empfängerseite (Microsoft 365 / Outlook) hat die Mail wegen fehlgeschlagener DMARC-Prüfung abgelehnt.
    • Obwohl die Mail ursprünglich bei Strato offenbar korrekt signiert war, ist die Authentifizierung unterwegs kaputtgegangen.

    Die relevanten Zeilen sind:

    • ursprünglich bei Strato:
      • spf=pass
      • dkim=pass
      • dmarc=pass

    aber später bei Microsoft:

    • spf=fail
    • dkim=fail (body hash did not verify)
    • dmarc=fail
    • compauth=fail

    Das zeigt ziemlich klar:
    Die Mail wurde nach dem DKIM-Signieren verändert oder über einen Server geleitet, der die Authentifizierung beschädigt hat.

    Wichtig ist diese Kette:

    Code
    smtp.strato.de
    → mo4-p00-ob.smtp.rzone.de
    → mail.ispmail.de
    → Microsoft 365

    Der problematische Hop ist sehr wahrscheinlich:

    Code
    mail.ispmail.de (195.185.212.45)

    Denn dort schlägt plötzlich SPF fehl und DKIM wird ungültig.

    Mögliche Ursachen

    1. Mailserver verändert den Body (sehr wahrscheinlich)

    DKIM meldet:

    Code
    dkim=fail (body hash did not verify)

    Das passiert typischerweise wenn:

    • Disclaimer angehängt werden
    • MIME-Struktur verändert wird
    • Attachments umcodiert werden
    • Zeilenumbrüche geändert werden
    • Antivirus/Spamfilter Inhalte modifizieren

    Rspamd/Postfix-Gateways sind dafür bekannte Kandidaten.


    2. Falscher SMTP-Relay

    SPF sagt:

    Code
    domain of versender.invalid does not designate 195.185.212.45 as permitted sender

    Das heißt:

    • Der empfangende Server sieht mail.ispmail.de als tatsächlichen Sender.
    • Diese IP steht aber offenbar nicht im SPF der Domain.

    Wenn mail.ispmail.de ein eigenes Relay/Gateway ist, muss dessen IP entweder:

    • im SPF stehen
      oder
    • die Mail unverändert weiterleiten und DKIM intakt lassen.

    Momentan passiert beides nicht.


    3. ARC-Kette ungültig

    Zusätzlich:

    Code
    arc=fail (47)

    ARC sollte eigentlich Authentifizierungsergebnisse „retten“ bei Weiterleitungen. Funktioniert hier aber ebenfalls nicht.

    Wahrscheinlich ist die ARC-Implementierung auf dem Zwischenserver fehlerhaft oder unvollständig.

    Was du prüfen solltest

    Wenn mail.ispmail.de dein eigener Server ist

    Dann:

    A) Keine Mailmodifikation nach DKIM

    Prüfen:

    • Disclaimer deaktivieren
    • MIME-Rewriting deaktivieren
    • Antivirus/Spamfilter testen
    • Rspamd-Milter prüfen

    Insbesondere:

    • mime modification
    • add footer
    • force reencode

    B) SPF erweitern

    Die IP:

    Code
    195.185.212.45

    muss ggf. in den SPF der Domain aufgenommen werden.

    Beispiel:

    Code
    v=spf1 ip4:195.185.212.45 include:_spf.strato.com -all

    (abhängig vom tatsächlichen Setup)


    C) DKIM nach dem letzten verändernden Hop signieren

    Falls mail.ispmail.de Inhalte verändert, muss:

    • dort neu DKIM-signiert werden
    • mit d=versender.invalid

    Wenn das nur ein Weiterleitungsserver ist

    Dann solltest du:

    • SRS (Sender Rewriting Scheme) aktivieren
    • ARC korrekt konfigurieren
    • möglichst keine Inhaltsänderungen durchführen

    Warum es früher evtl. funktioniert hat

    Microsoft 365 ist seit 2024/2025 deutlich strenger geworden bei:

    • DMARC reject
    • SPF alignment
    • ARC validation
    • CompAuth

    Besonders bei:

    • Weiterleitungen
    • Mailinglisten
    • Relayservern
    • selbst betriebenen Gateways

    Kurzdiagnose

    Die Mail war beim Versand korrekt authentifiziert, wurde aber auf mail.ispmail.de so verändert oder weitergeleitet, dass:

    • DKIM ungültig wurde
    • SPF nicht mehr passte
    • dadurch DMARC scheiterte
    • Microsoft die Mail wegen p=reject endgültig abgelehnt hat

    Der wahrscheinlichste Fix:

    • keine Veränderung der Mail auf mail.ispmail.de
      oder
    • dort korrekt neu DKIM-signieren + SPF sauber konfigurieren.

    Nein, hatte ich noch nicht. Kann ja aber eigentlich nur an den Rechten liegen. Hast du mal explizit die Rechte auf eine einzelne Nachricht überprüft?

    Ich hatte diese Woche etwas Ähnliches: Ich habe per IMAP beim Administrator Nachrichten importiert und diese anschließend im David in den User-Ordner verschoben. Obwohl der User die entsprechenden Rechte hat und die Vererbung aktiviert ist, konnte er die Nachrichten nicht sehen.
    Ich musste die Rechte einmal komplett entfernen und anschließend – inklusive Vererbung – auf den Ordner neu setzen.

    Bei wem das gar nicht funktioniert sollte also eher den persönlichen SPAM Ordner prüfen, ob es möglich ist Nachrichten dort hin zu schieben, nicht den System SPAM Ordner.

    Habe ich bereits getestet und keine Probleme festgestellt.

    Dann bin ich mal gespannt, ob es morgen auch noch funktioniert.
    Wie gesagt, als ich es mit Tobit klären wollte, da klappte es mal, und dann wieder nicht.

    ich kann ich dir sagen wie lange es funktioniert hat, war unterwegs und hatte den PC gesperrt, jetzt komme ich gerade zurück und jetzt geht es nicht mehr.

    Ok wie bescheuert ist das denn jetzt, ich nutze "Vorschau neben den Nachrichten" bei drei 31" Monitoren ist das ganz praktisch.

    Jetzt habe ich mal "Vorschau unter den Nachrichten" eingestellt und die Spam melden funktion genutzt und siehe da es hat funktioniert, dann habe ich wieder zurückgestellt "Vorschau neben den Nachrichten" und jetzt geht es da auch wieder.

    Hallo,

    Wenn ich eine Nachricht manuell in den Spam-Ordner verschiebe, funktioniert alles wie erwartet: Die Nachricht verschwindet aus dem Posteingang und liegt anschließend im Spam-Ordner.

    Wenn ich jedoch die Funktion „Als Spam melden“ verwende, passiert Folgendes: Es erscheint zunächst die Frage, ob die Nachricht in den Spam-Ordner verschoben werden soll. Bestätigt man dies mit „Ja“, verschwindet die Nachricht zwar aus dem Posteingang, taucht aber nicht im Spam-Ordner auf.

    Wechselt man anschließend in einen anderen Ordner und danach wieder zurück in den Posteingang, ist die Nachricht wieder dort vorhanden.