ubuntuusers.de

Ich habe eine Diskrepanz beim Versenden von Email-Anhängen auf einem Server, die ich nicht verstehe:

Die Situation: Ich erzeuge mir eine 25MB große Datei und versende diese, was leider fehlschlägt:

$ dd if=/dev/random of=attachment_25MB.txt bs=25M count=1
$ echo "Die ist eine Testmail mit 25MB Anhang" | mutt -s "Testmail mit 25MB Anhang" -a attachment_25MB.txt -- test@bla.de
Debugging at level 5.
postdrop: warning: uid=0: File too large
sendmail: fatal: root(0): message file too big
Error sending message, child exited 75 (Deferred.).
Could not send the message.

$ postconf message_size_limit
message_size_limit = 51200000

Wenn ich das message_size_limit auf z.B. 76800000 setze, dann funktioniert das Versenden. Also bin ich schonmal an der richtigen Stellschraube.

Aber woher kann dieser arge Gap kommen? Wenn ich die Datei attachment_25MB.txt base64 kodiere, was mutt ja mit Anhängen tut, dann hat sie eine Größe von 35412438Bytes, also immernoch weit unter dem Limit.

Hat jemand eine Idee dazu? Ich habe schon einigermaßen geforscht, bin aber mittlerweile ziemlich ratlos. Die base64-Kodierung war da eigentlich der einzige Hinweise für solche Diskrepanzen, den ich gefunden habe.

Kannst du dir die Mail mal selbst zuschicken ohne das aktivierte Limit? Dann könnte man gucken, wie groß die wirklich ist, wenn die ankommt. Da kommen zwar paar Header hinzu, die sollten den Bock aber nicht fett machen.

Mail Header haben auch nochmal ordentlich Impact. Nur paar Kilobyte, aber wenn man mit Mails hantiert die knapp an der Grenze sind...

Also tatsächlich sind die Mails gar nicht angekommen, auch wenn nach dem Mutt-Kommando keine Fehlermeldung mehr kam. Denn an unserem Relayserver sind sie dann hängengeblieben, der auch 51200000 als size_limit gesetzt hat. Aber der meldet dann tatsächlich zurück: message size 61316667 exceeds size limit 51200000 of server. Und das bei einer Datei, die gerade mal 25MB als Anhang hat.

Also der Header und so haben ein paar Kb, aber mehr doch auch nicht. Ich bin ja weit, weit unter der Grenze.

Also, ich habe jetzt die empfangene Mail im Thunderbird gespeichert und tatsächlich hat die eml-Datei 59MB.

Dann müssen überall diese Limits gesetzt werden. Ich rate aber davon ab, weil Mail nicht für solch große Dateien gemacht ist. Bei dir intern geht das, da kannst du das einstellen, extern wird über 10 MB oft abgelehnt.

Hat jemand eine Idee dazu?

Ja.

Ein Attachment kann mittels "base64" encodiert werden. Das muss aber nicht sein. Bei "base64" vergrößert sich die Datei um den Faktor 1,5, da 2 Bytes in 3 base64 Zeichen gewandelt werden. In deinem Fall scheint aber keine "base64" Encodierung stattgefunden zu haben sondern ein "quoted-printable" (siehe RFC 2045). Hierbei wird ein Byte in 3 Zeichen ("="+2 Hex-Zeichen) gewandelt. Welche Methode dein Client wählt hängt von seinem internen "Optimierungs"-Algorithmus ab, der manchmal auch hinsichtlich der Dateigröße eine Fehlentscheidung trifft.

Exportiere deine Mail mal im .mbox Formal (bei Microsoft heißt das .eml) und schau dir die Struktur der Mail an. Dann siehst du, dass nach den einfachen, bekannten Mail-Header-Tags die Einträge kommen, die das Spam-Handling bestimmen (meist X- und UI-Tags). Diese habe auch schon ein paar Byte Länge und sind in der Regel "base64" encodiert.

Danach kommt das spannende "Envelope"-Konstrukt, das man nach einer Leerzeile mit zwei startenden Minuszeichen erkennt. Nach dieser "Envelope" Kennung kommen ein paar Zeilen, die den Inhalt des folgenden Informationsblocks beschreiben. Für deinen Mail-Body ist dies z.B. "Content-Type: text/plain" (wenn du nicht HTML o.Ä. erzwingst).

Für den Anhang wird nach der "Envelope" Kennung der "Content-Type", die "Content-Disposition" (z.B. attachment) und der "filename" beschrieben. Wie die Bytes zwischen dieser Beschreibung und der nächsten "Envelope" Kennung zu interpretieren sind, wird mit dem Tag "Content-Transfer-Encoding" (z.B. quoted-printable) beschrieben.

Wenn du also eine 25MB große Datei versenden willst, ist der Anhang 25*3 MBytes plus Mail-Header und Body groß.

Sorry, dass ich dies jetzt so oberflächlich beschrieben habe. Bei Bedarf kann ich das auch detaillierter erläutern.

PS: Die Größendiskrepanz zwischen 25*3=75MB und den tatsächlich festgestellten 59MB lässt sich einfach dadurch erklären, dass der Anhang eben auch "normale", druckbare Zeichen enthält, die nicht als "quoted-printable" encodiert werden müssen. Wahrscheinlich hat der "Optimierungs"-Algorithmus des Clients diese Zeichen gesehen und daraufhin beschlossen, den Anhang nicht per "base64" zu behandeln.

Ok, danke für die Hinweise, die ich übrigens überhaupt nicht oberflächlich fand!

Also ja, die EMail ist tatsächlich Quoted-printable kodiert. Der Faktor mal 3 für die Größe stimmt ja nicht so ganz, denn Postfix meldete, dass die Mail 61316667 Bytes groß sei und das Attachment ist 25MB groß.

Aber ok, dann weiß ich zumindest schonmal, wo ich weiter graben muss!

Ich habe bei meinem Versuch mit 25MB zufälligen Zeichen folgendes Ergebnis berechnet:

$ ls -sh "Testmail mit 25MB Anhang.mbox" 
59M 'Testmail mit 25MB Anhang.mbox'
$ marker=$(sed -n '/^--[^=]*\r$/p' "Testmail mit 25MB Anhang.mbox" | sed -n 1p)
$ echo $marker	# der ist jedesmal ein anderer String
--uhMayb9xzb6BK79G
$ csplit "Testmail mit 25MB Anhang.mbox" /^$marker/ {*}
5256
136
61320445
$ # Eliminiere die "Envelope" Kennungen und die Tags
$ sed '1,/^\r$/d;$d' xx02 >attachment.txt
$ wc -c attachment.txt 
61320250 attachment.txt
$ # ohne die Fortsetzungsmarkierung:
$ sed 's/=\r$//' attachment.txt | wc -c
59838484
$ # Zähle Häufigkeit des "="
$ sed 's/=\r$//' attachment.txt | sed 's/./&\n/g' | sort | uniq -c | grep "="
16390378 =
$ # Anzahl der "\r" bei Zeilenende wegen "\r\n"
$ wc -l attachment.txt 
843327 attachment.txt
$ # Somit Berechnung der Bytes:
$ echo $(((59838484 - 16390378*2 - 843327)/1024/1024))
25
$ # Also 25 MB großes Attachment