[Dovecot] Disk Encryption

[Simon Brereton]

Hi

As I understand it email headers need to be unencrypted (otherwise
DKIM doesn't work). From the MUA to either Postfix, or Dovecot the
connection is (or can/should be) secured with TLS/SSL.

What I would like to know is if it is possible to encrypt the
mailstore? Postfix is using Dovecot for delivery so it's only Dovecot
that would need to encrypt/decrypt the mailstore.

Is this possible? Is there a terrible reason to do it even if it is possible?

I realise that from MTA to MTA there's no guarantee of encryption (and
in fact it's very unlikely unless keys have been exchanged), but my
primary goal is supplement the physical security of the mail store of
mails we already have or have sent.

Mostly just idle curiosity as to what has been done, or what could be
done. What is worth doing is a separate thread entirely.

Thanks.

Simon

[Robert Schetterer]

This post might be inappropriate. Click to display it.

[Simon Brereton]

Post by Robert Schetterer

Post by Simon Brereton
Hi
As I understand it email headers need to be unencrypted (otherwise
DKIM doesn't work). From the MUA to either Postfix, or Dovecot the
connection is (or can/should be) secured with TLS/SSL.
What I would like to know is if it is possible to encrypt the
mailstore? Postfix is using Dovecot for delivery so it's only Dovecot
that would need to encrypt/decrypt the mailstore.
Is this possible? Is there a terrible reason to do it even if it is possible?
I realise that from MTA to MTA there's no guarantee of encryption (and
in fact it's very unlikely unless keys have been exchanged), but my
primary goal is supplement the physical security of the mail store of
mails we already have or have sent.
Mostly just idle curiosity as to what has been done, or what could be
done. What is worth doing is a separate thread entirely.
Thanks.
Simon

my meaning
crypted mailstore makes sense in a mail archive, in germany
you have to have a mail archive for some kind of company emails
all these solutions have some crypted mailstore , and some
more features for data security, but thats a big theme, to big for here
crypt storage isnt "the saveness" per default, someone hacking the system
and get root may hack your crypt storage too etc, also to big theme for here

Robert, indeed, this is sort of my point. If we encrypt laptop
harddrives to prevent unauthorised access, that doesn't prevent the
possiblity of someone who already has admin access to the device from
decrypting/viewing/moving files. What it does do is prevent
unauthorised access to the data if there is no admin access.

Currently my mail store isn't encrypted and I would like to know if it
is possible to do that, and if so, maybe get some pointers.

Simon

[Reindl Harald]

Post by Simon Brereton

Post by Robert Schetterer
crypt storage isnt "the saveness" per default, someone hacking the system
and get root may hack your crypt storage too etc, also to big theme for here

Robert, indeed, this is sort of my point. If we encrypt laptop
harddrives to prevent unauthorised access, that doesn't prevent the
possiblity of someone who already has admin access to the device from
decrypting/viewing/moving files. What it does do is prevent
unauthorised access to the data if there is no admin access.
Currently my mail store isn't encrypted and I would like to know if it
is possible to do that, and if so, maybe get some pointers

this is independent of the used software and transparent
http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20130325/06d85b06/attachment-0001.bin>

[Gordon Grubert]

Dear list,

we're using dovecot 2.1.15 (debian binary package). The following
error can be found in the mail log files:

Mar 25 15:08:46 mailserver2 dovecot: imap-login: Login: user=<USER>,
method=PLAIN, rip=IP, lip=IP, mpid=28663, TLS, session=<In7mV8DYFQCNNQQ4>
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Cached message
size smaller than expected (2252 < 4821)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Maildir filename
has wrong S value, renamed the file from
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
to
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Corrupted index
cache file
/var/vmail/uni-greifswald.de/USER/Maildir/dovecot.index.cache: Broken
physical size for mail UID 25250
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Cached message
size smaller than expected (2252 < 4821)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Maildir filename
has wrong S value, renamed the file from
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
to
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Corrupted index
cache file
/var/vmail/uni-greifswald.de/USER/Maildir/dovecot.index.cache: Broken
physical size for mail UID 25250
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error:
read(/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS)
failed: Input/output error (FETCH for mailbox INBOX UID 25250)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Disconnected: Internal
error occurred. Refer to server log for more information. [2013-03-25
15:08:46] in=246 out=953

The same problem was reported by Ralf Hildebrandt one year ago. The bug
should be fixed with revision 3599790da3d7 but it seems to be there
again.

Input/output errors of the file system are improbable because all
files are accessible and can be read with cat and less.

Any ideas?

Best regards,
Gordon
--
Leiter AG Technische Infrastruktur und Basisdienste
Universitaetsrechenzentrum (URZ)
E.-M.-Arndt-Universitaet Greifswald
Felix-Hausdorff-Str. 12
17489 Greifswald
Germany

Tel. [phone]
Fax. [phone]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20130325/1a37fe96/attachment.bin>

[Robert Schetterer]

Post by Gordon Grubert
Dear list,
we're using dovecot 2.1.15 (debian binary package). The following
Mar 25 15:08:46 mailserver2 dovecot: imap-login: Login: user=<USER>,
method=PLAIN, rip=IP, lip=IP, mpid=28663, TLS, session=<In7mV8DYFQCNNQQ4>
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Cached message
size smaller than expected (2252 < 4821)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Maildir filename
has wrong S value, renamed the file from
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
to
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Corrupted index
cache file
/var/vmail/uni-greifswald.de/USER/Maildir/dovecot.index.cache: Broken
physical size for mail UID 25250
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Cached message
size smaller than expected (2252 < 4821)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Maildir filename
has wrong S value, renamed the file from
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
to
/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Corrupted index
cache file
/var/vmail/uni-greifswald.de/USER/Maildir/dovecot.index.cache: Broken
physical size for mail UID 25250
read(/var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS)
failed: Input/output error (FETCH for mailbox INBOX UID 25250)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Disconnected: Internal
error occurred. Refer to server log for more information. [2013-03-25
15:08:46] in=246 out=953
The same problem was reported by Ralf Hildebrandt one year ago. The bug
should be fixed with revision 3599790da3d7 but it seems to be there
again.
Input/output errors of the file system are improbable because all
files are accessible and can be read with cat and less.
Any ideas?
Best regards,
Gordon

please reread the list archive ,solutions where massive posted
and a new repair script was created

Best Regards
MfG Robert Schetterer

[Peer Heinlein]

Post by Robert Schetterer
please reread the list archive ,solutions where massive posted
and a new repair script was created

We did that before, for sure.

But there are NO working solutions for that and the problem still exists
and ist a massive problem, because a simple version upgrade doesn't work
and leads to a DOS of the infected systems.

The repair script hasn't worked at all with our kind of Maildir-Filenames.

If others run into the same problem:

We used this simple piece of code (which is much easier to read and adapt):

for FILE in * ; do
OLDNAME=$FILE
SIZE=`zcat $FILE | wc -c`
NEWNAME=`echo $FILE | sed "s/\(.*\)S=.*:\(.*\)/\1S=$SIZE:\2/g"`

if [ ! $OLDNAME = $NEWNAME ] ; then
echo mv "$OLDNAME" "$NEWNAME"
fi
done


Peer
--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin

[Robert Schetterer]

Post by Peer Heinlein

Post by Robert Schetterer
please reread the list archive ,solutions where massive posted
and a new repair script was created

We did that before, for sure.
But there are NO working solutions for that and the problem still exists
and ist a massive problem, because a simple version upgrade doesn't work
and leads to a DOS of the infected systems.
The repair script hasn't worked at all with our kind of Maildir-Filenames.
for FILE in * ; do
OLDNAME=$FILE
SIZE=`zcat $FILE | wc -c`
NEWNAME=`echo $FILE | sed "s/\(.*\)S=.*:\(.*\)/\1S=$SIZE:\2/g"`
if [ ! $OLDNAME = $NEWNAME ] ; then
echo mv "$OLDNAME" "$NEWNAME"
fi
done
Peer

Hi Peer , as talked to Gordon, this was a total upgrade from 2.0.x to
2.1.x and you converted all maildir to compressed before, right ?
posting some conf parameters might be helpfull , did you investigated
broken maildirs for mixing compressed and uncompressed mails exist, as i
understand Gordon there should be only compressed ? Have you checked
about double compressed mails in broken maildirs ?

As wrote before, at my bug time after repair with script and upgrading
dovecot, failures had gone and never returned, but my setup may be
different from yours and failure did happend sometime upgrade dove 2.1.x
not at migrate from dove 2.0.x, did you changed something other too ?




Best Regards
MfG Robert Schetterer

[Timo Sirainen]

Mar 25 15:08:46 mailserver2 dovecot: imap-login: Login: user=<USER>, method=PLAIN, rip=IP, lip=IP, mpid=28663, TLS, session=<In7mV8DYFQCNNQQ4>
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Cached message size smaller than expected (2252 < 4821)
Mar 25 15:08:46 mailserver2 dovecot: imap(USER): Error: Maildir filename has wrong S value, renamed the file from /var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS to /var/vmail/uni-greifswald.de/USER/Maildir/cur/1169635911.30322.scooby,S=2252:2,RS

..

The same problem was reported by Ralf Hildebrandt one year ago. The bug
should be fixed with revision 3599790da3d7 but it seems to be there
again.

The Dovecot bug was fixed, but the real reason for this is that the S=values are wrong in your maildir. You can either run the fixing script or set maildir_broken_filename_sizes=yes.

Input/output errors of the file system are improbable because all
files are accessible and can be read with cat and less.

That's just Dovecot's internal way of passing a failure to other parts of the code.

[Peer Heinlein]

Am 25.03.2013 15:38, schrieb Timo Sirainen:



Hi,

Post by Timo Sirainen

Post by Gordon Grubert
The same problem was reported by Ralf Hildebrandt one year ago. The bug
should be fixed with revision 3599790da3d7 but it seems to be there
again.

The Dovecot bug was fixed, but the real reason for this is that the S=values are wrong in your maildir. You can either run the fixing script or set maildir_broken_filename_sizes=yes.

Looks like this (or a related) bug still exist.

If you have a Maildir-Storage with gzip compression enabled,
everything's working fine if the user receives mail by LMTP. The mail is
saved in his Maildir-Storage, having the right (uncompressed) size in
the filename.

vmail vmail 1.9K Mar 26 22:17
1364332643.M527513P23361.mailserver2,S=3780,W=3860:2

But:

If the dovecot.index is broken, corrupt or deleted, Dovecot isn't able
to rebuild his index-files.

In Step ONE dovecot creates his index-files, but looks like Dovecot's
using the (smaller) FILEsize instead of the (larger) real size.

In Step TWO Dovecot's realizing that the cached size and the stored file
size in the filename doesn't fit together. But Dovecot doesn't fix his
index file; instead Dovecot's renaming the Maildir-Files, storing the
(small) file size in the filename.

Mar 26 22:39:17 mailserver2 dovecot: imap(testuser): Error: Cached
message size smaller than expe
cted (1467 < 3780)

Error: Maildir filename has wrong S value, r
enamed the file from
/var/vmail/uni-greifswald.de/testuser/Maildir/cur/1364332643.M527513P23361.m
ailserver2,S=3780,W=3860:2, to
/var/vmail/uni-greifswald.de/testuser/Maildir/cur/1364332643.M5275
13P23361.mailserver2,S=1856:2,


HOW TO REPRODUCE:

*) Create a Maildir-Store with zip enabled
*) Deliver Mails into it. Everything's working fine, the filenames are right
*) Delete dovecot.index*
*) STEP ONE: Dovecot's complaining about broken index-files
*) STEP TWO: Dovecot's renaming the files

