Zuerst wird die Email an den Server zum Versenden geschickt und der versendet die dann. Erst danach sendet der IMAP Client die Email an den Server zur Ablage im "gesendet" Postfach (kann man seit El Capitan und seiner Verzögerungsleistung an schlechten Leitungen gut beobachten, Emails bleiben recht lange im Ausgangskorb liegen bis sie an den Server übertragen werden und man sieht auch gut den doppelten Traffic, wenn der Server richtig konfiguriert ist, übler wenn der Server zum Beispiel so konfiguriert ist, dass nur einmal übertragen wird, dann verschwinden Emails noch öfter, weil der Datenaustausch noch schlechter funktioniert -> der Client sagt, leg die Email mal rüber und der Server sagt hab ich schon weggeschickt und keine Kopie behalten ...).

Wenn dabei ein Fehler passiert, die Datei einen Übertragungsfehler hat, ein Sonderzeichen den Transport humpeln lässt, eine De/Kodierung fehl läuft, der Server falsch konfiguriert ist, das ServerOS mit dem ClientOS nicht harmoniert und noch tausend andere Möglichkeiten, dann killt der entsprechende Teilprozess und es wird weder eine Fehlermeldung an den Client geworfen, noch der Prozess nochmal gestartet. Dem Client ist "habe ich gesendet" genug und die Ausgangskopie ist gelöscht, der Server hatte einen Fehler und nur eine Meldung an das eigene Log, aber nicht an den Client gesendet. Das ist ein Architekturfehler, den es seit Aufkommen von IMAP gibt und den niemand bisher gefixt hat - weil auch die Idee fehlt wie.

Bei belasteten Netzleitungen oder sowieso geringer Bandbreite tritt das öfter auf und wenn kein QoS implementiert ist, auch mal bei stark belastetem LAN.

Eine echte Gegenwehr gegen den Fehler gibt es nicht. Also, nochmals, wenn Emails wichtig sind, dann immer in cc:/bcc: an einen selber schicken, denn beim Senden sind die Protokolle sauber. Für die gewerbliche Nutzung bietet sich eine Email Lösung an, die in das CMS/QS System des Unternehmens integriert ist und die Archivierung der Mails nicht den Mail Services überlässt.