Wenn gesendete E-Mails nicht im Ordner „Gesendet“ auftauchen, ist das selten ein reines Anzeigeproblem. In der Praxis liegen die Nachrichten oft in einem anderen Ordner, in einer anderen Mailbox oder werden von einem Client lokal gespeichert, ohne dass der Server davon erfährt. Besonders häufig tritt das in Umgebungen auf, in denen Outlook parallel mit Outlook im Web, mobilen Apps oder einem zweiten Desktop-Client genutzt wird. Dazu kommen Unterschiede zwischen Exchange-Postfächern und IMAP-Konten: Während Exchange den Zielordner für „Gesendet“ typischerweise serverseitig verwaltet, hängt der Ablageort bei IMAP stark davon ab, ob der Client die Nachricht nach dem SMTP-/Submission-Versand in einen IMAP-Ordner kopiert oder ob der Mailserver des Providers selbst eine Kopie in „Sent“ erzeugt (provider- und clientabhängig). Für Anwender und Administratoren entsteht dadurch ein scheinbar widersprüchliches Bild: Eine Nachricht wurde nachweislich gesendet, ist aber im erwarteten Ordner nicht auffindbar oder erscheint nur in einem bestimmten Client. Entscheidend ist, die Verantwortung korrekt zuzuordnen – zwischen Client-Optionen, Protokollverhalten und serverseitigen Regeln – um Fehlkonfigurationen nachvollziehbar zu beheben und künftige Abweichungen zu vermeiden.

