Ok, thanks.
But :)
What is strange for me is disk usage.
du -s -h /var/mail/attachments/8b/67/
16M /var/mail/attachments/8b/67/
check indes
ls -i /var/mail/attachments/8b/67/
662975
Hi Michal,
On 06.01.21 00:18, Michał Kiljański wrote:
Hi,
My setup is:
mail_attachment_dir = /var/mail/attachments
mail_attachment_hash = %{sha512}
mail_attachment_min_size = 64k
mail_attachment_fs = sis posix
Something works - but I expected that is one instance of file, and this
file is
Hi,
My setup is:
mail_attachment_dir = /var/mail/attachments
mail_attachment_hash = %{sha512}
mail_attachment_min_size = 64k
mail_attachment_fs = sis posix
Something works - but I expected that is one instance of file, and this
file is linked to messages. But here in folder I have got this:
sudo
Hello!
Name's Erik and I have been using Dovecot for a few months and I so far quite
happy with the software. To this list I am quite new though.
After a testing period I have now been running a ~300 user system running
CentOS 6 and Dovecot 2.1.14 with Postfix and SiS enabled.
For the large
On 25.3.2013, at 1.10, Erik Persson e...@lysator.liu.se wrote:
For the large part the system is running flawlessly but I have caught a few
error messages:
imap(censored@censored.domain): Error: Attachment file
25 mar 2013 kl. 00:19 skrev Timo Sirainen t...@iki.fi:
On 25.3.2013, at 1.10, Erik Persson e...@lysator.liu.se wrote:
For the large part the system is running flawlessly but I have caught a few
error messages:
imap(censored@censored.domain): Error: Attachment file
On 2012-03-28 7:57 PM, Timo Sirainen t...@iki.fi wrote:
It's easy to restore a full backup. And it's easy to restore specific
users if you have the full backup easily accessible (just run doveadm
import with proper settings pointing to backup). What's difficult is
if you just want to restore a
On 25.3.2012, at 18.12, Charles Marcus wrote:
On 2012-03-24 9:16 AM, Timo Sirainen t...@iki.fi wrote:
On 24.3.2012, at 14.54, Charles Marcus wrote:
On 2012-03-24 8:08 AM, Timo Sirainent...@iki.fi wrote:
You can do full backups from a filesystem snapshot, which works
well enough (might
On 2012-03-24 9:16 AM, Timo Sirainen t...@iki.fi wrote:
On 24.3.2012, at 14.54, Charles Marcus wrote:
On 2012-03-24 8:08 AM, Timo Sirainent...@iki.fi wrote:
You can do full backups from a filesystem snapshot, which works
well enough (might leave some unused attachments lying around in
some
On 2012-03-24 7:49 AM, Timo Sirainen t...@iki.fi wrote:
This is already optionally done in v2.0+dbox. MIME attachments can be
stored in plain binary form if they can be reconstructed back into
their original form. It doesn't break any signed stuff.
Hey Timo,
Splitting this off into a
On 24.3.2012, at 14.01, Charles Marcus wrote:
On the question of the existing SIS capability for attachments... have you
given any thought as to how to solve the problem of restoring from backups
when SIS is used? I was planning on using it initially, until I read on list
that restoring
On 2012-03-24 8:08 AM, Timo Sirainen t...@iki.fi wrote:
You can do full backups from a filesystem snapshot, which works
well enough (might leave some unused attachments lying around in
some rare cases, but that can also happen if Dovecot crashes/dies).
But the problem isn't with backups, but
On 24.3.2012, at 14.54, Charles Marcus wrote:
On 2012-03-24 8:08 AM, Timo Sirainen t...@iki.fi wrote:
You can do full backups from a filesystem snapshot, which works
well enough (might leave some unused attachments lying around in
some rare cases, but that can also happen if Dovecot
Hello,
SiS is implemented and stable in the last version ?
Best Regards
Guy
On Thu, 2011-03-31 at 18:40 +0200, Marcin Mirosław wrote:
P.S. Is it possible to have attachments comprest with zlib plugin?
Not currently. (Or you could of course use a filesystem that offers
compression internally.)
On Mon, 2011-03-28 at 16:00 +0200, Andrew Lewis wrote:
Do you think it's possible for you to reproduce this? If you have the
original pre-dbox mail and you convert it to a new
and empty dbox+sis and reading it gives this error message, I'd really like
to get the original mail.
Yes, I
On Mon, 2011-04-04 at 17:59 +0300, Timo Sirainen wrote:
Mar 28 15:54:38 mail dovecot: imap(dru.test@xxx): Error: Attachment file
/mailstore/attachments/ce/73/ce737a45fe07495e2ae6466f9e381a30d5ec300406f11269d79bd5608cc0c922-e2ff0d2b0692904dc51b9501e12a
larger than expected (252218)
Hi!
I'm not sure is it the same as described by Andrew Lewis, this is whay
i'm posting.
Log is:
2011-03-31T17:40:08.369598+02:00 hermes dovecot: imap-login: Login:
user=mar...@mejor.pl, method=PLAIN, rip=62.121.127.119,
lip=193.238.12.139, mpid=19221, TLS
2011-03-31T17:40:08.684562+02:00 hermes
On 31.3.2011, at 18.46, Marcin Mirosław wrote:
Error: Corrupted dbox file
/dane/domeny/mejor.pl/mail/marcin/mdbox/storage/m.1 (around
offset=98692): Ext refs metadata corrupted: 3604 3311 -
a5/2f/a52fbe2094a0f68cdb403d696b313d9e3fba6978-f722212d1ea0944daf4aa95b0854
..
# 2.0.11:
W dniu 2011-03-31 18:09, Timo Sirainen pisze:
Unpatched 2.0.11?
Now patched with mentioned patch ;)
Problem has gone away.
Thank you.
P.S. Is it possible to have attachments comprest with zlib plugin?
I recently set up SiS and imported a large chunk of mail.
I've noticed one or two instances of this in the logs:
Mar 28 09:03:50 mail dovecot: imap(x...@yyy.zz): Error: Attachment file
On 28.3.2011, at 16.25, Andrew Lewis wrote:
I recently set up SiS and imported a large chunk of mail.
With dsync?
I've noticed one or two instances of this in the logs:
Mar 28 09:03:50 mail dovecot: imap(x...@yyy.zz): Error: Attachment file
Hi Timo,
I recently set up SiS and imported a large chunk of mail.
With dsync?
Using fetchmail (delivery via LMTP) and imapsync, dsync does not support the
mail storage I moved away from.
Do you think it's possible for you to reproduce this? If you have the
original pre-dbox mail and you
I fixed a couple of bugs:
http://hg.dovecot.org/dovecot-2.0/rev/e5dcc12f8dba
http://hg.dovecot.org/dovecot-2.0/rev/4455f79f964d
But yeah, looks like there are some more bugs when mail compression is enabled.
It somehow truncates attachments sometimes. I'll continue looking into it..
On 3.12.2010, at 9.26, Timo Sirainen wrote:
I fixed a couple of bugs:
http://hg.dovecot.org/dovecot-2.0/rev/e5dcc12f8dba
http://hg.dovecot.org/dovecot-2.0/rev/4455f79f964d
But yeah, looks like there are some more bugs when mail compression is
enabled. It somehow truncates attachments
On 12/2/2010 11:52 PM, Timo Sirainen wrote:
On 2.12.2010, at 23.39, Daniel L. Miller wrote:
When I do a doveadm fetch -u user hdr uid 12557 I receive more than one
message. Is this normal?
Yes, because you didn't specify mailbox. Also don't just fetch hdr, that won't
trigger the error. So
On 12/3/2010 2:17 AM, Timo Sirainen wrote:
On 3.12.2010, at 9.26, Timo Sirainen wrote:
I fixed a couple of bugs:
http://hg.dovecot.org/dovecot-2.0/rev/e5dcc12f8dba
http://hg.dovecot.org/dovecot-2.0/rev/4455f79f964d
But yeah, looks like there are some more bugs when mail compression is
On 12/3/2010 9:15 AM, Daniel L. Miller wrote:
On 12/3/2010 2:17 AM, Timo Sirainen wrote:
On 3.12.2010, at 9.26, Timo Sirainen wrote:
I fixed a couple of bugs:
http://hg.dovecot.org/dovecot-2.0/rev/e5dcc12f8dba
http://hg.dovecot.org/dovecot-2.0/rev/4455f79f964d
But yeah, looks like there are
On 3.12.2010, at 23.28, Daniel L. Miller wrote:
Still breaking on new mails.
Show some error logs.
On 12/3/2010 3:32 PM, Timo Sirainen wrote:
On 3.12.2010, at 23.28, Daniel L. Miller wrote:
Still breaking on new mails.
Show some error logs.
Dec 3 15:24:45 bubba dovecot: imap(dmil...@amfes.com): Error: FETCH
[1.2.MIME] for mailbox INBOX UID 10921 got too little data: 0 vs 94
Dec 3
On 4.12.2010, at 0.46, Daniel L. Miller wrote:
On 12/3/2010 3:32 PM, Timo Sirainen wrote:
On 3.12.2010, at 23.28, Daniel L. Miller wrote:
Still breaking on new mails.
Show some error logs.
Dec 3 15:24:45 bubba dovecot: imap(dmil...@amfes.com): Error: FETCH
[1.2.MIME] for mailbox
On 12/1/2010 11:02 AM, Daniel L. Miller wrote:
On 12/1/2010 10:49 AM, Daniel L. Miller wrote:
On 11/30/2010 8:09 PM, Daniel L. Miller wrote:
Continuing to see errors on this with some new messages. Is it
possible this has anything to do with zlib plugin, or possibly
having a mix of zlib
On Thu, 2010-12-02 at 10:40 -0800, Daniel L. Miller wrote:
On 12/1/2010 11:02 AM, Daniel L. Miller wrote:
On 12/1/2010 10:49 AM, Daniel L. Miller wrote:
On 11/30/2010 8:09 PM, Daniel L. Miller wrote:
Continuing to see errors on this with some new messages. Is it
possible this has
On 12/2/2010 11:17 AM, Timo Sirainen wrote:
I'll try to look into this soon.. You could of course see if disabling
zlib plugin makes it work again? Or the best would be if you could get a
copy of such mdbox storage where this is reproducible with a doveadm
fetch command. I could then send some
On 2.12.2010, at 23.39, Daniel L. Miller wrote:
When I do a doveadm fetch -u user hdr uid 12557 I receive more than one
message. Is this normal?
Yes, because you didn't specify mailbox. Also don't just fetch hdr, that won't
trigger the error. So something like:
doveadm fetch -u user text
On 11/30/2010 8:09 PM, Daniel L. Miller wrote:
Continuing to see errors on this with some new messages. Is it
possible this has anything to do with zlib plugin, or possibly having
a mix of zlib compressed uncompressed messages with mdbox? I
recently added zlib to deliver plugin list.
I
On 12/1/2010 10:49 AM, Daniel L. Miller wrote:
On 11/30/2010 8:09 PM, Daniel L. Miller wrote:
Continuing to see errors on this with some new messages. Is it
possible this has anything to do with zlib plugin, or possibly having
a mix of zlib compressed uncompressed messages with mdbox? I
Continuing to see errors on this with some new messages. Is it possible
this has anything to do with zlib plugin, or possibly having a mix of
zlib compressed uncompressed messages with mdbox? I recently added
zlib to deliver plugin list.
--
Daniel L. Miller, VP - Engineering, SET
AM Fire
On Thu, 2010-11-04 at 14:01 +, Timo Sirainen wrote:
On Wed, 2010-11-03 at 19:17 -0700, Daniel L. Miller wrote:
Nov 3 16:08:00 bubba dovecot: imap(dmil...@amfes.com): Error:
Attachment file
On Thu, 2010-11-04 at 14:02 +, Timo Sirainen wrote:
Nov 3 16:08:00 bubba dovecot: imap(dmil...@amfes.com): Error:
Attachment file
/var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c58743bc41c5f
size mismatch: 122626 != 165655
OK,
On 11/4/2010 7:08 AM, Timo Sirainen wrote:
On Thu, 2010-11-04 at 14:02 +, Timo Sirainen wrote:
Nov 3 16:08:00 bubba dovecot: imap(dmil...@amfes.com): Error: Attachment file
/var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c58743bc41c5f
size
Came across this in the logs...
Nov 3 16:08:00 bubba dovecot: imap(dmil...@amfes.com): Error:
Attachment file
/var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c58743bc41c5f
size mismatch: 122626 != 165655
There's about a dozen different file entries
On 4.11.2010, at 2.09, Daniel L. Miller wrote:
Nov 3 16:08:00 bubba dovecot: imap(dmil...@amfes.com): Error: Attachment
file
/var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c58743bc41c5f
size mismatch: 122626 != 165655
What's the file's size? What
On 11/3/2010 7:13 PM, Timo Sirainen wrote:
On 4.11.2010, at 2.09, Daniel L. Miller wrote:
Nov 3 16:08:00 bubba dovecot: imap(dmil...@amfes.com): Error: Attachment file
/var/mail/attachments/dc/73/dc7398c85dd02efe8a14fe6cc019b2cf07eec600-d5ca962aaae7d14c58743bc41c5f
size mismatch: 122626
On Wed, 2010-09-15 at 22:16 -0700, Daniel L. Miller wrote:
Is SIS for dbox included in the 2.0.2 sources? Or only via Mercurial?
Only in hg. Maybe I'll put it to 2.0.3 or 2.0.4.
Is SIS for dbox included in the 2.0.2 sources? Or only via Mercurial?
--
Daniel
When might deduplication of attachments work with maildir?
On Fri, 2010-09-03 at 12:07 -0500, Mike Abbott wrote:
When might deduplication of attachments work with maildir?
I was planning on never. :) But here's a quick design idea:
- Save normal mail data without attachments, similar to dbox
- In maildir filename keep S= and W= the same as if the
On Fri, 2010-09-03 at 18:17 +0100, Timo Sirainen wrote:
Hmm. This reminds me, it might be nice to be able to copy messages with
attachments in sdbox without temporarily duplicating the attachment..
Oh, it does, because it normally copies with hard links.
What would be involved in implementing SIS within Dovecot? A new or
modified mailbox format?
--
Daniel
On Fri, 2009-08-14 at 11:28 -0700, Daniel L. Miller wrote:
What would be involved in implementing SIS within Dovecot? A new or
modified mailbox format?
It could be added to dbox without too much trouble. I already kind of
planned for it:
/* Pointer to external message data. Format
Timo Sirainen wrote:
On Fri, 2009-08-14 at 11:28 -0700, Daniel L. Miller wrote:
What would be involved in implementing SIS within Dovecot? A new or
modified mailbox format?
It could be added to dbox without too much trouble. I already kind of
planned for it:
/* Pointer to
Quoting Timo Sirainen t...@iki.fi:
1) When writing the data, extract the attachments and write them to
different files. Add pointers to those files to the EXT_REF metadata.
Dovecot's message parsers should make this not-too-difficult to
implement.
I'd rather it did mime parts, rather than
On Fri, 2009-08-14 at 12:06 -0700, Daniel L. Miller wrote:
Now do we need to implement some kind of external database for tracking
the attachments between mailboxes? Any thoughts on what that should
look like?
I think:
Step 1) Calculate SHA256 of the attachment and get base64 sum of it.
On Fri, 2009-08-14 at 14:18 -0500, Eric Jon Rostetter wrote:
Quoting Timo Sirainen t...@iki.fi:
1) When writing the data, extract the attachments and write them to
different files. Add pointers to those files to the EXT_REF metadata.
Dovecot's message parsers should make this
Hard links would be the simplest implementation without needing a
separate database. Sure you could implement that too if you wanted to.
It would be worth checking the limits for hard links, and making sure they
are suitable for a large mail system using this scheme, without having a
fallback
On Fri, 2009-08-14 at 12:40 -0700, Jason Fesler wrote:
Hard links would be the simplest implementation without needing a
separate database. Sure you could implement that too if you wanted to.
It would be worth checking the limits for hard links, and making sure they
are suitable for a
Step 4) Figure out if base64-encoded attachments can be decoded in a way
that allows re-encoding them back to the exact original encoding. If so,
save the attachment decoded and add the necessary encoding info the dbox
metadata.
Or perhaps just store them compressed. How much of a difference is
On Fri, 2009-08-14 at 13:54 -0700, Daniel L. Miller wrote:
Timo Sirainen wrote:
Step 4) Figure out if base64-encoded attachments can be decoded in a way
that allows re-encoding them back to the exact original encoding. If so,
save the attachment decoded and add the necessary encoding info
Timo Sirainen wrote:
Step 4) Figure out if base64-encoded attachments can be decoded in a way
that allows re-encoding them back to the exact original encoding. If so,
save the attachment decoded and add the necessary encoding info the dbox
metadata.
Or perhaps just store them compressed. How
On 8/14/2009, Timo Sirainen (t...@iki.fi) wrote:
Hard links would be the simplest implementation without needing a
separate database. Sure you could implement that too if you wanted to.
So... support hard links natively (on FS that support them), then allow
for supporting other backend storage
On Fri, 2009-08-14 at 17:06 -0400, Charles Marcus wrote:
On 8/14/2009, Timo Sirainen (t...@iki.fi) wrote:
Hard links would be the simplest implementation without needing a
separate database. Sure you could implement that too if you wanted to.
So... support hard links natively (on FS that
Step 4) Figure out if base64-encoded attachments can be decoded in a way
that allows re-encoding them back to the exact original encoding. If so,
save the attachment decoded and add the necessary encoding info the dbox
metadata.
Although you might like to do that for some sort of tidiness
On Aug 14, 2009, at 7:15 PM, WJCarpenter wrote:
Step 4) Figure out if base64-encoded attachments can be decoded in
a way
that allows re-encoding them back to the exact original encoding.
If so,
save the attachment decoded and add the necessary encoding info the
dbox
metadata.
I was thinking things like: upper vs. lowercase characters, different
line wrapping lengths, possibly some other weird stuff.. I'd think
that all digital signatures break if any of those change? Or do they
really parse the headers and do calculate the signatures using the
decoded base64?
On Aug 14, 2009, at 8:39 PM, WJCarpenter wrote:
These days, standardized digitial signature schemes take into
account legal transformations that can happen during message
transmission. Most of them have a canonicalization formula so that
things still work. However, in early days, various
66 matches
Mail list logo
