Outlook Emails mit großen Anhängen verschieben

jeff

Aktives Mitglied
Thread Starter
Dabei seit
10.11.2003
Beiträge
571
Reaktionspunkte
17
Hallo zusammen,

meine Frau nutzt an ihrem Mac Outlook aus dem Office 365 Paket.

Nachdem alle Mailkonten dort eingerichtet waren, wurde ein Postfach vollständig von IMAP-Postfach "A" nach IMAP-Postfach "B" verschoben. Bei der Synchronisierung weigert sich Outlook vehement Emails mit Anhängen größer wie 25MB hochzuladen. Das IMAP-Postfach "B" hat eine größe von etwa 100GB und keine (!) Dateigrößen Beschränkung.

Bei der "internen" Verwaltung/Ablage darf das doch nicht passieren. Es geht ja nicht um das Versenden von Mails, sondern nur um das interne verschieben.

Weiß da jemand eine Lösung, wie ich die Mails, die nun in Outlook "lokal" festhängen wieder auf den Server (IMAP Postfach "B") bekomme, damit die auch an anderen Geräten wieder im entsprechenden Postfach verfügbar sind?
Ich bin wirklich nicht unwissend, aber da komme ich echt nicht weiter.

Vielen Dank. :)
Jeffrey
 
Also wenn ich das richtig in Erinnerung habe ist das eine Beschränkung von (macOS Version) Outlook welche man nicht abschalten kann.
 
Also wenn ich das richtig in Erinnerung habe
Japp, hast du:

https://support.office.com/de-de/article/korrekturen-oder-problemumgehungen-für-aktuelle-probleme-in-outlook-für-mac-54afa5e3-db38-422a-9d94-3b55330ded8e?ui=de-DE&rs=de-DE&ad=DE

Dort:
In Outlook für Mac können unter IMAP oder POP keine Dateien mit mehr als 25 MB angefügt werden [PROBLEMUMGEHUNG]

Letzte Aktualisierung: August 2017

PROBLEM

Wenn Sie versuchen, eine E-Mail-Nachricht mit einer Anlage, die größer als 25 MB ist, zu senden, wird eine Fehlermeldung angezeigt, und die E-Mail-Nachrichten wird nicht gesendet.

STATUS: Problemumgehung

Wir arbeiten an einer Behebung dieses Problems. In der Zwischenzeit verwenden Sie bitte Webmail zum Senden von Anlagen, die größer als 25 MB sind.
Wohlgemerkt: Status seit 2017 – Godot ist schneller.

Es geht ja nicht um das Versenden von Mails, sondern nur um das interne verschieben.
Na, wenn’s POP-Konten mit rein lokalen Daten auf dem Rechner wären, die zwischen ebenso lokalen Ordnern verschoben werden. So aber werden Serverbefehle gegeben, von denen ich spekuliere, dass Outlook sie wie ein »richtiges« Senden versteht und behandelt.

Ob jemand schon versucht hat, den Registry-Häck sinngemäß als neuem Schlüssel in die com.microsoft.Outlook.plist einzutragen (also nach Muster der Vorhandenen Schlüssel einen zusätzlichen zu schreiben) – und mit welchem (Miss)Erfolg, weiß ich nicht zu beantworten.
Aus: https://www.mailhilfe.de/maximale-dateigroesse-von-outlook-anhaengen-erhoehen :
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\Preferences
Value name: MaximumAttachmentSize
Value type: REG_DWORD
 
Zuletzt bearbeitet:
Ja, das ist leider totaler Bockmist. Hätte ich das vorher gewusst, hätte ich Outlook auf dem Rechner niemals zugelassen. :kopfkratz:
Die Plist habe ich nicht gefunden. Bei einer 365 Installation scheint es die nicht zu geben oder sie heißt anders. Ich mache mich am Wochenende mal auf die Suche.
 
da brauchst du nicht zu suchen, die macversion liest den wert schlicht nicht. und falls du mit imap-postfach A und B verschiedene konten meinst, dann ist das auch kein einfaches internes verschieben.

ich verwende für solch umzugsaktionen imapsync oder offlineimap oder halt einen client der keine begrenzung hat, wie z.b. thunderbird.
wo laufen denn die konten A/B, auf eigenem server (also zugriff via ssh und installationsmöglichkeit)?
 
