Hallo,

der Mail Ordner in meiner User Library ist über 150 GB groß.
Nun möchte ich gerne etwas Speicherplatz gewinnen, ohne alte Mails oder alte Anhänge unwiederbringlich zu löschen.

Wenn ich im Mail Ordner in der Library navigiere, hat es den Anschein, als gäbe es zu jeder Mail, die einen Anhang enthält, einen Ordner, in dem der Anhang abgelegt ist.
Das erscheint mir aber doppeltgemoppelt. Denn die .emlx Dateien beinhalten der Dateigröße nach zu urteilen, die Anhänge.
Insofern müsste es doch ohne Datenverlust möglich sein, die 'ausgepackten' und separat gespeicherten Anhänge zu löschen.
Daher meine Fragen...
- Liege ich richtig, dass die Anhänge nicht nur eigens im ~/Library/Mail/... abgelegt sind, sondern in der ursprünglichen message-Datei (emlx) ohnehin enthalten sind?
- Liege ich somit richtig, dass ich alle als eigene Datei in ~/Library/Mail/... abgelegten Anhänge löschen kann, weil ich die Anhänge jederzeit aus den .emlx-Dateien wieder extrahieren könnte?
- Wie kann ich schadlos, ohne das Ablagesystem der Mail App zu korrumpieren, die vielen überflüssigen Anhänge löschen?

Danke für Tipps
Fadenschein

Deine Frage geht von der Annahme aus, Apple würde im eigenen Betriebssystem Platz verschwenden, weil die Mail-Verwaltung die Anhänge nicht richtig handhabt und doppelt ablegt. Das halte ich für eine gewagte Theorie. Ich kann sie nicht widerlegen, denke aber dieser „Fehler“ wäre schon mal jemandem aufgefallen.

Ich meine, dass die Ordner mit dem Anhang drin immer dann angelegt werden, wenn ein Anhang direkt in der Mail geöffnet wird. Am besten einfach mal mit einer Testmail prüfen.

@jogoto
Schau' einfach mal rein in Deinen Mail Ordner in der Library.

@udrabo
Ja stimmt. So werden sie angelegt. Insofern müsste man sie ja eigentlich löschen können. Die Frage ist nur, wie man das am geschicktesten macht, ohne die Datenbankstruktur zu stören.

Da hast Du mich falsch verstanden oder ich mich ungenau ausgedrückt. Ich kann die von Dir beschriebene Struktur sehr wohl nachvollziehen. Weniger nachvollziehen kann ich die Überlegung, dass es sich dabei um einen „Fehler“, um unnötige Dateien handelt. Warum sollte das so sein?
Ich kann es wie gesagt nicht widerlegen, weil ich den Grund für diese Struktur nicht kenne. Das wiederum ist für mich aber ein Grund die Finger davon zu lassen und auf Apple zu vertrauen. Außerdem empfinde ich es als mehr als umständlich diese Dateien, die sich ja in vielen verschachtelten Ordner befinden, von Hand löschen zu wollen. Fällt Dir nichts anderes zur Mailverwaltung ein? Archiv?

@jogoto
Es ist sogar noch schlimmer, als befürchtet, denn viele Anhänge sind 3-fach vorhanden:

1)
~/Library/Mail/V4/BEISPIEL-B0B5-4143-823A-D6FA525B9CC0/'Beispiel'.mbox/BEISPIEL-773A-4BF5-8C77-79D53B5F70D1/Data/2/6/1/Messages/162895.emlx

Dies ist nur ein Beispielpfad. In der Datei 162895.emlx befindet sich augenscheinlich nicht nur der E-Mail Text, sondern der gesamte Anhang.

2)
~/Library/Mail/V4/BEISPIEL-B0B5-4143-823A-D6FA525B9CC0/'Beispiel'.mbox/BEISPIEL-773A-4BF5-8C77-79D53B5F70D1/Data/2/6/1/Attachments/162895/

In diesem Ordner (Achtung - ebenfalls ein Beispielpfad) befindet sich der Anhang der vorgenannten Mail nochmals zusätzlich als separate Datei.

3)
~/Library/Containers/com.apple.mail/Data/Library/Mail Downloads

