There should obviously be a method for dealing with high-load
conditions, where DBMail stores the message initially without doing the
SIS work, but flags it for processing later when the load goes below a
pre-configured level.
I don't see how that's obvious. If we move to storing unique mime-parts
only once, the only way to store any mime-part is by calculating the
sha1 value for such a mime part. What you are proposing is a stepped
insertion. That would require a full mail-spool type setup. Better leave
that to the MTA: simply refuse SMTP/LMTP connections when the load is
too high.
Ok, sounds reasonable...
Once we have this setup, using dbmail as an archive server is that
much more attractive. People may very well start using it to store
big files, and a lot of it!
But DBMail is for *mail* storage, no? It is not a *file* storage system...
Which is why there should be an internal max_size that is set to
something sane (100MB? 200MB?) - and a configurable max_size setting
that would allow an admin to set a *lower* max_size. Then, if someone
wants to change the internal max_size, they will have to know what they
are doing (to change the sources and re-compile)...
I would *never* allow my mail system to store individual *emails* larger
than 50MB...
--
Best regards,
Charles
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
