Maximum grootte / size

Bij het verzenden van een email melde macOS een message size van 41.5 (file size bijlage volgens finder (verkenner): 40.974.014 bytes (41 MB on disk)) maar het bericht kon niet verzonden worden omdat de grootte meer dan 52.4 MB zou zijn, zie screenshot:


(edit @kweetwel: Even e-mailadressen geblurred)

Kan iemand mij vertellen waar die meer dan 10 MB extra vandaan komt? Is dat een overhead of een bug?

Dat wordt veroorzaakt door MIME encoding.

Zie “Content-Transfer-Encoding”.

2 likes

Bij MIME transport wordt een encoding gebruikt waarbij uitsluitend ASCII (het enige dat SMTP kent) gebruikt wordt in de body (Mail tekst + attachments) van de mail.
Alle data die potentieel niet ASCII is wordt dan ook met 6 bitjes uit ieder byte omgecodeerd naar een ASCII teken.
hierdoor zijn er 4 bytes nodig voor elk verzonden attachment document. ==>
Attachments worden 4/3 maal de originele maat de 41MB document wordt 41*4/3 =
40.974.014 * 4 / 3 = 54632018 bytes groot. (evt. volgen nog 1 to 3 opvul bytes om op een door 4 deelbaar aantal tekens uit te komen).
(Er komt ook nog een mime header mee. Ook moet niet vergeten worden dat de Mail Header (Transportlog, Subject, etc. etc) ook mee telt in het totale aantal bytes. en dat kan ook al snel ettelijke KB groot worden).

Zijn het er niet 7?

  • 7bit – up to 998 octets per line of the code range 1…127 with CR and LF (codes 13 and 10 respectively) only allowed to appear as part of a CRLF line ending. This is the default value.

ASCII is slechts 7 bitjes + Parity
Nee 6 bitjes omdat de control characters er ook uit moeten vallen.
Encoding is base64 ( dat vereist 6 bitjes).
In theorie kun je 96 van de 128 tekens gebruiken, echter door base64 encoding win je veel aan snelheid van coderen/decoderen.
(dit geldt voor de meeste attachments),
Er zijn attachments die erg op ASCII lijken, die gebruiken “Quoted Printable” waar bij een paar tekens escaped worden.
Dat kan echter niet voor documenten die alle 256 tekens kunnen bevatten. daar zullen gemiddeld de meeste tekens een escape nodig hebben en dan wordt een document gemiddeld 2 maal zo groot. (binary documenten…)

Dus base64 is een snel en redelijk compact alternatief.

1 like

Ben benieuwd:
Kan ik met LibreOffice en GIMP regelen dat de opslag in base64 komt?
( Bijvoorbeeld door “Opslaan-Als” een slim bestandsformaat te nemen … )

Niet direct, maar met standaard UNIX-tools kan je natuurlijk wel bestanden encoden en decoden:

kevin@selenium:~$ echo "Hallo" > test.txt

kevin@selenium:~$ cat test.txt | base64 > base64.txt

kevin@selenium:~$ cat base64.txt 
SGFsbG8K

kevin@selenium:~$ cat base64.txt | base64 -d
Hallo

Zo kan je dus ook een .odt of zo pipen (met |) naar base64 en eventueel die output redirecten (met >) naar een nieuw bestand.

1 like

Kevin heeft de vraag eigenlijk al beantwoord.
Ik heb nog wel een aanvulling/vraag:

De vraag is wat je opschiet met alles in base64 op te slaan. De meeste tools gebruiken niet base64 als native opslag wat dus altijd een handmatige actie vereist voor encoding & decoding.
Als een mailer niet eerst het programma even snel checked of het ascii is dan loop je het risico dat het attackement een “document formaat, omgezet in base64 omgezet in base64” wordt.
Het nadeel is dat elk document dan gelijk 33% groter wordt.

Eigenlijk is mail niet zo geschikt om bestanden te versturen. Beter is bijvoorbeeld sftp of via dropbox, owncloud, stack enz…

1 like

Dank @Kevin en @Noci ,
soms blijkt een oplossing dus al jaren onder mijn eigen toetsenbord te zitten.
Als ik bang ben voor “tweemaal” base64-encoding, dan kan ik toch als volgt handelen:
.1. volgens de door Kevin aangegeven eenvoudige methode coderen,
.2. kijken hoe groot het bestand is geworden
.3. beoordelen of dat ruim onder de maximale bijlage-grootte is
en dan
.4. gewoon het originele (ongecodeerde) bestand als bijlage versturen

Is-ie te groot ?!?
.1. Kies dan jouw optimale privacy-veilige Transfer-Website (bijvoorbeeld WeTransfer)
.2. Mail het bestand vanaf jouw SineNomine-email adres naar datzelfde
adres
(werkt, heb ik getest)
.3. De verzender ontvangt een (korte) directe link, de ontvanger een (uitgebreidere) link met tracking-ID-code er in
.4. Mail de kortste link naar de mensen voor wie het bestand bedoeld is.

Op deze manier zorg je dat er extern geen koppelingen worden gelegd tussen : jou, het-bestand en de-anderen

Het zal hooguit opvallen, dat “jij” jouw eigen bestand vanaf diverse IP-nummers weer download …
(aanvullingen of tips hiervoor zijn welkom)

Ik pak dat makkelijker aan… Als de limiet 40MiB is dan kan een bestand max. 30MB zijn (niet MiB’s).
(MB = 1000x1000, MiB = 1024*1024) . Daarmee is er dan ook waarschijnlijk voldoende ruimte voor headers.
Kortom haal 25% van de limiet af en je hebt de maximale bestandsgrootte. (dat scheelt weer een conversie.)