HIER befinden sich die temporär abgespeicherten Anhänge, die angelegt werden, wenn man einen Anhang aus einer Mail direkt öffnet.
Den Inhalt dieses Ordners darf man nach Aussage vieler Postings im Internet auch gefahrlos löschen. Es bleiben dann aber immer noch zwei Kopien der Anhänge enthalten, nämlich die von 1) und 2).

Fazit
Mir geht es ja auch so... Augenscheinlich handelt es sich um eine ungeheure Platzverschwendung. Es gibt keine Indizien, die darauf hindeuten, dass es das nicht ist, außer der Annahme, das Apple mutmaßlich nie soviel Platz verschwenden würde.

Emails exportieren und Accounts löschen. Accounts neu anlegen und dann Emails wieder importieren. In die Accounts verschieben.
Vorher vielleicht noch alle Emails löschen, die nichtmehr benötigt werden.
Das dauert zwar bei 150GB - aber die Accounts werden wesentlich kleiner!

Unterhalb von ~/Library/Containers/ wird sehr viel mit Aliasen gearbeitet. Bisher waren die Ordner direkt unter ~/Library/ und verweisen teilweise immer noch darauf.

Es gab hier im Forum mal eine Anleitung, wie man alle Anhänge wegsichert und aus Mail löscht. Vielleicht wäre das ja was.

@Foti
Das wäre sicher das effektivste. Leider in meinem Fall sehr mühsam, da ich mir eine schöne Postfachordnerstruktur für meine Projekte ausgedacht habe.

@jogoto
Es gibt tatsächlich Anleitungen, wie man die Anhänge sichert und dann komplett aus Mail löscht. Das wäre aber nicht mein Ziel, da ich es angenehm finde, jederzeit auf eine alte Mail samt Anhang zugreifen zu können. Mein Ziel wäre es, redundante Daten zu löschen.

Gerade habe ich es mal bei einer Mail getestet und den Anhang aus 2) gelöscht.
Ergebnis: wenn ich per Quicklook (heisst das so?) im Finder in die zugehörige emlx-Datei aus 1) schaue, sehe ich eine Vorschau der Mail aber anstatt des Anhangs sehe ich ein blaues Kästechen mit einem Fragezeichen.
Wenn ich die Mail dann aber in der Mail.app anschaue, ist der Anhang ganz normal vorhanden.
Scheint also redundant zu sein.
Aber natürlich traue ich mich trotzdem nicht, die Anhänge zu löschen, wenn meine These nicht von mehreren Seiten bestätigt wurde.

Ich vermute mal das die "doppelte" Speicherung folgenden Hintergrund hat:
1. In der Email wird der Anhang "geöffnet".
2. Im Anhang wird gearbeitet und der Anhang gespeichert
=> der Anhang in der emlx ist noch der originale, der im Ordner ein modifizierter. Ich empfehle daher, prinzipiell den Anhang erst manuell irgendwo zu speichern und dann dort zu öffnen.
Wird in der selben Mail ein Anhang öfters geöffnet und bearbeitet so wird jedesmal ein neuer Ordner erstellt.
Nun kann es aber auch sein das unser allseits bewundertes OS nur denkt das der Anhang bearbeitet wurde Das hat dann zur Folge das alle angeschauten Anhänge ein 2. mal in einem extra Ordner liegen und nie gelöscht werden.

Erstelle einen Klon deines Systems, starte von dort und unterbinde jegliche Zugriff aufs Internet. Dann lösche alle Ordner mit den Anhängen drin und schaue ob Mail dir noch alles richtig anzeigt. Wenn ja, kannst du das ein dem richtigen System auch machen. Da du ja ein regelmäßiges Backup hast hast du im Falle des Falles auch einfach den alten Zustand wieder herstellen wenn doch etwas nicht wie gewohnt funktioniert

Hm, Du könntest mal mit Onyx "Items in Mail Downloads Folder" löschen lassen. Natürlich kannst Du das auch manuell machen.

"Items in the Mail Downloads folder: This folder, situated in the Library folder of your home folder, contains a copy of files opened in the Mail application. To remove these copies, select this option."

