Hi.
Two questions:
- Is this now reasonably stable for large mailboxes (c 2mm messages)?
- Will this leave the filename in the message body unchanged? So for example if I have the same attachment called proposalfromvendor.pdf and proposaltoclient.pdf in two different emails, will the original names be kept ? Or will it replace the filename with some kind of numeric hash ?
Many thanks.
Laeeth
Sent from my iPad
Am 19.06.2014 16:52, schrieb Laeeth Isharc:
- Is this now reasonably stable for large mailboxes (c 2mm messages)?
dunno
- Will this leave the filename in the message body unchanged? So for example if I have the same attachment called proposalfromvendor.pdf and proposaltoclient.pdf in two different emails, will the original names be kept ? Or will it replace the filename with some kind of numeric hash ?
the message body must not be changed never, not in any single case for no reason
why? because it breaks all sort of sigend mails
dunno how this is implemented, in case of dbmail each message is splitted in it's mimeparts, they are all stored with a sha1sum and referenced to the messages, fetch a message re-constrcuts the whole mail from it's mimeparts and everytime a new mimepart arrives it's verified with the existing checksums to decide if a new record is needed or only a reference - after all references are gone the record for a mimepart is deleted
On 06/19/14 10:52 AM, Laeeth Isharc wrote:
- Is this now reasonably stable for large mailboxes (c 2mm messages)?
We have not had any problems. YMMV and should be tested before putting into production.
- Will this leave the filename in the message body unchanged? So for example if I have the same attachment called proposalfromvendor.pdf and proposaltoclient.pdf in two different emails, will the original names be kept ? Or will it replace the filename with some kind of numeric hash ?
There are no changes. It is completely transparent. It stores the attachments using an internal hash.
participants (3)
-
Laeeth Isharc
-
Oscar del Rio
-
Reindl Harald