Ability to set an alternate/dedicated storage for attachments
Idea shared by Sébastien Riccio - 5/8/2020 at 8:55 PM

Actually one of the "issue" we have a service provider using SmarterMail is that we can't dedicate a storage for storing mail attachments.

On other mail solutions we use, for example one based on the opensource dovecot project, we can set a separate storage for attachments.
This has many advantages:

- We can use a different backup strategy for the attachement dedicated folder
- The attachments are saved decoded instead of mime encoded, therfore it takes less space.
- It has options for deduplication (a redudent attachment with same checksum, is only stored once and can be referenced to multiple mail objects)
- We can decide to remove attachments from mails after a chosen period of time

This significally decrease the users mailboxes size. For example an attached 10MB document sent to 20 users of a domain will take only 10MB of space instead of (20 x 10 x mime encoding size increase ratio) ~300MB.

For a server with lot of users this can really make a huge difference.

On dovecot this exists since 2010  is easily configurable for example like this:

mail_home = /mailstore/local/%d/%n
mail_location = mdbox:/mailstore/local/%d/%n:ALT=/mailstore/remote/%d/%n
mail_attachment_fs = sis posix
mail_attachment_dir = /mailstore/attachments
mail_attachment_min_size = 128k	
We would really love to see such an option in SmarterMail and think it would really add a plus to it.

Kind regards
Sébastien Riccio
System & Network Admin

4 Replies

Reply to Thread
Good idea, but I don't know if it's feasible ...
Agreed Gabriele, good idea, but in the real world, I dunno...
Hmm do you see any issues or disadvantage with this feat ? Actually, we use it with dovecot with great success.
Sébastien Riccio
System & Network Admin

I think setting it up would be hell for them. If it only saves 1 copy of the attachment, how are deletions of emails with said attachment handled? Is the attachment simply kept forever? Have to perform checks to see if said attachment is still used by any emails in the system.

What if something goes wrong with the storage system, all attachments are now gone? How does SM now handle this? What about incoming emails? I'd rather just make the primary array larger, honestly, a 10MB attachment sent to 30 users probably isnt super common and 300MB isnt really a big deal especially given how cheap storage is now-a-days.

Reply to Thread