I haven't seen any way to find to workaround or repair this broken
Maildir-Storage. Even if I rename all files and set sizes in the
filenames, Dovecot's complaining about the mismatch in his cache and
starts his (broken) repair action.

If we're right, this could be grow to a real problem. Every Server with
zipped Maildirs can be completly ruined just by deleting his
index-cache-files.


Peer
--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin

[Peer Heinlein]

Post by Peer Heinlein
If we're right, this could be grow to a real problem. Every Server with
zipped Maildirs can be completly ruined just by deleting his
index-cache-files.

More and more users complained this morning about broken mailboxes and
our logfile was full of errors.

We made a simple downgrade to 2.0.21 and now everything's working perfect.

Peer
--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin

[Timo Sirainen]

Post by Peer Heinlein

Post by Peer Heinlein
If we're right, this could be grow to a real problem. Every Server with
zipped Maildirs can be completly ruined just by deleting his
index-cache-files.

More and more users complained this morning about broken mailboxes and
our logfile was full of errors.
We made a simple downgrade to 2.0.21 and now everything's working perfect.

maildir_broken_file_sizes=yes would also bring back v2.0 behavior. But yeah, looks like there's a bug.

[Gordon Grubert]

Post by Timo Sirainen

Post by Peer Heinlein

Post by Peer Heinlein
If we're right, this could be grow to a real problem. Every Server with
zipped Maildirs can be completly ruined just by deleting his
index-cache-files.