Selbst wenn alles drei mal da liegt, auch 50 Gigabyte wären noch ganz schon viele Mail und Anhänge...

Vielleicht noch eine andere Idee, wenn der Speicherbedarf von Mail außer Kontrolle gerät: Auf einem meiner Macs hatte ich mal Probleme beim Sync mit einem IMAP-Konto. Irgendwie hat der sich beim Verschieben einer Mail verschlickt und es dann immer weiter versucht (auch nach dem Neustart des Programms), was eine gigantisch große LOG Datei zur Folge hatte, die um mehrere Gigabyte pro Tag angewachsen ist.

@MikeMuc
Ja, wenn ich keine weiteren Infos über das Netz finde, werde ich es wohl ausprobieren müssen. Bei einer einzelnen Mail hat es ja schon funktioniert. Meine Sorge ist, dass es sein könnte, dass es zunächst funktioniert, aber bspw. bei einem zukünftigen Systemupdate oder einer Migration zu Problemen kommt. Oder es zerschiesst mir die Mail Datenbank langsam im Hintergrund ohne dass ich es zunächst bemerke. Dann hilft mir mein Backup nur eingeschränkt.

@AppleNick
Ja, das ist der Ordner (siehe Punkt 3 weiter oben), den man einfach löschen darf. Der ist aber eh' nicht so groß bei mir. Nur etwa 1 GB.
Den meinte ich aber eigentlich gar nicht, sondern den Teil der der mbox in der alle Mails einzeln und alle Attachments doppelt enthalten sind.

@Arne R.
Stimmt schon. Ich habe sehr viele Mails und sehr viele Anhänge.
Das liegt einfach daran, dass ich schon seit rund 10 Jahren täglich sehr viele Mails mit großen Anhängen bekomme. Einen Fehler (außer der der doppelten Speicherung) kann ich recht gut ausschließen, da ich mir den Ordner mit den 150 GB genau angeschaut habe, und nichts Verdächtiges zu finden ist.

Mail sollte man immer so einrichten, dass man die von mir vorgeschlagene Lösung ohne Probleme realisieren kann. Bei den letzten Updates hat Mail jedesmal einen neuen V Ordner angelegt. V2, V3 und bei 10.12. V4. Dabei habe ich beobachtet, dass Mail mit dem Kopieren innerhalb des Update-Prozess die Mail-.lib "aufbläht! Erst durch durch einen "clean Install" und durch das Importieren der zuvor exportierten Mails hat sich bei mir der V-Ordner von 10GB auf 872MB verändert. Das finde ich schon eklatant!

@foti
10GB auf 872MB - das hat einen verführerischen Reiz.
Zu schade, dass ich lokale Postfächer zur Ablage angelegt habe, die recht verschachtelt sind. Und bei einem Test habe ich festgestellt, dass Mail nicht in der Lage ist, verschachtelte Postfächer zu ex- und importieren.
Man muss jeden Ordner einzeln behandeln. Da wäre ich wohl 1 Woche beschäftigt...

Irgendwann wirst Du es aber tun müssen, da mit Sicherheit irgenwann mal ein Clean-Install anstehen wird.

@Foti
Vielleicht beherrscht Mail.app bis dahin den Export von verschachtelten Postfachordnern, wenn ich Glück habe.

Ansonsten habe ich einen interessanten Test gemacht:
Ich habe mir eine E-Mail mit einem großen Anhang geschickt.
Nachdem die Mail vom Pop Server geladen wurde habe ich sie nicht in 'Mail' angeklickt oder geöffnet.

Stattdessen habe ich in der mbox Datenbank danach gesucht.
Ergebnis: den Anhang im eigens angelegten Attachment Ordner legt Mail.app an obwohl ich weder die Mail noch den Anhang geöffnet habe. Wenn ich den Anhang aus dem Ordner lösche, oder wenn ich gleich den ganzen Anhang Ordner lösche, passiert scheinbar ..... Trara..
NICHTS

Völliges Rätsel, warum Mail.app für jeden Anhang einen Ordner anlegt und den Anhang somit doppelt speichert.