Zuletzt bearbeitet:
Lustigerweise gilt dieserart Emailgrößenbeschränkung herstellerseitig wohl mehr als Feature denn als Bug.

Wie aus dem Inhalt einer meiner Links interpretiert werden kann, soll die Beschränkung technischen Problemen vorbeugen, wenn Outlook eine serverseitige Dateigrößenbeschränkung nicht ermitteln kann.

Bekannt ist ja bei Emailanwendungen – eben nicht nur bei Outlook – das Problem, dass eine reale Beschränkung beim Dienstleister manchmal nicht mit einer serverseitigen Fehlermeldung über die Ablehnung des Versands (eigener Dienstleister) oder des Empfangs (beim Server des Empfängers) quittiert wird. Dann kann die Email in der eigenen – lokalen – Postausgangsliste als unversandt hängenbleiben, und zu Dauerfehlermeldungen führen, wenn bzw. weil sich die Email nicht mehr aus jener Liste löschen lässt. (Ganz zu schweigen vom möglichen Emailbouncing zwischen eigenem SMTP und dem Eingangsserver des Empfängers, wenn sich Letzterer nicht ordnungsgemäß über die Ablehnung der Email rückmeldet – und der SMTP den Versand wiederholt neu versucht.)

Bis Outlook2007 (Win) gab’s noch keine programmseitige Größenbeschränkung – und bemerkenswerterweise genau dáfür einen Häck, eine Größenbeschränkung manuell nachzurüsten. Ab Outlook2010 (Win) ist’s also genau umgekehrt. Jetzt versucht die ganze Welt, die nunmehr im Programm eingebaute Grenze auszuhebeln.

Dabei genügt doch eigentlich ein Schalter in den Prefs der Emailer, über das Ein- oder Ausschalten einer programmseitigen Größengrenze und deren Höhe selbst zu bestimmen. Dann ist’s aber auch die eigene Entscheidung, mit etwaigen Sendefehlern (s.o.) zu leben.

Letztlich sind wir, wie sinngemäß bei der Frage nach formatierten vs. Nurtext-Emails, im Grabenkampf der Traditionalisten vs. Neuländer angekommen, bei dem von Letzteren ein Medium für einen Zweck verwendet wird, bei dem die Altvorderen noch telnet oder ftp zu verwenden angeraten hätten.
 
du kannst die maximum message size des mail servers selbst ermitteln:
Bash:
curl -v smtp://smtp.outlook.com 2>&1 | grep '250-SIZE' | awk '{print $NF/1048576 "MB"}'
mir ist seit langem kein server mehr untergekommen, der die size nicht ausgibt und wie man sieht, steht selbst outlook.com bei 150MB.
es hängt aber ebenfalls vom server des empfängers ab, wobei meist bei den kleinen und mittleren providern die standardgrößen nicht geändert werden. MS wurde in den letzten jahren immer restriktiver, vor allem bezgl. mißbrauch und spam (grausig allein das prozedere, wenn man auf deren blacklist gelandet ist) und jeder moderne mailclient hat mittlerweile ebenfalls die möglichkeit für cloud-attachments.

Dann kann die Email in der eigenen – lokalen – Postausgangsliste als unversandt hängenbleiben
wenn dein mailserver die mail annimmt, bist du fertig. das hat nichts damit zu tun, ob der empfängerserver die mail annimmt.
es gibt ja auch noch mehr gründe, warum die mail beim empfänger nicht zugestellt werden kann.
 
Zuletzt bearbeitet:
da brauchst du nicht zu suchen, die macversion liest den wert schlicht nicht. und falls du mit imap-postfach A und B verschiedene konten meinst, dann ist das auch kein einfaches internes verschieben.

ich verwende für solch umzugsaktionen imapsync oder offlineimap oder halt einen client der keine begrenzung hat, wie z.b. thunderbird.
wo laufen denn die konten A/B, auf eigenem server (also zugriff via ssh und installationsmöglichkeit)?

Das habe ich schon befürchtet. Postfach A war ein GMX Account. Der neue Account (B) liegt bei Host Europe. Alle betreffenden Mails sollten da innerhalb der Serverspezifikationen liegen. Nur Outlook hat mir da jetzt beim hochladen zu HE einen Strich durch die Rechnung gemacht.
 