More and more users complained this morning about broken mailboxes and
our logfile was full of errors.
We made a simple downgrade to 2.0.21 and now everything's working perfect.

maildir_broken_file_sizes=yes would also bring back v2.0 behavior. But yeah, looks like there's a bug.

No, it does not.

Best regards,
Gordon


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20130327/4dc2e20e/attachment-0001.bin>

[Robert Schetterer]

Post by Gordon Grubert

Post by Timo Sirainen

Post by Peer Heinlein

Post by Peer Heinlein
If we're right, this could be grow to a real problem. Every Server with
zipped Maildirs can be completly ruined just by deleting his
index-cache-files.

More and more users complained this morning about broken mailboxes and
our logfile was full of errors.
We made a simple downgrade to 2.0.21 and now everything's working perfect.

maildir_broken_file_sizes=yes would also bring back v2.0 behavior. But
yeah, looks like there's a bug.

No, it does not.
Best regards,
Gordon

agree, when i first run at that problem
maildir_broken_file_sizes=yes didnt fixed it, i had to repair maildirs
manual by script, upgraded dovecot 2.1.x to newer version, that problem
never came back again, just for interest what dovecot source did you
use, did you you compile modifications by your own ?





Best Regards
MfG Robert Schetterer

[Gordon Grubert]

Post by Robert Schetterer
agree, when i first run at that problem
maildir_broken_file_sizes=yes didnt fixed it, i had to repair maildirs
manual by script, upgraded dovecot 2.1.x to newer version, that problem
never came back again, just for interest what dovecot source did you
use, did you you compile modifications by your own ?

I used the debian binary package for dovecot 2.1.15 from
xi.rename-it.nl

Best regards,
Gordon

[Robert Schetterer]

Post by Gordon Grubert

Post by Robert Schetterer
agree, when i first run at that problem
maildir_broken_file_sizes=yes didnt fixed it, i had to repair maildirs
manual by script, upgraded dovecot 2.1.x to newer version, that problem
never came back again, just for interest what dovecot source did you
use, did you you compile modifications by your own ?

I used the debian binary package for dovecot 2.1.15 from
xi.rename-it.nl

did you changed anything in your config too, using or changing other
features too , while upgrade ?
Did you modifications to the sources ( debian rules etc ) and recompile
i.e integrate lucene etc ?

Post by Gordon Grubert
Best regards,
Gordon

Best Regards
MfG Robert Schetterer

[Peer Heinlein]

Post by Gordon Grubert

Post by Timo Sirainen

Post by Peer Heinlein
We made a simple downgrade to 2.0.21 and now everything's working perfect.

maildir_broken_file_sizes=yes would also bring back v2.0 behavior. But
yeah, looks like there's a bug.

No, it does not.

In Timo's first mail he wrote maildir_broken_fileNAME_sizes and we used
that (which didn't helped at all).

mailserver2:~/dovecot.neu.2-1# grep -r maildir_broken *
conf.d/10-mail.conf:maildir_broken_filename_sizes = yes
mailserver2:~/dovecot.neu.2-1#


But maybe it's working with "maildir_broken_file_sizes" :-), we can
test that on our test-system.

Peer
--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin

[Timo Sirainen]

Post by Peer Heinlein
Mar 26 22:39:17 mailserver2 dovecot: imap(testuser): Error: Cached
message size smaller than expe
cted (1467 < 3780)
Error: Maildir filename has wrong S value, r
enamed the file from
/var/vmail/uni-greifswald.de/testuser/Maildir/cur/1364332643.M527513P23361.m
ailserver2,S=3780,W=3860:2, to
/var/vmail/uni-greifswald.de/testuser/Maildir/cur/1364332643.M5275
13P23361.mailserver2,S=1856:2,
*) Create a Maildir-Store with zip enabled
*) Deliver Mails into it. Everything's working fine, the filenames are right
*) Delete dovecot.index*
*) STEP ONE: Dovecot's complaining about broken index-files
*) STEP TWO: Dovecot's renaming the files

Oh, except I actually forgot to load zlib plugin in my previous test. I can't reproduce with these steps.. and I don't really see why they would cause it anyway. A broken cached size would cause that rename, but not a missing cached size.

[Robert Schetterer]

Post by Timo Sirainen

Post by Peer Heinlein
Mar 26 22:39:17 mailserver2 dovecot: imap(testuser): Error: Cached
message size smaller than expe
cted (1467 < 3780)
Error: Maildir filename has wrong S value, r
enamed the file from
/var/vmail/uni-greifswald.de/testuser/Maildir/cur/1364332643.M527513P23361.m
ailserver2,S=3780,W=3860:2, to
/var/vmail/uni-greifswald.de/testuser/Maildir/cur/1364332643.M5275
13P23361.mailserver2,S=1856:2,
*) Create a Maildir-Store with zip enabled

guess you mean zlib ?

Post by Timo Sirainen

Post by Peer Heinlein
*) Deliver Mails into it. Everything's working fine, the filenames are right
*) Delete dovecot.index*

in fact i did this 2 weeks ago , no errors came up with 2.1.15,
maildirs/mailboxes got work again

Post by Timo Sirainen

Post by Peer Heinlein
*) STEP ONE: Dovecot's complaining about broken index-files
*) STEP TWO: Dovecot's renaming the files

Oh, except I actually forgot to load zlib plugin in my previous test. I can't reproduce with these steps.. and I don't really see why they would cause it anyway. A broken cached size would cause that rename, but not a missing cached size.

my problem was ,i couldnt find out why i needed to delete index* to get
2 Mailboxes work again,for more magic, no problem in the logs and
mailboxes worked in thunderbird linux but not in thunderbird windows (
clean new setups ),i speculated to some problem with massive pop3 and
imap in parallel from different ip at same time to the same mailbox
via loadbalancers crashing something, but sadly couldnt reproduce it yet

Best Regards
MfG Robert Schetterer

[Peer Heinlein]

Post by Timo Sirainen
Oh, except I actually forgot to load zlib plugin in my previous test.

I can't reproduce with these steps.. and I don't really see why they
would cause it anyway. A broken cached size would cause that rename, but
not a missing cached size.

Thats why I wrote from STEP ONE and from STEP TWO.

I had the impression, that Dovecot first rebuilds his cache with WRONG
sizes and THEN starts in step two the renaming.

Peer
--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin

[Timo Sirainen]

Post by Timo Sirainen

Post by Timo Sirainen
Oh, except I actually forgot to load zlib plugin in my previous test.

I can't reproduce with these steps.. and I don't really see why they
would cause it anyway. A broken cached size would cause that rename, but
not a missing cached size.
Thats why I wrote from STEP ONE and from STEP TWO.
I had the impression, that Dovecot first rebuilds his cache with WRONG
sizes and THEN starts in step two the renaming.

Well, the question is then.. Why were the corrupted in the first place? Based on your previous error message it looked like the cache file contained the compressed size, so maybe zlib plugin wasn't loaded for some Dovecot process at that time?

Anyway, yeah, I guess there are two potential improvements here: Either a) don't rename maildir file if S=size is different from cached size or b) rename the S=size to the correct decompressed size (=no renaming if it's correct). Not sure which one is easier to do, possibly b) and possibly it should be done anyway.

In any case, I think this is a good addition: http://hg.dovecot.org/dovecot-2.2/rev/6d9444ea1c9a

[Peer Heinlein]

Am 27.03.2013 20:10, schrieb Timo Sirainen:

Hi,

Post by Timo Sirainen
Well, the question is then.. Why were the corrupted in the first place? Based on your previous error message it looked like the cache file contained the compressed size, so maybe zlib plugin wasn't loaded for some Dovecot process at that time?

AFAIK zlib is always on:

mailserver2:~# doveconf | grep plugins
mail_plugins = quota acl mail_log notify zlib
mail_plugins = quota acl mail_log notify zlib sieve
mail_plugins = quota acl mail_log notify zlib imap_quota imap_acl
mail_plugins = quota acl mail_log notify zlib


I'll try to create and send you a test-case with an infected maildir.

Peer
--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. ?35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Gesch?ftsf?hrer: Peer Heinlein -- Sitz: Berlin

[Gordon Grubert]

Hi,

in our case, the problem is solved since dovecot 2.2.13.

Best regards,
Gordon

[Xin Li]

Post by Simon Brereton

Post by Robert Schetterer

Post by Simon Brereton
Hi
As I understand it email headers need to be unencrypted
(otherwise DKIM doesn't work). From the MUA to either Postfix,
or Dovecot the connection is (or can/should be) secured with
TLS/SSL.
What I would like to know is if it is possible to encrypt the
mailstore? Postfix is using Dovecot for delivery so it's only
Dovecot that would need to encrypt/decrypt the mailstore.
Is this possible? Is there a terrible reason to do it even if it is possible?
I realise that from MTA to MTA there's no guarantee of
encryption (and in fact it's very unlikely unless keys have
been exchanged), but my primary goal is supplement the physical
security of the mail store of mails we already have or have
sent.
Mostly just idle curiosity as to what has been done, or what
could be done. What is worth doing is a separate thread
entirely.
Thanks.
Simon

my meaning
crypted mailstore makes sense in a mail archive, in germany you
have to have a mail archive for some kind of company emails all
these solutions have some crypted mailstore , and some more
features for data security, but thats a big theme, to big for
here
crypt storage isnt "the saveness" per default, someone hacking
the system and get root may hack your crypt storage too etc, also
to big theme for here

Robert, indeed, this is sort of my point. If we encrypt laptop
harddrives to prevent unauthorised access, that doesn't prevent
the possiblity of someone who already has admin access to the
device from decrypting/viewing/moving files. What it does do is
prevent unauthorised access to the data if there is no admin
access.
Currently my mail store isn't encrypted and I would like to know if
it is possible to do that, and if so, maybe get some pointers.

Let's say you operate a mail server which uses a RAID array (or ZFS
pool) as backend storage and one day one disks goes bad and needs to
be replaced. You don't want information being leak from that bad disk
when returning to vendor for replacement.

There are a lot of solutions to this issue. One possible way is to
use FreeBSD's full disk encryption, geli(4), to encrypt all hard
drives and have the email server hold the key on its boot partition,
but don't protect it with a password so that the mail server can boot
without any human intervention.

Encrypting individual user's mail store make little sense as one can
still get your decryption key if they got root privilege, usually by
tracing the login process or just replace it with something that can
do the login but also save login credentials. In short, if root have
been compromised, it's game over already.

Cheers,

[Daniel Reinhardt]

If you are concerned about data being left on a hard drive when it fails
and you are returning it to vendor, then I would consider hard drive
degaussers. They are effective, but are very costly.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Simon Brereton

Post by Robert Schetterer

Post by Simon Brereton
Hi
As I understand it email headers need to be unencrypted
(otherwise DKIM doesn't work). From the MUA to either Postfix,
or Dovecot the connection is (or can/should be) secured with
TLS/SSL.
What I would like to know is if it is possible to encrypt the
mailstore? Postfix is using Dovecot for delivery so it's only
Dovecot that would need to encrypt/decrypt the mailstore.
Is this possible? Is there a terrible reason to do it even if it is possible?
I realise that from MTA to MTA there's no guarantee of
encryption (and in fact it's very unlikely unless keys have
been exchanged), but my primary goal is supplement the physical
security of the mail store of mails we already have or have
sent.
Mostly just idle curiosity as to what has been done, or what
could be done. What is worth doing is a separate thread
entirely.
Thanks.
Simon

my meaning
crypted mailstore makes sense in a mail archive, in germany you
have to have a mail archive for some kind of company emails all
these solutions have some crypted mailstore , and some more
features for data security, but thats a big theme, to big for
here
crypt storage isnt "the saveness" per default, someone hacking
the system and get root may hack your crypt storage too etc, also
to big theme for here

Robert, indeed, this is sort of my point. If we encrypt laptop
harddrives to prevent unauthorised access, that doesn't prevent
the possiblity of someone who already has admin access to the
device from decrypting/viewing/moving files. What it does do is
prevent unauthorised access to the data if there is no admin
access.
Currently my mail store isn't encrypted and I would like to know if
it is possible to do that, and if so, maybe get some pointers.

Let's say you operate a mail server which uses a RAID array (or ZFS
pool) as backend storage and one day one disks goes bad and needs to
be replaced. You don't want information being leak from that bad disk
when returning to vendor for replacement.
There are a lot of solutions to this issue. One possible way is to
use FreeBSD's full disk encryption, geli(4), to encrypt all hard
drives and have the email server hold the key on its boot partition,
but don't protect it with a password so that the mail server can boot
without any human intervention.
Encrypting individual user's mail store make little sense as one can
still get your decryption key if they got root privilege, usually by
tracing the login process or just replace it with something that can
do the login but also save login credentials. In short, if root have
been compromised, it's game over already.
Cheers,
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJRUndLAAoJEG80Jeu8UPuzyyMIAJ22uv8U2OlZFFAUWTDL4zu/
tw6ZhxqQxhHVsg69kQPmIRVnMvlv0bhRqQphaJl5PQJAnfiwvrulx8ruFfTWIM3W
xyxKMQtY/pJouRJwz1SZsfuuBNjU+ACX17IXIi5NDkLm8IT1FLgS9fWaYotACIUe
5fTXgodDDAGrWoYE4X1WTJiYCEE4UisilExaAJ0quk72NO/TzMnsLktR7mx0eSaP
NqAi8ger9a2rflStgdJlI6pCmzRs4onAs2YWZq4F5Nv/wnnUysMsSjwNW+MuL4WY
jWbX8oF+11kyH14vPLvzLKvMXjC9yKf8G880OPuMmgFQOrYAXzP5yp3w/rRVBCM=
=SMvV
-----END PGP SIGNATURE-----

[Charles Marcus]

Did anyone else get 13 identical copies of this response from Daniel???

Post by Daniel Reinhardt
If you are concerned about data being left on a hard drive when it fails
and you are returning it to vendor, then I would consider hard drive
degaussers. They are effective, but are very costly.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Simon Brereton

Post by Robert Schetterer

Post by Simon Brereton
Hi
As I understand it email headers need to be unencrypted
(otherwise DKIM doesn't work). From the MUA to either Postfix,
or Dovecot the connection is (or can/should be) secured with
TLS/SSL.
What I would like to know is if it is possible to encrypt the
mailstore? Postfix is using Dovecot for delivery so it's only
Dovecot that would need to encrypt/decrypt the mailstore.
Is this possible? Is there a terrible reason to do it even if it is possible?
I realise that from MTA to MTA there's no guarantee of
encryption (and in fact it's very unlikely unless keys have
been exchanged), but my primary goal is supplement the physical
security of the mail store of mails we already have or have
sent.
Mostly just idle curiosity as to what has been done, or what
could be done. What is worth doing is a separate thread
entirely.
Thanks.
Simon

my meaning
crypted mailstore makes sense in a mail archive, in germany you
have to have a mail archive for some kind of company emails all
these solutions have some crypted mailstore , and some more
features for data security, but thats a big theme, to big for
here
crypt storage isnt "the saveness" per default, someone hacking
the system and get root may hack your crypt storage too etc, also
to big theme for here

Robert, indeed, this is sort of my point. If we encrypt laptop
harddrives to prevent unauthorised access, that doesn't prevent
the possiblity of someone who already has admin access to the
device from decrypting/viewing/moving files. What it does do is
prevent unauthorised access to the data if there is no admin
access.
Currently my mail store isn't encrypted and I would like to know if
it is possible to do that, and if so, maybe get some pointers.

Let's say you operate a mail server which uses a RAID array (or ZFS
pool) as backend storage and one day one disks goes bad and needs to
be replaced. You don't want information being leak from that bad disk
when returning to vendor for replacement.
There are a lot of solutions to this issue. One possible way is to
use FreeBSD's full disk encryption, geli(4), to encrypt all hard
drives and have the email server hold the key on its boot partition,
but don't protect it with a password so that the mail server can boot
without any human intervention.
Encrypting individual user's mail store make little sense as one can
still get your decryption key if they got root privilege, usually by
tracing the login process or just replace it with something that can
do the login but also save login credentials. In short, if root have
been compromised, it's game over already.
Cheers,
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJRUndLAAoJEG80Jeu8UPuzyyMIAJ22uv8U2OlZFFAUWTDL4zu/
tw6ZhxqQxhHVsg69kQPmIRVnMvlv0bhRqQphaJl5PQJAnfiwvrulx8ruFfTWIM3W
xyxKMQtY/pJouRJwz1SZsfuuBNjU+ACX17IXIi5NDkLm8IT1FLgS9fWaYotACIUe
5fTXgodDDAGrWoYE4X1WTJiYCEE4UisilExaAJ0quk72NO/TzMnsLktR7mx0eSaP
NqAi8ger9a2rflStgdJlI6pCmzRs4onAs2YWZq4F5Nv/wnnUysMsSjwNW+MuL4WY
jWbX8oF+11kyH14vPLvzLKvMXjC9yKf8G880OPuMmgFQOrYAXzP5yp3w/rRVBCM=
=SMvV
-----END PGP SIGNATURE-----

[Noel Butler]

nope

Post by Charles Marcus
Did anyone else get 13 identical copies of this response from Daniel???

Post by Daniel Reinhardt
If you are concerned about data being left on a hard drive when it fails
and you are returning it to vendor, then I would consider hard drive
degaussers. They are effective, but are very costly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20130328/035018db/attachment.bin>

[Simon Brereton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Simon Brereton

Post by Robert Schetterer

Post by Simon Brereton
Hi
As I understand it email headers need to be unencrypted
(otherwise DKIM doesn't work). From the MUA to either Postfix,
or Dovecot the connection is (or can/should be) secured with
TLS/SSL.
What I would like to know is if it is possible to encrypt the
mailstore? Postfix is using Dovecot for delivery so it's only
Dovecot that would need to encrypt/decrypt the mailstore.
Is this possible? Is there a terrible reason to do it even if it is possible?
I realise that from MTA to MTA there's no guarantee of
encryption (and in fact it's very unlikely unless keys have
been exchanged), but my primary goal is supplement the physical
security of the mail store of mails we already have or have
sent.
Mostly just idle curiosity as to what has been done, or what
could be done. What is worth doing is a separate thread
entirely.
Thanks.
Simon

my meaning
crypted mailstore makes sense in a mail archive, in germany you
have to have a mail archive for some kind of company emails all
these solutions have some crypted mailstore , and some more
features for data security, but thats a big theme, to big for
here
crypt storage isnt "the saveness" per default, someone hacking
the system and get root may hack your crypt storage too etc, also
to big theme for here

Robert, indeed, this is sort of my point. If we encrypt laptop
harddrives to prevent unauthorised access, that doesn't prevent
the possiblity of someone who already has admin access to the
device from decrypting/viewing/moving files. What it does do is
prevent unauthorised access to the data if there is no admin
access.
Currently my mail store isn't encrypted and I would like to know if
it is possible to do that, and if so, maybe get some pointers.

Let's say you operate a mail server which uses a RAID array (or ZFS
pool) as backend storage and one day one disks goes bad and needs to
be replaced. You don't want information being leak from that bad disk
when returning to vendor for replacement.
There are a lot of solutions to this issue. One possible way is to
use FreeBSD's full disk encryption, geli(4), to encrypt all hard
drives and have the email server hold the key on its boot partition,
but don't protect it with a password so that the mail server can boot
without any human intervention.

Thanks. I think I will investigate this option. I use Debian, and I
think the same approach is possible.

My concern with this approach is that if the drive is booted from then
the information is freely available - but as you say, only if the root
password is known. If the drive is simply mounted in different
system, then the passphrase would be need (this is what I understand).

Alternatively, I could encrypt /var/mail/ and mount it as a LUKS
volume to achieve the same effect. But I need a test plan and
equipment.

Thanks for all the pointers.

Simon

[Jeroen Massar]

[..]

Post by Simon Brereton
Currently my mail store isn't encrypted and I would like to know if
it is possible to do that, and if so, maybe get some pointers.

There are two main roads:

- filesystem/disk based encryption
* Fast and easy to setup though (eg LUKS on Linux)
* does not protect against a running system being attacked, eg
that they can run custom code in the same security level that
thus can read the unencrypted content.

- per-file encryption, eg with PGP/GnuPG
* Likely more complex to setup/fail-prone
* attacker getting access can only encrypt more mail and/or
of course subvert any new mail, but can't decrypt old.
* there are a couple of tools which enable this, typically it is
a procmail/pipe through gnupg
* Decryption of mails can be done with a "IMAP-proxy" style tool
or possibly better/easier by the mail client.
* Check out:
- https://github.com/isislovecruft/leap_mx
- https://grepular.com/Automatically_Encrypting_all_Incoming_Email
-
https://perot.me/encrypt-specific-incoming-emails-using-dovecot-and-sieve

For both:
* Store your decryption keys in a secure/offline place
(cold-boot attacks)
* "Rubber Hose Crypto": http://www.schlockmercenary.com/2006-03-29
* "Lead Pipe Crypto": http://www.schlockmercenary.com/2009-10-19

Of course it always depends on the attack vectors that you are
protecting against ;)

Greets,
Jeroen