In der Vergangenheit hatte ich öfters den fall, dass bei alten Mails zwar noch ein Anhang vorhanden, dieser sich aber nicht öffnen lies. Wenn Mail nun so eine Art internes Backup anlegt?

Hier ist das Phänomen beschrieben. Dass Mail.app Attachments separat ablegt, obwohl sie in der .emlx Datei enthalten sind.
Leider steht nichts zu Sinn und Zweck.

Das Prinzip des Backups ist eine Möglichkeit, aber ich kann sie mir noch nicht erklären. Denn wenn Mail in der Lage ist, die .emlx Datei zu öffnen - warum sollte es nicht in der Lage sein, den Anhang zu extrahieren?

Im Hinblick auf Foti.
Ich habe einen Test gemacht, eine meiner Mailboxen zu exportieren und zu importieren. Ergebnis: Mail.app legt nach dem Import keinen Ordner an, in dem die Attachments doppelt liegen. Trotzdem verhalten sich die Importe genauso, wie die Original E-Mals, d.h. die Anhänge lassen sich ohne Probleme anzeigen.

Hier mal zum Vergleich: Ich benutze Mail auch bereits seit 10+ Jahren und bekomme gelegentlich (nicht dauernd) auch große Anhänge. Mein Ordner hat knapp 13 GB.

Sind denn eure Emails und Anhänge nur lokal vorhanden oder auch bei einem Mail Anbieter?

dito.

Ein weiterer Test.
Ich habe ein Postfach mit 2.564 Mails exportiert.
Und dann wieder importiert.
Die Ordnergrößen sind wie folgt:
mbox Original Postfach: 8,96 GB
mbox Export Postfach: 5,14 GB
mbox Reimport Postfach: 7,03 GB

Anders als zuerst vermutet, hat Mail.app beim Reimport sogleich dafür gesorgt, dass alle Anhänge doppelt vorliegen. Einmal als Teil der .emlx Datei und einmal als separate Datei in einem eigenen Ordner.

Dann muss man wohl feststellen, die einzige Möglichkeit ist die emails als IMAP zu lagern. Ich habe alle Daten heruntergeladen und auch nur den normalen Speicher ...

Vielleicht fuer Spotlight? Wobei wenn man die Email indiziert kann man ja auch gleich den eingebetteten Anhang scannen. Sieht eher nach bescheidenem Design aus...

Hier steht noch was zu den bis zu dreifach gespeicherten Anhaengen, beantwortet obige Frage aber auch nicht.

Warum nicht ältere Jahrgänge in Eaglefiler speichern und dann in Mail löschen? So bleibt die Struktur erhalten und durchsuchbar.

Ich kann den Datenverlust durch Fehlmanipulationen förmlich riechen!

Ich würde …
… den Mac vom Internet trennen, damit keine neuen E-Mails empfangen werden
… den Ordner “~/Library/Mail/…” auf eine externe Festplatte als Backup sichern
… wüten und experimentieren, bis der Sachverhalt klar ist
… im schlimmsten Fall das Backup wieder einspielen und aufgeben

Welches OS wird denn verwendet und welches Mail mit welcher Bezeichnung des Ordners V2, V3, V4 ?
Die Mailanhänge könnten doppelt angelegt werden, da Du mit den Unterordnern arbeitest. Ein Anhang im original Ordner (die werden unter V3/V4 so benannt 2EFEC36D-8037-4B21-A307-5BA35F620E2C) und dann den Anhang noch einmal im erstellten Ordner.

Testweise kann man das Exportieren und Importieren nicht so machen wie Du es gemacht hast.
Du musst alles exportieren und dann die Mail Accounts kpl.löschen!
Dann die Mail Accounts neu erstellen und die Mails Step bei Step wieder importieren.

@Foti
10.12.2
V4
Meinen lokalen Test habe ich nur mit lokalen Postfächern gemacht.
Die haben gar keine Verbindung zu den Mailaccounts.
Da meine lokalen Postfächer auch am größten sind, ist mein Einsparbedürfnis dort am stärksten

@someone
Ich glaube, dass es so ist, wie Du sagst. Mail.app extrahiert den Anhang und legt in zusätzlich zur .emlx gesondert ab, damit ihn Spotlight durchforsten kann. Das wäre zwar sicher auch anders möglich, aber vielleicht lässt es sich so am einfachsten bewerkstelligen.

ok. Mail in 10.12.2 funktioniert nicht wirklich. Ich bin deshalb wieder auf 10.11.6 zurück. Ist leider so. Apple kümmert sich auch offensichtlich nicht mehr um Mail. Hauptsache Siri!

Oder man wechselt gleich zu einem Programm das regelmässige mit updates gepflegt wird.

Das da wäre?

Irgendwie verstehe ich das ganze Problem gleich mehrfach nicht:

• Das ganze Kopfzerbrechen wegen läppischen 150 GB? Das geht doch bei den heutigen Plattengrößen im statistischen Rauschen unter …
• Wie sollte das denn anders funktionieren? Anhänge in einer Mail sind schließlich kodiert, vergleichbar einem Zip-Archiv. Es käme doch auch niemand auf die Idee, ein empfangenes Zip-Archiv mit z.B. einem Programm nur als Archiv zu speichern und dann jedes Mal zu entpacken, wenn man das Programm nutzen will. Nein, man entpackt das Archiv einmal und startet das Programm bzw. öffnet die Datei ab da direkt, in umkodiertem Zustand. Und genauso macht Mail das auch.
• Wenn Du viele Mails mit großen Dateien 10 Jahre lang aufhebst, würde ich unterstellen, dass die Dateien wichtig sind. Dann sollten sie doch aber ohnehin an einen adäquaten Ort für direkten Zugriff gesichert werden und nicht in Mail verbleiben (also Bilder z.B. in Aperture etc.)?!? Sollten in den Mails zeitgleich auch noch andere Infos stehen, so lassen sich die nackten Mails ja aufheben, nachdem man die Anhänge über den entsprechenden Menüpunkt gelöscht hat.

150GB sind 60% der Kapazität eines standard MBP 2016. Als Rauschen würde ich das nicht bezeichnen.

Öhm – wir reden hier über ein 10-Jahres-Archiv. Welcher Mensch bei klarem Verstand würde das auf einem LAPTOP speichern?

Und falls doch , und dem Betreffenden sind 10 Jahre nicht mal eine 1-TB-SSD wert – ja dann …

Ich weiß ja nicht, mit welchen Stundensätzen Ihr so kalkuliert, aber 10 Stunden über dieses Problem Grübeln ergäbe bei mir locker den Aufpreis für eine 1-TB-SSD.

Weia

Grundsätzlich stimme ich dir zu. Noch dazu wo man sicher eh nicht permanent auf die ältesten Mails zugreifen muss. Persönlich bin ich zum Glück auch nicht in der Situation, dass mir 150GB weh tun.

btw. Frohes Neues an alle Mitleser

AirMail, Spark oder Mailbox.

Ich habe das gerade noch einmal auf meinem Server kontrolliert. Mein Bekannter (Unternehmer) hat 25GB Mails auf meinem Server. 25GB auf seinem Rechner in der Datenbank. Die Mailbox ist per IMAP angebunden und Mail läuft den ganzen Tag.

Also kann man doch nur empfehlen die Mails auf einem Server zu lagern und per IMAP einzubinden. Lokale Mails sind dann nicht mehr vorhanden und es ist immer ein Backup und Verfügbarkeit aller Mails Online und Offline.

Frohes neues Jahr.

Sehr interessant. Was funktioniert denn nicht? Das von mir beschriebene Problem (falls man es als Problem sehen möchte) gibt es schon in den Vorgänger OS X Versionen.
In meinem Fall handelt es sich um ein Macbook 13". Dort sind die Plattengrößen beschränkt. Das Maximum sind die von mir verwendeten 1TB.
Nach bisherigen Untersuchungen funktioniert es auch ohne die separaten Anhänge tadellos. Wenn ich die separat gespeicherten Anhänge lösche, bemerke ich (bislang noch) keine funktionale Einschränkung. Ich bleibe aber vorsichtig. Das Durchsuchen von bspw. Zip-Archiven - falls das der Grund für die separate Ablage wäre - wäre softwaretechnisch ohne Probleme lösbar. Es gibt sogar Plugins für Spotlight.
Wenn Du deine Logik konsequent umsetzt, kämst Du zu dem Schluss, die Mails in Mail aufzubewahren, so wie Du forderst Bilder in Aperture oder bspw. Musik in iTunes zu verwalten.
Wenn man einen Brief mit einer Anlage bekommt, ist es wichtig, Brief und Anlage gemeinsam aufzubewahren. Damit man sieht, was man wann bekommen hat und was in Ergänzung zur Anlage vom Absender geschrieben wurde. Genau das macht ja Mail.app via .emlx Datei vorzüglich. Mail und Anhang sind beieinander und man kann auf beides zugreifen.
Öhm - was spricht dagegen, die eigenen Mails fortwährend aufzubewahren? Was spricht gegen ein LAPTOP? Brauche ich dafür einen MacPro oder einen iMac?
Falls von mir die Rede ist - ich habe natürlich eine 1TB SSD. Und wenn's das 13er Macbook mit 2TB gäbe, hätte ich ein solches.
Die 1TB sind trotzdem knapp. Schließlich habe ich noch Fotos (Lightroom) und Musik (iTunes) und ein paar andere Dokumente (Finder).

Das „Problem“ gibt es seit Tiger (OS X 10.4). Damals wurde die interne Architektur von Mail komplett umgebaut, um es mit Spotlight kompatibel zu machen.
Ist das noch eine SATA-Festplatte oder schon eine PCIe-SSD? Falls ersteres, müsstest Du auf 4 TB aufrüsten können.
Die Frage ist, was ist „es“? Natürlich sind die Daten noch da, in den Mails selbst. Sie müssen nur jedesmal erneut entpackt werden, wenn Du die Mail aufrufst. Das ist ein Performanceproblem, und wenn Du sehr oft verschiedene Mails aufrufst und Deine Festplatte ist eine SSD, verkürzt Du deren Lebensdauer (weil permanent neu entpackt und damit auch neu gespeichert wird).
„Ohne Probleme“? Das geht prinzipiell nur so, dass die Datei aus der Mail extrahiert wird, dann der Spotlight-Index aktualisiert wird, und dann die extrahierte Datei wieder gelöscht wird. Wie bei allen Cache-Fragen ist das immer eine Abwägung zwischen Performance/Anzahl der Schreibvorgänge und belegtem Plattenplatz. Bei OS X fällt generell die Entscheidung in aller Regel pro Cache, contra Plattenplatz aus, weil der eben im Überfluss vorhanden ist.

Ob Spotlight zwingend auf die Existenz der indizierten Datei angewiesen ist oder auch funktionieren würde, wenn (nach der Indizierung) jedes Mal erneut entpackt werden muss, kann ich aus dem Stegreif jetzt nicht sagen.
Klar, aber die müssen auch extrahieren. Zaubern kann keiner.
Mails, ja. Aber nicht darin enthaltene Anhänge.
Bei kleineren Anlagen kann ich das nachvollziehen, da mache ich das auch so. Aber bei größeren Anlagen fände ich ein dediziertes Archiv für diese Anlagen sinnvoller als Mail, das darauf nicht optimiert ist. Da würde ich eher versuchen, den Textinhalt der Mail als Metadaten bzw. Kommentar den Anlagen in deren spezialisiertem Archiv anzuheften.

Und offenbar sind Deine Anlagen ja sehr groß. Ich dachte daher automatisch, das seien Fotos oder Videos, aber im weiteren Verlauf Deines Beitrags erwähnst Du Fotos getrennt davon.

Was sind das denn für geheimnisvolle Anlagen, kannst Du das sagen?
Nicht das geringste.
Wenn ich etwas dauerhaft aufheben will, ist es offenbar wichtig. Und ich würde wichtige Daten nur stationären Geräten anvertrauen; die sind robuster, werden weniger strapaziert und können nicht (so leicht) gestohlen werden/verloren gehen.
Hmpf, das klingt nach fest verbautem Speicher, ja, das ist dann natürlich doof.

Ein Grund mehr gegen Laptops …