wenn dein mailserver die mail annimmt, bist du fertig.
Aja? Auch bei IMAP (oder Exchange)?
Wie soll der Status des Sendeauftrags denn in der Anzeige des Emailprogramms sicher wiedergegeben werden (also: im »Ausgang« oder unter »Gesendet«) wenn das Ergebnis genau dieser (lokalen Programm–)Anzeige der synchronisierte Zustand auf dem (entfernten) Server des eigenen Dienstleisters ist?

Solange alles »normal« läuft, ist ja auch alles OK. Der eigene Dienstleister will die große Email nicht: Nachricht über die Ablehnung und gut; der Dienstleister des Empfängers will die Email nicht: Nachricht über die Ablehnung und gut is’.

Spätestens aber wenn die Entgegennahme beim Empfänger – warum auch immer – meldungslos scheitert, versucht der eigene Dienstleister erneute Zustellungsversuche. Bis zum endgültigen Abbruch der Versuche liegt die Email dann im »Ausgang« (also im Emailprogramm in der lokalen Anzeige des Inhalts des Ausgangsordners auf dem Postausgangsserver). Siehe dann dazu Threads a la »Ich bekomme die Email nicht aus dem Postausgang«. Der Versand ist ja noch nicht final abgeschlossen; er kann noch nicht als »gesendet« verbucht werden.

Bei POP-Konten ist nach Entgegennahme des Sendeauftrags beim SMTP dann lokal in der Anzeige tatsächlich Schluss. Die Email wird, lokal, unter »Gesendet« verbucht. Vielleicht kommt dann irgendwann eine Rück-Email über die gescheiterte Zustellung – oder auch nicht.

Das ist freilich nur der Versuch einer Begründung für die programmseitige Begrenzung als Fallback zur sicheren Seite, keine Rechtfertigung. Denn ein einfacher Schalter in den Voreinstellungen des Programms tät’s ja auch: Sind Sie sicher? [Ja] [Nein] [Abbrechen].
 
Spätestens aber wenn die Entgegennahme beim Empfänger – warum auch immer – meldungslos scheitert, versucht der eigene Dienstleister erneute Zustellungsversuche. Bis zum endgültigen Abbruch der Versuche liegt die Email dann im »Ausgang« (also im Emailprogramm in der lokalen Anzeige des Inhalts des Ausgangsordners auf dem Postausgangsserver). Siehe dann dazu Threads a la »Ich bekomme die Email nicht aus dem Postausgang«. Der Versand ist ja noch nicht final abgeschlossen; er kann noch nicht als »gesendet« verbucht werden.
meldungsloses scheitern gibt es im mailverkehr nicht. entweder der empfängerserver nimmt erfolgreich an, dann wird auch quittiert oder eben nicht. sobald aber dein mailserver die mail annimmt, wird sie bei imap u.ä. danach *für dich* in dein imap-konto kopiert, falls das so eingestellt ist und du bist fertig mit senden. ob die mail dann noch beim empfänger angekommen ist, steht zu dem zeitpunkt oft nicht fest. siehe z.b. senden an nicht existente empfänger, das ist vermutlich jedem schon einmal passiert. da liegt deine mail längst in Sent, aber der bounce kommt erst nach einer weile, je nach zustellversuchshäufigkeit.

Bei POP-Konten ist nach Entgegennahme des Sendeauftrags beim SMTP dann lokal in der Anzeige tatsächlich Schluss.
spätestens jetzt siehst du, dass smtp und pop/imap nichts miteinander zu tun haben, nur weil sie im mailprogramm passend gehändelt werden. bei pop hast du einfach nur eine INBOX, da kann ja auch nichts ausgehend betreffendes gespeichert werden.
ausserdem kannst du jederzeit ein vom imap-konto verschiedenes smtp-konto für's versenden verwenden. das muss nicht zwingend passend zum mailverwaltungskonto sein.

zusammenfassend: dass deine versandte mail in Sent (imap/lokal/wherever) auftaucht, hat nichts mit dem status des mailversands zu tun und ist in SMTP auch überhaupt nicht adressiert (was nicht heisst, dass der server es nicht könnte - siehe exchange/gmail). wenn probleme auftreten, bekommt man entsprechende meldungen vom beteiligten SMTP-server, und fehlkonfigurationen gibt es leider auch immer, gerade weil mailserver eher zu den komplizierteren diensten zählen.
 
Zuletzt bearbeitet:
Zurück
Oben Unten