Message Storage Details

First, it may be helpful to know a little bit about how e-mail messages are actually sent across the wire:

Messages are grouped into multiple message payload parts, and should binary attachments exist, they are encoded into text using, generally, base64 or quoted-printable encodings.

Earlier versions of this library would preserve the above text verbatim in the database, but neither of the above encodings are very efficient methods of storing binary data, and databases aren’t really ideal for storing large chunks of binary data anyway.

Modern versions of this library (>=2.1) will walk through the original message, write models.MessageAttachment records for each non-text attachment, and alter the message body removing the original payload component, but writing a custom header providing the library enough information to re-build the message in the event that one needs a python email.message.Message object.

The above payload is what would continue to be stored in the database. Although in this constructed example, this reduces the message’s size only marginally, in most instances, attached files are much larger than the attachment shown here.


Email message bodies are base-64 encoded when stored in the database.

Although the attachment is no longer preserved in the message body above, and only the X-Django-Mailbox-Interpolate-Attachment: 1308 header remains in the place of the original attachment, the attachment was stored in a django_mailbox.MesageAttachment record:

Field Value Description
Primary Key 1308 Uniquely generated for each attachment.
Headers Content-Type: image/png; name="heart.png" Content-Disposition: attachment; filename="heart.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hc6mair60 Raw headers from the actual message’s payload part.
File (binary file object) References a stored-on-disk binary file corresponding with this attachment.

And were one to run the django_mailbox.Message instance’s get_email_object method, the following message will be returned:


Note that although the above is functionally identical to the originally received message, there were changes in the order of headers in rehydrated message components, and whitespace changes are also possible (but not shown above).