Inhalt
- Ablagelogik verstehen: Unterschiede zwischen Exchange (MAPI/HTTP), IMAP und SMTP-Only-Versand
- Outlook- und Client-Einstellungen prüfen: „Kopie im Ordner Gesendete Elemente speichern“, alternative Ordner und Kontomischbetrieb
- Serverseitige Ursachen und typische Fehlkonfigurationen: Exchange-Postfach, IMAP-Ordnerzuordnung, Regeln, Shared Mailboxes und parallele Webmail-Nutzung
- Exchange: serverseitige „Sent Items“-Logik und bekannte Abweichungen
- IMAP: Ordnerzuordnung („Sent“-Folder) und serverseitige Ordnerstrukturen
- Postfachregeln, Transportregeln und Journaling: wenn „Gesendet“ umgeleitet wird
- Parallele Webmail-Nutzung und mehrere Clients: konkurrierende Standards und doppelte Kopien
Ablagelogik verstehen: Unterschiede zwischen Exchange (MAPI/HTTP), IMAP und SMTP-Only-Versand
Ob eine gesendete Nachricht im erwarteten Ordner „Gesendet“ landet, ist weniger eine einzelne Outlook-Einstellung als das Ergebnis einer Protokoll- und Rollenverteilung: Wer überträgt die Nachricht, wer führt den eigentlichen „Send“-Vorgang aus, und wer entscheidet anschließend über die Ablage? Exchange (über MAPI/HTTP; EWS spielt weiterhin eine Rolle für Legacy-Integrationen und einige Drittanbieter; „Outlook REST“ ist abgekündigt), IMAP sowie reiner SMTP-Versand bilden dabei drei grundsätzlich unterschiedliche Modelle. Fehlerbilder entstehen häufig dort, wo Clients und Server gleichzeitig Ablageentscheidungen treffen oder unterschiedliche Standardordner verwenden.
Exchange: Senden und Ablage als Postfach-Operation (MAPI/HTTP)
Bei Exchange-Postfächern ist das Senden typischerweise eine Postfach-Operation: Outlook übergibt die Nachricht an Exchange, und Exchange erzeugt danach die Kopie im Ordner „Gesendete Elemente“. Diese Kopie gilt als „Quelle der Wahrheit“, weil sie im Postfach liegt und damit für Outlook Desktop, Outlook im Web und Mobil-Clients identisch sichtbar wird. Outlook kann zwar lokal zwischenspeichern (Cached Exchange Mode), die Ablageentscheidung kommt aber aus dem Postfach.
Abweichungen entstehen vor allem bei Stellvertretungen und „Send As/Send on behalf“: Dann entscheidet nicht nur die Client-Option, sondern auch die Exchange-Logik, ob eine Kopie in das Postfach des Sendenden, des Vertretenen oder in beide Postfächer abgelegt wird. In hybriden oder streng geregelten Umgebungen wird dieses Verhalten oft per Exchange- oder Microsoft-365-Einstellungen festgelegt und kann dadurch „gegen“ lokale Erwartungen arbeiten.
IMAP: Ablage ist meist ein Client-Thema, nicht automatisch Teil des Protokolls
IMAP definiert primär den Zugriff auf serverseitige Ordner und Nachrichten, nicht den Sendevorgang selbst. Gesendet wird bei klassischen IMAP-Konten meist per SMTP (Submission), und die Kopie im Ordner „Gesendet“ entsteht häufig, weil ein Client sie nach erfolgreichem Versand zusätzlich speichert (oft per IMAP APPEND). Damit hängt die korrekte Ablage direkt davon ab, welchen Ordner der jeweilige Client als „Sent“ interpretiert und ob er eine Kopie überhaupt auf dem Server ablegt. Je nach Provider kann zusätzlich (oder alternativ) der Server selbst eine Kopie erzeugen – das ist aber kein einheitliches IMAP-Standardverhalten.
Problematisch wird es bei paralleler Nutzung mehrerer Clients (Outlook Desktop, Smartphone-App, Webmail des Providers): Jeder Client kann einen anderen „Sent“-Ordner verwenden oder die Ablage lokal statt serverseitig durchführen. Außerdem existieren je nach Provider unterschiedliche Ordnernamen und IMAP-Spezialordner (z. B. „Sent“, „Sent Items“, „Gesendete Elemente“, „INBOX.Sent“). Ohne konsistente Zuordnung sieht es dann so aus, als „verschwänden“ gesendete E-Mails, obwohl sie in einem anderen Ordner liegen oder nur lokal gespeichert wurden.
SMTP-Only (ohne IMAP/Exchange-Ablage): Gesendet ist lokal oder nicht vorhanden
Beim reinen SMTP-Versand ohne IMAP- oder Exchange-Postfachkontext existiert kein serverseitiger Ort, an dem „Gesendet“ zuverlässig entstehen könnte. Typische Beispiele sind Geräte und Anwendungen (Scanner, ERP, Monitoring), die per SMTP versenden, oder Konfigurationen, bei denen der Versand über SMTP erfolgt, aber keine passende serverseitige Mailbox eingebunden ist. Eine Kopie kann dann nur erzeugt werden, wenn die sendende Anwendung sie zusätzlich speichert (was viele nicht tun) oder wenn eine serverseitige Kopie über zusätzliche Mechanismen erzeugt wird (z. B. BCC an ein Archivpostfach oder ein Gateway-Archiv). Das ist funktional jedoch nicht dasselbe wie ein klassischer „Gesendet“-Ordner im Benutzerpostfach.
Auch innerhalb von Outlook kann ein SMTP-geprägtes Verhalten sichtbar werden, wenn ein Konto zwar E-Mails senden kann, aber die Ablage lokal in einer Datendatei erfolgt (z. B. POP oder ein Profil mit lokaler Standarddatendatei). In solchen Fällen ist „Gesendet“ nicht Teil des Serverpostfachs und wird folglich weder in Webmail noch auf anderen Clients angezeigt. Das ist kein Synchronisationsfehler, sondern eine Folge der Kontokonfiguration.
| Technikpfad | Wo entsteht „Gesendet“? | Typische Abweichungsursachen |
|---|---|---|
| Exchange (MAPI/HTTP) | Serverseitig im Postfach („Gesendete Elemente“) | Stellvertretung („Send As/On behalf“), serverseitige Kopierlogik, Sonderpostfächer/Shared Mailboxes |
| IMAP + SMTP | Meist clientseitig erzeugte Kopie, idealerweise per IMAP im Serverordner „Sent“ (provider-/clientabhängig) | Unterschiedliche Sent-Ordnernamen, fehlende Spezialordner-Zuordnung, einzelne Clients speichern lokal oder in abweichende IMAP-Mailboxen |
| SMTP-Only | Gar nicht oder ausschließlich lokal/in der sendenden Anwendung | Kein Postfachkontext, keine App-Funktion für Kopien, serverseitige Kopien nur als Workaround (z. B. BCC/Archiv) |
Praktische Einordnung typischer Symptome nach Protokoll
Eine schnelle Diagnose gelingt, wenn das Symptom mit der zugrunde liegenden Ablagelogik abgeglichen wird. Bei Exchange ist ein leerer Ordner „Gesendet“ trotz erfolgreichem Versand oft ein Hinweis auf eine andere Zielmailbox (z. B. Shared Mailbox oder Stellvertretung) oder auf eine Ansicht/Filterung, selten auf „fehlendes Speichern“. Bei IMAP dagegen ist „nicht in Gesendet“ häufig schlicht „in einem anderen Ordner gespeichert“ oder „nur lokal gespeichert“, weil ein zweiter Client den Versand ausgelöst hat oder der Sent-Ordner in einem Client falsch zugeordnet wurde. Beim SMTP-Only-Versand ist das Fehlen einer gesendeten Kopie grundsätzlich erwartbar, sofern keine explizite Kopierfunktion existiert.
- Exchange-Indizien: Versand aus einer freigegebenen Mailbox oder als Stellvertreter; die Kopie liegt oft in „Gesendete Elemente“ der sendenden oder der vertretenen Mailbox, abhängig von Berechtigungsmodus und serverseitiger Kopierlogik.
- IMAP-Indizien: Gesendete Nachrichten erscheinen in „Sent“ statt „Gesendet“ (oder umgekehrt); die Abweichung folgt meist einem Client, der den „Sent“-Spezialordner anders zuordnet oder eine lokale Datendatei verwendet.
- SMTP-Only-Indizien: Versand ist nachweisbar (z. B. im Message-Trace eines Mailgateways oder beim Provider), aber es existiert keine Mailbox, in der eine Kopie entstehen könnte; ohne zusätzliche Funktion bleibt „Gesendet“ leer.
Die zentrale Konsequenz aus diesen Unterschieden: Der Ordner „Gesendet“ ist kein universelles Feature des E-Mail-Transports, sondern ein Artefakt aus Postfachtyp und Client-Verhalten. Erst wenn klar ist, ob die Ablage serverseitig (Exchange) oder clientseitig (IMAP/SMTP) erfolgt, lassen sich Outlook-Optionen und serverseitige Einstellungen widerspruchsfrei prüfen, ohne falsche Ursachen zu verfolgen.
Outlook- und Client-Einstellungen prüfen: „Kopie im Ordner Gesendete Elemente speichern“, alternative Ordner und Kontomischbetrieb
Wenn gesendete Nachrichten nicht im erwarteten Ordner „Gesendet“ auftauchen, liegt die Ursache häufig nicht auf dem Server, sondern in der Client-Logik: Outlook kann das Speichern gesendeter Elemente je nach Kontotyp (Exchange/Microsoft 365, IMAP, POP), Sendemethode (Senden als/ im Auftrag von), genutztem Endgerät sowie Add-ins unterschiedlich behandeln. Deshalb beginnt die Einordnung mit den lokalen Optionen und der Frage, welcher Client den Versand tatsächlich ausgeführt hat.
Outlook-Optionen: „Kopie im Ordner ‚Gesendete Elemente‘ speichern“ und Sonderfälle
In Outlook existieren mehrere Stellschrauben, die den Ablageort beeinflussen. Zentral ist die globale Einstellung zum Speichern gesendeter Elemente, die in einigen Umgebungen absichtlich deaktiviert wird (z. B. bei gemeinsam genutzten Postfächern oder bestimmten Archiv-/Compliance-Konzepten) und dann als „fehlender Ordnerinhalt“ missverstanden wird. Zusätzlich greifen Ausnahmen, sobald eine Nachricht „über“ ein anderes Postfach versendet wird: Bei Exchange/Microsoft 365 entscheidet häufig die Kombination aus Outlook-Verhalten, Postfachberechtigungen und serverseitiger Kopierlogik, ob das Element im Ordner des sendenden Benutzers oder im Ordner des verwendeten Postfachs landet.
Auch im Cached Exchange Mode und bei aktivierter gemeinsamer Nutzung kann Outlook lokal eine andere Ansicht zeigen als Outlook im Web, wenn Synchronisationsfilter, Offlinezustände oder lokale Indizes im Spiel sind. Das erklärt Fälle, in denen Nachrichten serverseitig korrekt im Ordner „Gesendete Elemente“ liegen, aber im Desktop-Client fehlen oder erst nach einiger Zeit erscheinen.
- Globale Outlook-Option: In Outlook unter
Datei > Optionen > E-Maildie Einstellung „Kopie von Nachrichten im Ordner ‚Gesendete Elemente‘ speichern“ prüfen (Bezeichnung kann je nach Build leicht variieren). Ist sie deaktiviert, wird in diesem Outlook-Client keine Kopie in „Gesendete Elemente“ gespeichert (bei Exchange kann die serverseitige Kopie dennoch vorhanden sein). - „Senden als“ / „Senden im Auftrag von“: Bei Versand über ein freigegebenes Postfach oder als Stellvertreter prüfen, ob die Kopie im persönlichen „Gesendet“ oder im „Gesendet“ des verwendeten Postfachs landet. In Exchange/Microsoft 365 korrespondieren solche Effekte häufig mit den Parametern
MessageCopyForSentAsEnabledundMessageCopyForSendOnBehalfEnabled(serverseitig an der Shared Mailbox), die steuern, ob zusätzlich eine Kopie im Ordner „Gesendete Elemente“ der Shared Mailbox abgelegt wird. - Regeln und Add-ins: Clientseitige Regeln („Nach dem Senden“) und COM-/VSTO-Add-ins können gesendete Elemente verschieben oder löschen. Zur Eingrenzung Outlook testweise im abgesicherten Modus starten:
outlook.exe /safe. - Offline-/Synchronisationsartefakte: Bei Exchange-Postfächern die Konsistenz zwischen Outlook und Webansicht prüfen. Weichen Inhalte ab, ist nicht sofort „falsche Ablage“ naheliegend, sondern ggf. ein Problem mit OST-Synchronisation, Filteransichten oder einer beschädigten lokalen Such-/Ansichtsdatenbank.
IMAP in Outlook: Gesendet-Ordner-Zuordnung und serverseitige Ordnerstruktur
Bei IMAP ist der Ablageort nicht nur eine Outlook-Frage. Der Server stellt Ordner und ggf. spezielle Mailboxen bereit (Sent, Sent Items, Gesendet, etc.), und verschiedene Clients interpretieren diese „Special-Use“-Ordner unterschiedlich. Outlook kann bei manchen IMAP-Implementierungen gesendete Elemente in einen lokal erzeugten Ordner schreiben oder einen anderen IMAP-Ordner wählen als Webmail oder Mobile-Apps. Typisch ist außerdem eine abweichende Root-/Präfixstruktur (z. B. INBOX als Namespace), die dazu führt, dass ein „Gesendet“-Ordner doppelt erscheint oder in einem nicht erwarteten Zweig landet.
Besonders fehleranfällig wird die Lage, wenn mehrere Clients parallel genutzt werden und jeder Client einen eigenen „Sent“-Ordner festlegt. Dann entstehen schnell zwei oder mehr Ordner, die semantisch „Gesendet“ heißen, aber technisch unterschiedliche IMAP-Mailboxen sind. In Outlook zeigt sich das häufig als „Gesendete Elemente“ unterhalb einer Datendatei, während Webmail „Gesendet“ direkt unter dem Postfach anzeigt – oder umgekehrt.
| Symptom im Client | Wahrscheinliche Ursache in der Zuordnung |
|---|---|
| „Gesendet“ ist leer, aber Webmail zeigt gesendete Mails | Outlook speichert in einen anderen IMAP-Ordner oder in einen lokalen Ordner (nicht synchronisiert) |
| Zwei Ordner „Gesendet“/„Sent“ existieren parallel | Unterschiedliche Special-Use-Erkennung oder abweichender Namespace (z. B. INBOX-Präfix) zwischen Clients |
| Gesendete Mails erscheinen unter „Lokale Ordner“ | Versand über Konto/Datendatei, deren Standardablage lokal ist, oder falsches Standardkonto bzw. falsche Standarddatendatei in Outlook |
| Gesendete Mails landen im „Gesendet“-Ordner eines anderen Kontos | Kontomischbetrieb: Standarddatendatei/Standardkonto passt nicht zum sendenden Konto oder es wird tatsächlich über ein anderes Konto versendet als erwartet |
Alternative Ordner und Datendateien: Standardkonto, Standarddatendatei, Antwortverhalten
Outlook kann für das Speichern gesendeter Elemente die Standarddatendatei heranziehen, nicht zwingend das Konto, das als „Von“-Absender sichtbar ist. In Profilen mit mehreren Konten (z. B. Exchange plus zusätzliches IMAP/POP) führt das zu scheinbar „verschwundenen“ E-Mails: Die Nachricht wurde gesendet, aber im Gesendet-Ordner einer anderen Datendatei abgelegt. Das passiert insbesondere, wenn das Standardkonto nicht dem primär genutzten Postfach entspricht oder wenn Antworten aus einem geöffneten freigegebenen Postfach heraus erstellt werden.
Zur Eingrenzung ist entscheidend, die konkrete Versandspur zu ermitteln: Welches Konto hat den SMTP-/Submission-Versand ausgeführt, welche Datendatei ist als Standard gesetzt, und welche Outlook-Funktion (Antworten/Weiterleiten, „Von“-Feld, freigegebene Ordner) war beteiligt. Ohne diese Zuordnung bleiben Korrekturversuche oft zufällig und verschieben nur das Problem zwischen Ordnern.
- Standardkonto und Standarddatendatei: In
Datei > Kontoeinstellungen > Kontoeinstellungenprüfen, welches Konto Standard ist und welche Datendatei als Standard markiert ist; Ablagefehler treten häufig auf, wenn Versand und Standarddatendatei auseinanderfallen. - „Von“-Identität vs. sendendes Konto: Bei Nutzung mehrerer Identitäten sicherstellen, dass nicht nur das sichtbare „Von“ korrekt ist, sondern auch das tatsächlich sendende Konto. Bei manchen Konstellationen (insbesondere mit IMAP/SMTP und zusätzlichen Exchange-Postfächern) kann Outlook beim Antworten ein anderes Konto wählen als erwartet.
- Freigegebene Postfächer im Profil: Wird ein Shared Mailbox-Ordner zusätzlich geöffnet, können Antworten aus diesem Kontext in „Gesendet“ des persönlichen Postfachs landen (oder umgekehrt), abhängig von Berechtigungen und serverseitiger Kopierlogik. Für die Einordnung zählen daher sowohl Outlook-Verhalten als auch Exchange-Einstellungen.
- Client-Mix (Desktop, OWA, Mobile): Wenn einzelne Geräte korrekt ablegen und andere nicht, spricht das gegen einen reinen Serverfehler. Dann lohnt der Abgleich: Versand über Webmail → Ablageort in Webmail; Versand über Desktop → Ablageort in Desktop; Versand über Mobile → Ablageort in Mobile und Webmail. Abweichungen deuten auf clientseitige Ordnerzuordnung oder auf unterschiedliche Versandpfade (z. B. Exchange vs. IMAP/SMTP).
Wenn gesendete Nachrichten nicht im erwarteten Ordner erscheinen, liegt die Ursache häufig nicht im Client, sondern in der serverseitigen Ablage-Logik oder in einer inkonsistenten Ordnerzuordnung. Je nach Postfachtyp (Exchange Online/On-Premises, Hybrid, IMAP) entscheidet entweder der Server oder der Client, ob und wo eine Kopie abgelegt wird. Parallel genutzte Zugriffspfade – Outlook Desktop, Outlook im Web, mobile Apps, Drittanbieter-Clients – verschärfen Abweichungen, weil sie teils unterschiedliche Standards für „Sent Items“ verwenden oder serverseitige Vorgaben anders interpretieren.
Exchange: serverseitige „Sent Items“-Logik und bekannte Abweichungen
In Exchange-Umgebungen wird die Ablage gesendeter Elemente grundsätzlich durch den Server und die Postfachkonfiguration geprägt. Outlook im Web speichert standardmäßig im Ordner „Gesendete Elemente“ des Postfachs, unabhängig von lokalen Outlook-Einstellungen. Outlook Desktop folgt bei Exchange-Konten in der Regel derselben Logik, kann jedoch durch Sonderfälle abweichen: Versand „als“ oder „im Auftrag von“ (Send As/Send on behalf), Versand aus freigegebenen Postfächern, Versand über zusätzliche Postfachverbindungen oder Delegierten-Szenarien.
Besonders häufig entsteht Verwirrung bei Shared Mailboxes: Eine Nachricht wird zwar aus dem freigegebenen Postfach versendet, die Kopie landet aber im Ordner „Gesendet“ des sendenden Benutzerpostfachs. Dieses Verhalten kann je nach Client und Konstellation variieren; Exchange stellt dafür explizite Optionen bereit, die serverseitig wirken und damit auch Outlook im Web und mobile Clients beeinflussen.
- Shared Mailbox – Kopie zusätzlich in „Gesendet“ der Shared Mailbox ablegen (Exchange Online und Exchange Server):
Set-Mailbox <SharedMailbox> -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true - Prüfen, ob die Optionen gesetzt sind:
Get-Mailbox <SharedMailbox> | Select MessageCopyForSentAsEnabled,MessageCopyForSendOnBehalfEnabled - Clientseitige Erwartung vs. Serverrealität: Bei aktiviertem Caching und mehreren Outlook-Profilen kann der lokale Ordnerbestand kurzfristig vom Serverzustand abweichen; maßgeblich bleibt jedoch die serverseitige Ablage im Postfach.
| Konstellation | Typisches Symptom | Serverseitiger Hebel |
|---|---|---|
| Versand „Send As“ aus Shared Mailbox | Kopie landet im persönlichen „Gesendet“ statt im „Gesendet“ der Shared Mailbox | -MessageCopyForSentAsEnabled an der Shared Mailbox (zusätzliche Kopie im Shared-Postfach) |
| Versand „Send on behalf“ | Uneinheitliche Ablage je nach Client | -MessageCopyForSendOnBehalfEnabled an der Shared Mailbox (zusätzliche Kopie im Shared-Postfach) |
| Hybrid/mehrere Identitäten (primäre SMTP vs. Alias) | Kopie erscheint im „falschen“ Postfach oder Ordner wird doppelt geführt | Überprüfung von Postfachzuordnung, Delegation, Automapping und Sende-Berechtigungen |
IMAP: Ordnerzuordnung („Sent“-Folder) und serverseitige Ordnerstrukturen
Bei IMAP existiert keine universelle, serverseitig erzwungene Definition, welcher Ordner „Gesendet“ ist. Viele Server stellen einen Standardordner bereit, aber Clients müssen ihn korrekt zuordnen. Typische Fehlerbilder: Der Client legt einen neuen Ordner „Sent“ oder „Gesendet“ an, während der Server bereits „Sent Items“ oder einen lokalisierten Ordner führt; alternativ wird in einem Unterordner unterhalb eines IMAP-Namespaces gespeichert (z. B. unter „INBOX.“), der in anderen Clients nicht angezeigt wird.
Zusätzlich erschweren Sonderfälle die Lage: Manche Server kennzeichnen Spezialordner serverseitig (IMAP SPECIAL-USE, RFC 6154). Wenn ein Client diese Kennzeichnung nicht auswertet oder parallel ein anderer Client einen abweichenden Ordner als „Sent“ festlegt, entstehen doppelte oder „verschwindende“ Sendeordner, obwohl die Nachrichten technisch korrekt per IMAP abgelegt werden.
- Namespace-/Pfadfehler: Server verwendet Präfixe wie
INBOX.oderINBOX/; ein Client speichert inSent, ein anderer inINBOX.SentoderINBOX/Sent. - Doppelte Ordner durch Lokalisierung: Webmail nutzt
Gesendet, ein Desktop-Client erstelltSent; beide Ordner existieren parallel und werden je nach Clientansicht unterschiedlich angezeigt. - Fehlende SPECIAL-USE-Unterstützung: Der Server markiert den Ordner als
\Sent, der Client ignoriert das und verwendet eine eigene Zuordnung, wodurch Ablage und Anzeige auseinanderlaufen.
Postfachregeln, Transportregeln und Journaling: wenn „Gesendet“ umgeleitet wird
Regeln können den Eindruck erzeugen, eine gesendete Nachricht sei nicht abgelegt worden, obwohl sie lediglich verschoben oder kopiert wurde. Clientseitige Outlook-Regeln betreffen primär eingehende Nachrichten; „Nach dem Senden“-Regeln (clientseitig) sowie Add-ins können jedoch gesendete Elemente verschieben oder löschen. Serverseitige Inbox-Regeln wirken ebenfalls auf eingehende Nachrichten und nicht auf das serverseitige Speichern von „Gesendete Elemente“ – sie können aber Kopien beeinflussen, wenn z. B. per Regel CC/BCC hinzugefügt wird oder wenn ein Add-in/Client nach dem Senden automatisiert verschiebt. Transportregeln (Mail Flow Rules) arbeiten auf der Nachricht im Transport und ändern den Versandinhalt oder die Adressierung, nicht aber direkt den Speicherort der im Postfach abgelegten Kopie; dennoch kann die resultierende Nachricht so aussehen, als sei „eine andere“ Mail versendet worden.
In Compliance-Szenarien (Journaling, eDiscovery-Hold, Litigation Hold/Retentions) wird in der Regel nichts „aus dem Gesendet-Ordner entfernt“, jedoch kann die Nutzerwahrnehmung durch nachgelagerte Prozesse verfälscht werden: Drittanbieter-Archivierung verschiebt Elemente, Add-ins erzeugen zusätzliche Kopien, oder ein Serverprozess schreibt eine Kopie in ein anderes Postfach (z. B. Funktionspostfach). Für die Eingrenzung ist entscheidend, ob die Nachricht im Postfach nie angelegt wurde (Ablage-/Clientpfad) oder ob sie nachträglich verschoben/ausgeblendet wurde (Regeln, Archivierung, Clientansicht).
Parallele Webmail-Nutzung und mehrere Clients: konkurrierende Standards und doppelte Kopien
Werden Outlook Desktop, Outlook im Web und mindestens ein weiterer IMAP- oder Mobile-Client parallel genutzt, treffen mehrere Ablagelogiken aufeinander. Webmail legt üblicherweise serverseitig in „Gesendete Elemente“ ab. Ein IMAP-Client kann zusätzlich eine eigene Kopie in einen anderen Ordner hochladen, wenn er den Sent-Ordner anders zuordnet oder eine Option wie „Kopie im Ordner ‚Sent‘ speichern“ implementiert, ohne den serverseitigen Standard zu erkennen. Das Ergebnis sind doppelte Kopien oder Kopien in unterschiedlichen Ordnern, die je nach Client „verschwinden“.
In Exchange-Postfächern kommt hinzu, dass manche Drittanbieter-Clients bei IMAP/SMTP-Anbindung an ein Exchange-Postfach die Exchange-Ablage nicht nutzen, sondern selbst per IMAP in einen Ordner schreiben. Dabei sind Ordnername, Namespace und SPECIAL-USE-Zuordnung ausschlaggebend. Bei gemischten Setups sollte deshalb pro Postfach möglichst ein konsistenter Zugriffstyp genutzt werden; wenn IMAP erforderlich ist, müssen die IMAP-Spezialordner serverseitig eindeutig bereitgestellt und clientseitig konsistent zugeordnet werden.
- Symptom „nur im Web sichtbar“: Webmail zeigt die Kopie im serverseitigen Ordner, der Desktop-Client synchronisiert jedoch einen anderen Ordnerzweig (z. B. durch falschen IMAP-Root oder fehlende Ordnerabonnements).
- Symptom „nur im Desktop sichtbar“: Ein Client speichert lokal oder lädt in einen nicht als Spezialordner erkannten IMAP-Ordner hoch; Webmail blendet diesen Ordner aus oder sortiert ihn getrennt.
- Symptom „doppelt gesendet/zweifach im Gesendet“: Ein Client legt eine Kopie ab und ein weiterer Client (oder der Server) erzeugt zusätzlich eine zweite Kopie; häufig bei parallel aktivierten „Sent“-Kopierfunktionen und uneinheitlicher Ordnerzuordnung.
Meroth IT-Service ist Ihr lokaler IT-Dienstleister in Frankfurt am Main für kleine Unternehmen, Selbstständige und Privatkunden
Kostenfreie Ersteinschätzung Ihres Anliegens?
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten
