[Dovecot] dovecot v-2.0, postfix+mysql configuration issue.

[Vimuth]

Greetings Gentlemen,
Im in the attempt of configuring a postfix mail server on RHEL6.2 with the
said components in the subject. I followed a couple of guides and I beleive
that Im almost there, but I get the following error when I try to send a
mail to a user who is in the mysql database as follows, Dovecot version
that is being used is 2.0.X.

echo test | mail vim...@mydomain.rock

[root@box1 ~]# tail -f /var/log/maillog
Mar 26 07:00:44 box1 dovecot: auth: Error: sql(vim...@mydomain.rock): User
query failed: Table 'mailserver.users' doesn't exist (using built-in
default user_query: SELECT home, uid, gid FROM users WHERE username = '%n'
AND domain = '%d')
Mar 26 07:00:44 box1 dovecot: lda: Error: user vim...@mydomain.rock: Auth
USER lookup failed
Mar 26 07:00:44 box1 dovecot: lda: Fatal: Internal error occurred. Refer to
server log for more information.
Mar 26 07:00:44 box1 postfix/pipe[6291]: A9E0E23B96:
to=, relay=dovecot, delay=14255,
delays=14255/0.02/0/0.12, dsn=4.3.0, status=deferred (temporary failure)
Mar 26 07:05:44 box1 postfix/qmgr[5675]: 2E5AD23B66:
from=, size=421, nrcpt=1 (queue active)
Mar 26 07:05:44 box1 dovecot: auth: Error: mysql: Query failed, retrying:
Table 'mailserver.users' doesn't exist
Mar 26 07:05:44 box1 dovecot: auth: Error: sql(vim...@mydomain.rock): User
query failed: Table 'mailserver.users' doesn't exist (using built-in
default user_query: SELECT home, uid, gid FROM users WHERE username = '%n'
AND domain = '%d')
Mar 26 07:05:44 box1 dovecot: lda: Error: user vim...@mydomain.rock: Auth
USER lookup failed
Mar 26 07:05:44 box1 dovecot: lda: Fatal: Internal error occurred. Refer to
server log for more information.
Mar 26 07:05:44 box1 postfix/pipe[6312]: 2E5AD23B66:
to=, relay=dovecot, delay=16007,
delays=16007/0.03/0/0.08, dsn=4.3.0, status=deferred (temporary failure)

As I understand, this has something to do with the way I have setup my
database. Im gonna post what are in my most important configuration files
and also of course in the database.

here's *"/etc/dovecot/dovecot-sql.conf.ext"*

driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=redhat
default_pass_scheme = MD5
password_query = SELECT email as user, password FROM virtual_users WHERE
email='%u';

here's */etc/postfix/main.cf*

# TLS parameters
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_key_file = /etc/pki/tls/private/smtpd.key
smtpd_tls_cert_file = /etc/pki/tls/smtpd.crt
smtpd_tls_CAfile = /etc/pki/tls/certs/cacert.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

# set smtpd restrictions
smtpd_recipient_restrictions = permit_sasl_authenticated,
   permit_mynetworks,
   reject_unauth_destination
virtual_mailbox_domains = mysql:/etc/postfix/
mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

mailbox_command = /usr/libexec/dovecot/deliver
mailbox_transport = dovecot
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

Now to the *database
*
mysql> show databases;
++
| Database   |
++
| information_schema |
| mail   |
| mailserver |
| mysql  |
++[

mysql> use mailserver;
Database changed
mysql> select * from mailserver;
mysql> show tables;
+--+
| Tables_in_mailserver |
+--+
| virtual_aliases  |
| virtual_domains  |
| virtual_users|
+--+

mysql> select * from virtual_users;
++---+--+--+
| id | domain_id | password | email|
++---+--+--+
|  1 | 1 | e2798af12a7a0f4f70b4d69efbc25f4d | vim...@mydomain.rock |
++---+--+--+
1 row in set (0.00 sec)

Please can someone help. If you need more information please let me know.
I'm ready to tear down the entire implementation and start from the scratch.

Many thanks in advance.
/Vimuth

Re: [Dovecot] Disk Encryption

[Noel Butler]

nope

On Wed, 2013-03-27 at 07:23 -0400, Charles Marcus wrote:

> Did anyone else get 13 identical copies of this response from Daniel???
> 
> On 2013-03-27 12:47 AM, Daniel Reinhardt  wrote:
> > 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.
> >
> >


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Peer Heinlein]

Am 27.03.2013 20:10, schrieb Timo Sirainen:

Hi,

> 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

Re: [Dovecot] Gmail like labels, three years later

[Pablo Vieira]

2013/3/27 Timo Sirainen 

> On 27.3.2013, at 17.28, Pablo Vieira  wrote:
>
> METADATA is simply about adding simple key=value pairs to mailboxes. So
> you could have something like:
>
> /shared/keywords/$Label1 = Important
> /shared/keywords/$Label2 = Work
> /shared/keywords/HelloWorld = Hello World messages
>
> Probably it wouldn't need to be any more complex than that. The clients
> would then handle adding/changing/removing those keywords.
>
> http://tools.ietf.org/html/rfc5464 describes METADATA.
>
> Thanks a lot. Any idea when METADATA will have a full implementation in
Dovecot? Them along with virtual folders might make it easy to build a
Gmail-like system.

Re: [Dovecot] Incorrect response when opening read-only mailboxes with per-user flags?

[Timo Sirainen]

On 27.3.2013, at 22.16, Guido Berhoerster  
wrote:

> * Timo Sirainen  [2013-03-27 20:27]:
>> On 27.3.2013, at 13.41, Guido Berhoerster 
>>  wrote:
>> 
>>> After some debugging on the protocol level I've finally found the
>>> problem with per-user seen flags in read-only mailboxes. Dovecot
>>> actually does allow storing the seen flag on messages but AFAICS
>>> it does not communicate that correctly to clients, this is what
>>> its response to selecting a read-only mailbox with "lrs" ACL in
>>> effect for the logged in user looks like:
>>> 
>>> 2 SELECT "Public/Test"
>> ..
>>> 2 OK [READ-ONLY] Select completed.
>>> 
>>> Shouldn't PERMANENTFLAGS contain \Seen here if per-user seen
>>> flags are enable and should it even be tagged READ-ONLY at all in
>>> this case? At least clients such as Python imaplib, IMAPClient,
>>> or Roundcube will open such mailboxes with EXAMINE and thus do
>>> not allow the modification of flags.
>> 
>> Are you still testing on v2.0? It could be a bug in it.
> 
> Yes, this is 2.0.9 from RHEL6.

I remember fixing this bug. There's a very good chance that it would simply 
work with v2.1.

Re: [Dovecot] Gmail like labels, three years later

[Timo Sirainen]

On 27.3.2013, at 22.15, Michael M Slusarz  wrote:

>> My latest idea: Keep using the rather dummy simple IMAP keywords. Use IMAP 
>> METADATA to create a mapping between keyword <-> human readable name. 
>> Dovecot is getting close to having native METADATA support. Such IMAP 
>> standard would still need to be designed though. Anyone up for writing an 
>> RFC? :)
> 
> Would the idea be that once the extension is announced a client would then 
> need to do a metadata lookup everytime you open the mailbox to build a 
> keyword->label map?  That could potentially be an expensive operation.
> 
> Maybe you could do something like an ENABLE LABELS so that when you open a 
> mailbox, you would see something like this (SELECT/EXAMINE response):
> 
> * FLAGS (\Answered \Flagged \Deleted \Seen \Draft foo1 foo2 Junk NonJunk)
> * LABELS (NIL NIL NIL NIL NIL "Label 1" "Label 2 Text" NIL NIL)
> 
> So there is no need to manually deal with lookups.  Storing the labels would 
> be done via standard METADATA commands.

Hmm. Maybe .. Although it would be nice to get the IMAP design away from such 
special-case features and try to make these more generic (which might not even 
require server modifications to work). Like maybe with CONDSTORE/QRESYNC you 
could simply see if your cached labels-modseq equals to the old one. Or simply 
pipelining the GETMETADATA command with SELECT. Or something.. I haven't really 
thought this much.

Re: [Dovecot] Incorrect response when opening read-only mailboxes with per-user flags?

[Guido Berhoerster]

* Timo Sirainen  [2013-03-27 20:27]:
> On 27.3.2013, at 13.41, Guido Berhoerster 
>  wrote:
> 
> > After some debugging on the protocol level I've finally found the
> > problem with per-user seen flags in read-only mailboxes. Dovecot
> > actually does allow storing the seen flag on messages but AFAICS
> > it does not communicate that correctly to clients, this is what
> > its response to selecting a read-only mailbox with "lrs" ACL in
> > effect for the logged in user looks like:
> > 
> > 2 SELECT "Public/Test"
> ..
> > 2 OK [READ-ONLY] Select completed.
> > 
> > Shouldn't PERMANENTFLAGS contain \Seen here if per-user seen
> > flags are enable and should it even be tagged READ-ONLY at all in
> > this case? At least clients such as Python imaplib, IMAPClient,
> > or Roundcube will open such mailboxes with EXAMINE and thus do
> > not allow the modification of flags.
> 
> Are you still testing on v2.0? It could be a bug in it.

Yes, this is 2.0.9 from RHEL6.
-- 
Guido Berhoerster

Re: [Dovecot] Gmail like labels, three years later

[Michael M Slusarz]

Quoting Timo Sirainen :


On 27.3.2013, at 5.15, Pablo Vieira  wrote:


On this post http://www.dovecot.org/list/dovecot/2011-June/059605.html I
was asking about the possibility of using arbitrary labels on messages,
much like Gmail does. On following replies, I was told about  few tricks
that might be used, that the IMAP protocol was being considering UTF-8
labels and ways to integrate them into the current system, etc., etc., etc.
That sounds nice and all.

I'm chiming in three years later only to know if things have changed, both
at Dovecot and at the IMAP protocol. Are we closer to have proper labels on
IMAP? Labels that help sorting messages in virtual folders where a message
can belong in several of them?


My latest idea: Keep using the rather dummy simple IMAP keywords.  
Use IMAP METADATA to create a mapping between keyword <-> human  
readable name. Dovecot is getting close to having native METADATA  
support. Such IMAP standard would still need to be designed though.  
Anyone up for writing an RFC? :)


Would the idea be that once the extension is announced a client would  
then need to do a metadata lookup everytime you open the mailbox to  
build a keyword->label map?  That could potentially be an expensive  
operation.


Maybe you could do something like an ENABLE LABELS so that when you  
open a mailbox, you would see something like this (SELECT/EXAMINE  
response):


* FLAGS (\Answered \Flagged \Deleted \Seen \Draft foo1 foo2 Junk NonJunk)
* LABELS (NIL NIL NIL NIL NIL "Label 1" "Label 2 Text" NIL NIL)

So there is no need to manually deal with lookups.  Storing the labels  
would be done via standard METADATA commands.


michael

Re: [Dovecot] Dovecot METADATA support

[Bruce Marriner]

 
On Wednesday, March 27, 2013 02:25 PM CDT, Timo Sirainen  wrote: 
 > On 27.3.2013, at 16.34, Bruce Marriner  wrote:
> 
> > I've been trying to work with dovecot metadata plugin and posted a question 
> > here related to that a few days ago here :
> > http://www.dovecot.org/list/dovecot/2013-March/089241.html
> 
> The patch is now in v2.1 hg, so will be in v2.1.16.

Thank you.

> >>> Dovecot is getting close to having native METADATA support.
> > 
> > I am very curious about this.  When is "getting close" and I would guess 
> > this will be for v2.2?  Will this support be the same as the 
> > dovecot-metadata-plugin in hg or something completely different?  I'm sorry 
> > if I'm asking questions that have already been answered.
> 
> The metadata plugin started with implementing the IMAP commands and kind of 
> ignored the difficult parts of fitting it in with everything. The stuff that 
> is in Dovecot now handles most of the difficult parts, but the IMAP commands 
> are missing. There are still two somewhat difficult things missing:
> 
>  * Where/how to keep track of metadata quota to prevent abuse? Maybe some 
> limits to number of entries, max. bytes total in entries, max. bytes per 
> entry. Although the last one only is useful for those backends that can't 
> handle large entry sizes.
> 
> ( * Maybe there should be a new dict backend that can handle both small and 
> large entries more optimally.. Then again some nosql dict backend would 
> probably work well too.)
> 
>  * Currently it's configured via mail_attribute_dict, which can e.g. point to 
> a file in user's home directory. How to handle shared metadata in shared 
> folders? Should userA just be accessing userB's dict file? Where are metadata 
> stored for public folders that have no owner? Should there be two dict 
> settings for private and public dict? (The last, or maybe all, would be a 
> non-issue if I had already implemented my idea of having only one dict 
> configuration where different prefixes could be mapped to completely 
> different locations/backends/etc.)
> 
 
These questions I can't help much with, sadly.  But I am more then willing to 
help with any testing, debugging, etc that I can possibly provide when there's 
something to test :).  I really do appreciate your work on this Timo!
 
 
 

Re: [Dovecot] Migrating password scheme

[Timo Sirainen]

On 26.3.2013, at 5.14, Joseph Tam  wrote:

> I've updated the Dovecot2 wiki, but I am unsure which userdb's
> "default_fields" applies to, and whether it just applies to postlogin
> scripts, so I documented it at
> 
>   http://wiki2.dovecot.org/AuthDatabase/PasswdFile

It works with all userdbs and passdbs. There are some other new features also 
generic to all passdbs. I guess the PasswordDatabase and UserDatabase pages 
need some sections about them.. Wonder if the common ones should be pointed to 
AuthDatabase or just copy&pasted (=become desynced over time) to both pages.. 
Could be a good feature idea for a wiki to allow importing text from some other 
page :)

Anyway, I'll probably move these things over unless someone happens to beat me 
to it. Way too busy right now though.

Re: [Dovecot] Incorrect response when opening read-only mailboxes with per-user flags?

[Timo Sirainen]

On 27.3.2013, at 13.41, Guido Berhoerster  
wrote:

> After some debugging on the protocol level I've finally found the
> problem with per-user seen flags in read-only mailboxes. Dovecot
> actually does allow storing the seen flag on messages but AFAICS
> it does not communicate that correctly to clients, this is what
> its response to selecting a read-only mailbox with "lrs" ACL in
> effect for the logged in user looks like:
> 
> 2 SELECT "Public/Test"
..
> 2 OK [READ-ONLY] Select completed.
> 
> Shouldn't PERMANENTFLAGS contain \Seen here if per-user seen
> flags are enable and should it even be tagged READ-ONLY at all in
> this case? At least clients such as Python imaplib, IMAPClient,
> or Roundcube will open such mailboxes with EXAMINE and thus do
> not allow the modification of flags.

Are you still testing on v2.0? It could be a bug in it.

Re: [Dovecot] Dovecot METADATA support

[Timo Sirainen]

On 27.3.2013, at 16.34, Bruce Marriner  wrote:

> I've been trying to work with dovecot metadata plugin and posted a question 
> here related to that a few days ago here :
> http://www.dovecot.org/list/dovecot/2013-March/089241.html

The patch is now in v2.1 hg, so will be in v2.1.16.

> I just read today (e-mail on this list) from Timo Sirainen that
> 
>>> Dovecot is getting close to having native METADATA support.
> 
> I am very curious about this.  When is "getting close" and I would guess this 
> will be for v2.2?  Will this support be the same as the 
> dovecot-metadata-plugin in hg or something completely different?  I'm sorry 
> if I'm asking questions that have already been answered.

The metadata plugin started with implementing the IMAP commands and kind of 
ignored the difficult parts of fitting it in with everything. The stuff that is 
in Dovecot now handles most of the difficult parts, but the IMAP commands are 
missing. There are still two somewhat difficult things missing:

 * Where/how to keep track of metadata quota to prevent abuse? Maybe some 
limits to number of entries, max. bytes total in entries, max. bytes per entry. 
Although the last one only is useful for those backends that can't handle large 
entry sizes.

( * Maybe there should be a new dict backend that can handle both small and 
large entries more optimally.. Then again some nosql dict backend would 
probably work well too.)

 * Currently it's configured via mail_attribute_dict, which can e.g. point to a 
file in user's home directory. How to handle shared metadata in shared folders? 
Should userA just be accessing userB's dict file? Where are metadata stored for 
public folders that have no owner? Should there be two dict settings for 
private and public dict? (The last, or maybe all, would be a non-issue if I had 
already implemented my idea of having only one dict configuration where 
different prefixes could be mapped to completely different 
locations/backends/etc.)

Re: [Dovecot] Gmail like labels, three years later

[Timo Sirainen]

On 27.3.2013, at 17.28, Pablo Vieira  wrote:

>> My latest idea: Keep using the rather dummy simple IMAP keywords. Use IMAP
>> METADATA to create a mapping between keyword <-> human readable name.
>> Dovecot is getting close to having native METADATA support. Such IMAP
>> standard would still need to be designed though. Anyone up for writing an
>> RFC? :)
>> 
>> Thanks Timo, I'm not quite sure what IMAP METADATA is. Will have some
> spare time this summer. Any good readings about IMAP you can recommend?
> MIght as well help in that department.

METADATA is simply about adding simple key=value pairs to mailboxes. So you 
could have something like:

/shared/keywords/$Label1 = Important
/shared/keywords/$Label2 = Work
/shared/keywords/HelloWorld = Hello World messages

Probably it wouldn't need to be any more complex than that. The clients would 
then handle adding/changing/removing those keywords.

http://tools.ietf.org/html/rfc5464 describes METADATA.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Timo Sirainen]

On 27.3.2013, at 18.41, Peer Heinlein  wrote:

> Am 27.03.2013 08:44, schrieb 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

Re: [Dovecot] Authentication failure messages in logs

[Nicolas Mora]

Le 18/03/2013 10:13, Steffen Kaiser a écrit :


Well, you seem to use just one passdb. The article you are referring
to says "the first try is always empty username and password so it
slows down terribly every action.".


Yes, sorry, I may have messed up with the links...

In fact, I may have been wrong from the beginning because the problem 
seems not to come from dovecot but higher in the auth process, probably 
PAM...


Sorry for the silly question.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Robert Schetterer]

Am 27.03.2013 17:51, schrieb Peer Heinlein:
> Am 25.03.2013 15:27, schrieb 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
> 
> 

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

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Peer Heinlein]

Am 25.03.2013 15:27, schrieb 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

[Dovecot] Managesieve Automatic Homedir Creation: File not Found Error

[linuxer]

Hi all,

I'm running dovecot version 2.0.19 (Ubuntu 12.04) and I discovered some
unexpected behaviour related to the Dovecot managesieve module. When
connecting to the managesieve service from a client for the first time
(e.g. roundcube webmail), I get an application error. This is logged by
Dovecot:

Error: sieve-storage:
opendir(/var/.../exampledomain/exampleuser@exampledomain//sieve) failed:
No such file or directory.

At first glance I thought the problem was caused by the "//" in the
directory path. I assume this is just a concatenation of the user virtual
home directory (in my case
"/var/.../exampledomain/exampleuser@exampledomain/" and the default sieve
folder (~/sieve). While this looks wrong it seems not to be the actual
problem (should be fixed though?)

Then I noticed that the user home directory and sieve data were actually
properly created despite the error. When connecting again, it worked
without error. The problem can be reproduced by deleting the users virtual
home directory and connecting again.

A guess would be that the automatic creation of the virtual users homedir
folder structure is some asychronous process not being completed in time.

I also found this older thread with a similar issue:
http://osdir.com/ml/dovecot-development/2010-05/msg00018.html

Could also be worth mentioning that I'm running Dovecot on a virtualized
host with possibly relatively poor I/O performance (maybe faster
environments don't have this problem).

Thanks for looking into this, and thx for the really neat dovecot software
package!

Cheers,
L.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Peer Heinlein]

Am 27.03.2013 11:19, schrieb Gordon Grubert:

>>> 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

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Peer Heinlein]

Am 27.03.2013 08:44, schrieb 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

Re: [Dovecot] Crash while moving mail between private folder and shared folder

[kadafax]

Hi,

Just to bump the OP message as I experience the exact same symptom with 
the same configuration. That is: when moving an email to a virtual 
mailboxes, dovecot crash (and sometime the email disappears from the 
real mailbox).


Thx

Le 23/03/13 10:03, Christian Felsing a écrit :

Hello,

while moving a mail from a private folder (inbox) to a shared folder and
back to private folder Dovecot 2.2rc3 crashes:

---cut here---
Mar 23 09:57:44 dovecot dovecot: imap-login: Login:
user=, method=PLAIN, rip=192.168.200.6,
lip=192.168.200.22, mpid=19423, TLS
Mar 23 09:57:44 dovecot dovecot: imap(john@example.net): Panic: file
mail-namespace.c: line 654 (mail_namespace_find): assertion failed: (ns
!= NULL)
Mar 23 09:57:44 dovecot dovecot: imap(john@example.net): Error: Raw
backtrace: /opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(+0x608fa)
[0x7f82f65b28fa] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(+0x6093e)
[0x7f82f65b293e] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(i_fatal+0)
[0x7f82f657435b] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mail_namespace_find_unalias+0)
[0x7f82f686b590] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mail_namespace_find_unalias+0x19)
[0x7f82f686b5a9] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(+0x57bd)
[0x7f82f51127bd] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(quota_test_alloc+0xcb)
[0x7f82f511424b] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(quota_try_alloc+0x3d)
[0x7f82f511445d] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(+0xb00b)
[0x7f82f511800b] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib01_acl_plugin.so(+0xc7cb)
[0x7f82f552d7cb] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mailbox_copy+0x5f)
[0x7f82f687274f] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mailbox_move+0x10)
[0x7f82f6872810] -> dovecot-01/imap() [0x40d29d] ->
dovecot-01/imap(command_exec+0x3c) [0x4161ec] -> dovecot-01/imap()
[0x415250] -> dovecot-01/imap() [0x41530a] ->
dovecot-01/imap(client_handle_input+0x115) [0x4155c5] ->
dovecot-01/imap(client_input+0x72) [0x415972] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x36)
[0x7f82f65c20e6] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0xd7)
[0x7f82f65c2f37] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(io_loop_run+0x28)
[0x7f82f65c1c28] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
[0x7f82f6579473]
-> dovecot-01/imap(main+0x270) [0x40b950] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f82f61e6ead]
-> dovecot-01/imap() [0x40baad]
Mar 23 09:57:44 dovecot dovecot: imap(john@example.net): Fatal:
master: service(imap): child 19423 killed with signal 6 (core dumps
disabled)
Mar 23 09:57:44 dovecot dovecot: imap-login: Login:
user=, method=PLAIN, rip=192.168.200.6,
lip=192.168.200.22, mpid=19425, TLS
Mar 23 09:57:44 dovecot dovecot: imap(john@example.net): Panic: file
mail-namespace.c: line 654 (mail_namespace_find): assertion failed: (ns
!= NULL)
Mar 23 09:57:44 dovecot dovecot: imap(john@example.net): Error: Raw
backtrace: /opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(+0x608fa)
[0x7f66ed9a58fa] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(+0x6093e)
[0x7f66ed9a593e] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(i_fatal+0)
[0x7f66ed96735b] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mail_namespace_find_unalias+0)
[0x7f66edc5e590] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mail_namespace_find_unalias+0x19)
[0x7f66edc5e5a9] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(+0x57bd)
[0x7f66ec5057bd] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(quota_test_alloc+0xcb)
[0x7f66ec50724b] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(quota_try_alloc+0x3d)
[0x7f66ec50745d] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib10_quota_plugin.so(+0xb00b)
[0x7f66ec50b00b] ->
/opt/dovecot-2.2.rc3/lib/dovecot/lib01_acl_plugin.so(+0xc7cb)
[0x7f66ec9207cb] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mailbox_copy+0x5f)
[0x7f66edc6574f] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot-storage.so.0(mailbox_move+0x10)
[0x7f66edc65810] -> dovecot-01/imap() [0x40d29d] ->
dovecot-01/imap(command_exec+0x3c) [0x4161ec] -> dovecot-01/imap()
[0x415250] -> dovecot-01/imap() [0x41530a] ->
dovecot-01/imap(client_handle_input+0x115) [0x4155c5] ->
dovecot-01/imap(client_input+0x72) [0x415972] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x36)
[0x7f66ed9b50e6] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0xd7)
[0x7f66ed9b5f37] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(io_loop_run+0x28)
[0x7f66ed9b4c28] ->
/opt/dovecot-2.2.rc3/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
[0x7f66ed96c473]
-> dovecot-01/imap(main+0x270) [0x40b950] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f66ed5d9ead]
-> d

Re: [Dovecot] Error Building v2.2

[Nikolaos Milas]

On 26/3/2013 10:57 μμ, Nikolaos Milas wrote:

So, how do we build Dovecot v2.2 on CentOS 5 ? 


I decided to use: 
ftp://ftp.pbone.net/mirror/ftp.sourceforge.net/pub/sourceforge/h/hp/hphp/CentOS%205%2064bit/RPM/autoconf-2.63-3.noarch.rpm


which required me to build m4 with a version > 1.4.7 (because I couldn't 
find such an m4 version around).


Therefore, I used: 
https://oss.oracle.com/el5/SRPMS/m4-1.4.5-3.el5.1.src.rpm with source 
for v1.4.9 (from: ftp://ftp.gnu.org/gnu/m4/) and I built 
m4-1.4.9-1.el5.1.x86_64.rpm


After that, I was able to build Dovecot 2.2 successfully on CentOS 5.

Nevertheless, I had a bunch of warnings from autoconf, which I copy 
below, in case someone can suggest how to avoid them.


Thanks and regards,
Nick

autoconf warnings follow:

=
+ autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, 
...): suspicious cache-id, must contain _cv_ to be cached

../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from...
/usr/share/aclocal/libtool.m4:615: AC_LIBTOOL_COMPILER_OPTION is 
expanded from...
/usr/share/aclocal/libtool.m4:4835: AC_LIBTOOL_PROG_COMPILER_PIC is 
expanded from...

/usr/share/aclocal/libtool.m4:2668: _LT_AC_LANG_C_CONFIG is expanded from...
/usr/share/aclocal/libtool.m4:2667: AC_LIBTOOL_LANG_C_CONFIG is expanded 
from...

/usr/share/aclocal/libtool.m4:80: AC_LIBTOOL_SETUP is expanded from...
/usr/share/aclocal/libtool.m4:60: _AC_PROG_LIBTOOL is expanded from...
/usr/share/aclocal/libtool.m4:25: AC_PROG_LIBTOOL is expanded from...
configure.ac:293: the top level
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, 
...): suspicious cache-id, must contain _cv_ to be cached
/usr/share/aclocal/libtool.m4:660: AC_LIBTOOL_LINKER_OPTION is expanded 
from...
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, 
...): suspicious cache-id, must contain _cv_ to be cached
/usr/share/aclocal/libtool.m4:2749: _LT_AC_LANG_CXX_CONFIG is expanded 
from...
/usr/share/aclocal/libtool.m4:2748: AC_LIBTOOL_LANG_CXX_CONFIG is 
expanded from...

/usr/share/aclocal/libtool.m4:1804: _LT_AC_TAGCONFIG is expanded from...
configure.ac:293: warning: 
AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious 
cache-id, must contain _cv_ to be cached
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, 
...): suspicious cache-id, must contain _cv_ to be cached
/usr/share/aclocal/libtool.m4:3916: _LT_AC_LANG_F77_CONFIG is expanded 
from...
/usr/share/aclocal/libtool.m4:3915: AC_LIBTOOL_LANG_F77_CONFIG is 
expanded from...
configure.ac:293: warning: 
AC_CACHE_VAL(lt_prog_compiler_static_works_F77, ...): suspicious 
cache-id, must contain _cv_ to be cached
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, 
...): suspicious cache-id, must contain _cv_ to be cached
/usr/share/aclocal/libtool.m4:4018: _LT_AC_LANG_GCJ_CONFIG is expanded 
from...
/usr/share/aclocal/libtool.m4:4017: AC_LIBTOOL_LANG_GCJ_CONFIG is 
expanded from...
configure.ac:293: warning: 
AC_CACHE_VAL(lt_prog_compiler_static_works_GCJ, ...): suspicious 
cache-id, must contain _cv_ to be cached

autoreconf: configure.ac: tracing
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, 
...): suspicious cache-id, must contain _cv_ to be cached

../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from...
aclocal.m4:1878: AC_LIBTOOL_COMPILER_OPTION is expanded from...
aclocal.m4:6086: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
aclocal.m4:3931: _LT_AC_LANG_C_CONFIG is expanded from...
aclocal.m4:3930: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
aclocal.m4:1343: AC_LIBTOOL_SETUP is expanded from...
aclocal.m4:1323: _AC_PROG_LIBTOOL is expanded from...
aclocal.m4:1288: AC_PROG_LIBTOOL is expanded from...
configure.ac:293: the top level
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, 
...): suspicious cache-id, must contain _cv_ to be cached

aclocal.m4:1923: AC_LIBTOOL_LINKER_OPTION is expanded from...
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, 
...): suspicious cache-id, must contain _cv_ to be cached

aclocal.m4:4008: _LT_AC_LANG_CXX_CONFIG is expanded from...
aclocal.m4:4007: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from...
aclocal.m4:3067: _LT_AC_TAGCONFIG is expanded from...
configure.ac:293: warning: 
AC_CACHE_VAL(lt_prog_compiler_static_works_CXX, ...): suspicious 
cache-id, must contain _cv_ to be cached
configure.ac:293: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77, 
...): suspicious cache-id, must contain _cv_ to be cached

aclocal.m4:5171: _LT_AC_LANG_F77_CONFIG is expanded from...
aclocal.m4:5170: AC_

Re: [Dovecot] Gmail like labels, three years later

[Pablo Vieira]

2013/3/27 Timo Sirainen 

> On 27.3.2013, at 5.15, Pablo Vieira  wrote:
>
> > On this post http://www.dovecot.org/list/dovecot/2011-June/059605.html I
> > was asking about the possibility of using arbitrary labels on messages,
> > much like Gmail does. On following replies, I was told about  few tricks
> > that might be used, that the IMAP protocol was being considering UTF-8
> > labels and ways to integrate them into the current system, etc., etc.,
> etc.
> > That sounds nice and all.
> >
> > I'm chiming in three years later only to know if things have changed,
> both
> > at Dovecot and at the IMAP protocol. Are we closer to have proper labels
> on
> > IMAP? Labels that help sorting messages in virtual folders where a
> message
> > can belong in several of them?
>
> My latest idea: Keep using the rather dummy simple IMAP keywords. Use IMAP
> METADATA to create a mapping between keyword <-> human readable name.
> Dovecot is getting close to having native METADATA support. Such IMAP
> standard would still need to be designed though. Anyone up for writing an
> RFC? :)
>
> Thanks Timo, I'm not quite sure what IMAP METADATA is. Will have some
spare time this summer. Any good readings about IMAP you can recommend?
MIght as well help in that department.

[Dovecot] Separate log file for Sieve

[Ewald Dieterich]

I use

log_path = /var/log/dovecot/error.log
info_log_path = /var/log/dovecot/info.log
debug_log_path = /var/log/dovecot/debug.log

to log to different files.

Since I don't consider Sieve errors as severe as "real" Dovecot errors I 
would like to keep them away from the error log.


Is it possible to configure a separate log file for Sieve?

[Dovecot] Dovecot METADATA support

[Bruce Marriner]

I've been trying to work with dovecot metadata plugin and posted a question 
here related to that a few days ago here :
http://www.dovecot.org/list/dovecot/2013-March/089241.html

I just read today (e-mail on this list) from Timo Sirainen that

>>
>> Dovecot is getting close to having native METADATA support.
>>

I am very curious about this.  When is "getting close" and I would guess this 
will be for v2.2?  Will this support be the same as the dovecot-metadata-plugin 
in hg or something completely different?  I'm sorry if I'm asking questions 
that have already been answered.

My goal is to use Kolab3 with Dovecot instead of using Cyrus IMAP and Kolab 
requires metadata/annotation support.  Right now I'm testing this using the 
dovecot-metadata-plugin but I am very interested it learning about native 
metadata support and testing it with Kolab 3.

Any detail you can provide would be very appreciated.

Bruce

Re: [Dovecot] Problem when indexing maildir with a large number of folders

[André Rodier]

Hello Allessio,

I am using readpst -r from libpst (http://www.five-ten-sg.com/libpst/)

André

On 27 March 2013 13:25, Alessio Cecchi  wrote:
> Il 27/03/2013 00:20, Andre Rodier ha scritto:
>
>> Hello everybody,
>>
>> As part of a migration from exchange 2003 to dovecot, I have converted a
>> lot of PST files for a user. I am importing his PST files in a maildir
>> folder called
>> 'Archives'. Actually, I reached about 770 'Archives' folders, and the
>> total length of their names is about 59k characters. Thanks to wc!
>>
>> I am using Maildir++
>
>
> Hi,
>
> what kind of method are you using for converting PST into Maildir?
>
> Thanks
> --
> Alessio Cecchi is:
> @ ILS -> http://www.linux.it/~alessice/
> on LinkedIn -> http://www.linkedin.com/in/alessice
> Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/
> @ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it



-- 
André Rodier

Re: [Dovecot] Problem when indexing maildir with a large number of folders

[Alessio Cecchi]

Il 27/03/2013 00:20, Andre Rodier ha scritto:

Hello everybody,

As part of a migration from exchange 2003 to dovecot, I have converted a lot of 
PST files for a user. I am importing his PST files in a maildir folder called
'Archives'. Actually, I reached about 770 'Archives' folders, and the total 
length of their names is about 59k characters. Thanks to wc!

I am using Maildir++


Hi,

what kind of method are you using for converting PST into Maildir?

Thanks
--
Alessio Cecchi is:
@ ILS -> http://www.linux.it/~alessice/
on LinkedIn -> http://www.linkedin.com/in/alessice
Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/
@ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it

Re: [Dovecot] Implementing Single instance attachment storage (SIS) with sdbox

[Pascal Volk]

On 03/27/2013 12:30 PM mego...@inboxalias.com wrote:
> Hi there,
> 
> as I want to implement data dedupliction on my dovecot system (eg. a users 
> sends the same attchment to 5 different users on my system so I only have to 
> store the attachment one time and set pointers to the file) , I found out it 
> could be possible with Single instance attachment storage (SIS), so I read 
> several pages about SIS as it was quoted here 
> (http://wiki2.dovecot.org/MailboxFormat/dbox): 
> 
>> dbox storage is extensible. Single instance attachment storage was already 
>> implemented as such extension. 
> 
> But I did not found any further intructions in Dovecot Wiki how to implement 
> it - however, on Dovecots blog there was an older article from Timo which 
> gave some indication how to get it work 
> (http://blog.dovecot.org/2010/07/single-instance-attachment-storage.html):
> 
> 
>> mail_location = dbox:~/dbox:ATTACHMENTS=/attachments/$/$
> 
> 
> But when I change my configuration according to this (I use sdbox as mail 
> format), I just get a "Unknown setting: ATTACHMENTS" in my mail.err log.
> 
> Can anybody give me a clue how to get this working?


Hm, that blog post seems to be a little bit old. There is no need to
modify the mail_location setting.
All single instance storage related settings could be found at the end
of conf.d/10-mail.conf
.


Regards,
Pascal
-- 
The trapper recommends today: fabaceae.1308...@localdomain.org

[Dovecot] Incorrect response when opening read-only mailboxes with per-user flags?

[Guido Berhoerster]

After some debugging on the protocol level I've finally found the
problem with per-user seen flags in read-only mailboxes. Dovecot
actually does allow storing the seen flag on messages but AFAICS
it does not communicate that correctly to clients, this is what
its response to selecting a read-only mailbox with "lrs" ACL in
effect for the logged in user looks like:

2 SELECT "Public/Test"
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 2 EXISTS
* 0 RECENT
* OK [UNSEEN 2] First unseen.
* OK [UIDVALIDITY 1364221612] UIDs valid
* OK [UIDNEXT 3] Predicted next UID
* OK [HIGHESTMODSEQ 1] Highest
2 OK [READ-ONLY] Select completed.

Shouldn't PERMANENTFLAGS contain \Seen here if per-user seen
flags are enable and should it even be tagged READ-ONLY at all in
this case? At least clients such as Python imaplib, IMAPClient,
or Roundcube will open such mailboxes with EXAMINE and thus do
not allow the modification of flags.
-- 
Guido Berhoerster

[Dovecot] Implementing Single instance attachment storage (SIS) with sdbox

[megodin]

Hi there,

as I want to implement data dedupliction on my dovecot system (eg. a users 
sends the same attchment to 5 different users on my system so I only have to 
store the attachment one time and set pointers to the file) , I found out it 
could be possible with Single instance attachment storage (SIS), so I read 
several pages about SIS as it was quoted here 
(http://wiki2.dovecot.org/MailboxFormat/dbox): 

> dbox storage is extensible. Single instance attachment storage was already 
> implemented as such extension. 

But I did not found any further intructions in Dovecot Wiki how to implement it 
- however, on Dovecots blog there was an older article from Timo which gave 
some indication how to get it work 
(http://blog.dovecot.org/2010/07/single-instance-attachment-storage.html):


> mail_location = dbox:~/dbox:ATTACHMENTS=/attachments/$/$



But when I change my configuration according to this (I use sdbox as mail 
format), I just get a "Unknown setting: ATTACHMENTS" in my mail.err log.



Can anybody give me a clue how to get this working?


Thanks in advance!
Megodin






---
Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! 
http://email.freenet.de/produkte/basic/index.html

_
Send and receive anonymous emails to your inbox with InboxAlias.
http://www.inboxalias.com

Re: [Dovecot] Disk Encryption

[Charles Marcus]

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

On 2013-03-27 12:47 AM, Daniel Reinhardt  wrote:

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.


On Wed, Mar 27, 2013 at 12:36 AM, Xin Li  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 3/25/13 6:24 AM, Simon Brereton wrote:

On 25 March 2013 12:30, Robert Schetterer  wrote:

Am 25.03.2013 11:03, schrieb 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-







--

Best regards,

Charles Marcus
I.T. Director
Media Brokers International, Inc.
678.514.6224 | 678.514.6299 fax

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Robert Schetterer]

Am 27.03.2013 11:55, schrieb Gordon Grubert:
> On 03/27/2013 11:48 AM, Robert Schetterer wrote:
>> 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 ?

> 
> Best regards,
> Gordon
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Gordon Grubert]

On 03/27/2013 11:48 AM, Robert Schetterer wrote:

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

Re: [Dovecot] Problem when indexing maildir with a large number of folders

[Timo Sirainen]

On 27.3.2013, at 1.20, Andre Rodier  wrote:

>> doveadm(john smith): Panic: file mail-index-transaction-update.c: line 875 
>> (mail_index_update_header_ext): assertion failed: (offset <= (uint16_t)-1 && 
>> size
>> <= (uint16_t)-1 && offset + size <= (uint16_t)-1)
> 
> I can see I have reached a limit, but is there any configuration value I can 
> use to increase this limit, please?

Looks like this was an easier fix than I thought: 
http://hg.dovecot.org/dovecot-2.1/rev/87d0c4056b4d

I didn't test it now, but the code to handle it exists.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Robert Schetterer]

Am 27.03.2013 11:19, schrieb Gordon Grubert:
> On 03/27/2013 08:38 AM, Timo Sirainen wrote:
>> On 27.3.2013, at 9.34, Peer Heinlein 
>> wrote:
>>
>>> Am 26.03.2013 23:15, schrieb 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

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

Re: [Dovecot] Problem when indexing maildir with a large number of folders

[Andre Rodier]

Hello again,

I am sorry to be a pain, but is there any chance someone knows this problem, 
and how I can fix this, please?

Kind regards,
André
On Tuesday, 26.03.13 at 23:20, Andre Rodier wrote:
> Hello everybody,
> 
> As part of a migration from exchange 2003 to dovecot, I have converted a lot 
> of PST files for a user. I am importing his PST files in a maildir folder 
> called
> 'Archives'. Actually, I reached about 770 'Archives' folders, and the total 
> length of their names is about 59k characters. Thanks to wc!
> 
> I am using Maildir++
> 
> I can run the doveadm index command on the private namespace, however, I am 
> not able to do this on the virtual folders.
> 
> Here the error I have:
> 
> > doveadm(john smith): Panic: file mail-index-transaction-update.c: line 875 
> > (mail_index_update_header_ext): assertion failed: (offset <= (uint16_t)-1 
> > && size
> > <= (uint16_t)-1 && offset + size <= (uint16_t)-1)
> > doveadm(gareth walters): Error: Raw backtrace: 
> > /usr/lib/dovecot/libdovecot.so.0(+0x4414a) [0x7f9b7100714a] ->
> > /usr/lib/dovecot/libdovecot.so.0(default_fatal_handler+0x2a) 
> > [0x7f9b7100720a] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) 
> > [0x7f9b70fde82a] ->
> > /usr/lib/dovecot/libdovecot-storage.so.0(+0xb8079) [0x7f9b7130a079] -> 
> > /usr/lib/dovecot/modules/lib20_virtual_plugin.so(virtual_storage_sync_init+0x788)
> > [0x7f9b6f1775a8] -> 
> > /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync_init+0x33) 
> > [0x7f9b712cf3e3] ->
> > /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync+0x27) 
> > [0x7f9b712cf507] -> doveadm(+0x16618) [0x7f9b719c8618] -> doveadm(+0x13346) 
> > [0x7f9b719c5346] ->
> > doveadm(+0x13e21) [0x7f9b719c5e21] -> doveadm(doveadm_mail_try_run+0x161) 
> > [0x7f9b719c62e1] -> doveadm(main+0x3d1) [0x7f9b719c4ef1] ->
> > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f9b70c57ead] -> 
> > doveadm(+0x13125) [0x7f9b719c5125]
> > Aborted
> 
> I can see I have reached a limit, but is there any configuration value I can 
> use to increase this limit, please?
> 
> Kind regards,
> André.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Gordon Grubert]

On 03/27/2013 08:38 AM, Timo Sirainen wrote:

On 27.3.2013, at 9.34, Peer Heinlein  wrote:


Am 26.03.2013 23:15, schrieb 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




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Dovecot] Disk Encryption

[Jeroen Massar]

[..]
> 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

Re: [Dovecot] Sieve Vacation for redirected email

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 26 Mar 2013, Dave Gattis wrote:

Our emails are redirected from the home office causing all vacation responses 
to fail with, "discarding vacation response for implicitly delivered message; 
no known (envelope) recipient address found in message headers".


=== headers from reply
Return-Path: 
X-Original-To: dave.gat...@domain-b.com
Delivered-To: dave.gat...@domain-b.com
Received: from spamcop.main.ch (spamcop.main.ch [83.144.241.40])
by domain-b.com (Postfix) with ESMTP id 0E4E81C101DE
for ; Tue, 26 Mar 2013 14:35:13 -0400 
(EDT)

Received: from ex.domain-a.com (ex.domain-a.com [83.144.240.35]) by
spamcop.main.ch with ESMTP id 0dP4XCjZrdDY5l1Q for
; Tue, 26 Mar 2013 19:41:36 +0100 (CET)
Received: from EX2.domain-a.com ([fe80::acd3:8e53:bcb6:7a4%11]) by
 ex2.domain-a.com ([fe80::acd3:8e53:bcb6:7a4%11]) with Microsoft SMTP 
Server

id
 14.01.0355.002; Tue, 26 Mar 2013 19:39:54 +0100

From: Dave Gattis 
To: SUMACO Gattis Dave 
=

You have two problems:

a) "no known (envelope) recipient address found in message headers" means, 
that the vacation :addresses list does not contain


dave.gat...@domain-a.com

because vacation probes the entries of the :addresses list against To and 
CC.


b) the messages are _resend_ not forwarded by spamcop.main.ch to your MTA. 
By doing so the original *envelope* sender address is lost, which is *not* 
the entry in "From:". Therefore vacation would send the reply to:


dave.gat...@domain-a.com

which is the return path per your excerpt. You could verify that by 
finding the envelope sender in the postfix logs, I guess; or by fixing a).


Actually, I'm not sure if pigeonhole can pick up the address to reply to 
from a mail header - I do not see any hints in the sample config. So, 
maybe, you need to ask spamcop.main.ch to preserve the return address.


Note: Changing the envelope sender is not bad by itself, it solves several 
problems with forwarding; a well-known MTA can do this, too: 
http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/8006eabb-3334-4ff1-89d6-d647088bec46 
, but you get other problems rewriting the sender address.


- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBUVLAH13r2wJMiz2NAQJYbgf+OdgAU/KJiMANoUJ6XDiwPuNGr0IMNCev
QOBtc+EgDTJ36yBAbtOn88zhHCgXuBwLxQax5cx3E5eQ0mba6IxJm7c9whaJA+IG
y0Eh8bJiIfAKtGrEWoz6riktDkJ89kLpxY0zycpPgK6xGUiBvSHFb59bpIMc+WLX
YHXWzX8u3216Jydr28x+Gcday/mix6zujoQucRjzPmAXc9RjFqkLxiOuIdDP+zSH
war8t7QWlEVtfgCOG07V0QkqEvM047HhRbSZuTRcTHmUH2Sjfwe3fdHdnmjd4wvk
wsVl9F/X7cdzh84uQ2eP2ZIfQYuC4vu/Ur1ONyaxH4DBxFyIdFjngA==
=stJs
-END PGP SIGNATURE-

Re: [Dovecot] Disk Encryption

[Simon Brereton]

On 27 March 2013 05:36, Xin Li  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 3/25/13 6:24 AM, Simon Brereton wrote:
>> On 25 March 2013 12:30, Robert Schetterer  wrote:
>>> Am 25.03.2013 11:03, schrieb 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

Re: [Dovecot] Error Building v2.2

[Christian Wiese]

Hi Nick,

good to hear that you had some partial success at least!

> > However, on CentOS 5, it didn't work. autoreconf did not output
> > errors after I installed gettext-devel but it again threw: 
> 
> Hmm, I forgot; According to: 
> http://www.dovecot.org/list/dovecot/2011-April/058420.html, --docdir 
> option exists when autoconf version > 2.60, but CentOS / RHEL 5 has 
> version 2.59.
>
> So, how do we build Dovecot v2.2 on CentOS 5 ?

What about _not_ passing the --docdir configure option at all when
building for CentOS 5?
As I mentioned earlier I have not much experience when it comes to RPM
stuff, but maybe there is a way to check for the CentOS version within
the spec file, to decide if you should pass the --docdir or not.
If that is not possible you might need to create a dedicated SRPM for
each CentOS version.

Cheers,
Chris

[Dovecot] Dovecot 2.2rc3 Client Cert Auth and Webmail -> auth_ssl_require_client_cert problem

[Christian Felsing]

Hello,

I would like to set up a Dovecot based mail system which uses X.509
Client Certificates for authentication. A webmail system based on Horde5
should use Dovecot as backend.

For now Dovecot works with client certificates issued by my CA and Horde
authenticates also with same client certs. Due to protocol it is
impossible to use client certs presented by user to Horde for
authentication at Dovecot, so Horde should be allowed to authenticate
itself without or an arbitrary password to Dovecot. Horde and Dovecot
are running in same protected LAN.

Unfortunately Dovecot does not support different authentication methods
on different IP addresses or ports. This does not work:

remote 192.168.116.28/32 {
  auth_ssl_require_client_cert = no
  auth_ssl_username_from_cert = yes
  disable_plaintext_auth = no
  ssl = yes

}

Result is "doveconf: Fatal: Error in configuration file
/opt/dovecot-2.2.rc3/etc/dovecot/conf.d/10-auth.conf line 103: Auth
settings not supported inside local/remote blocks:
auth_ssl_require_client_cert"

Replacing "auth_ssl_require_client_cert = no" by "ssl_verify_client_cert =
no" does not yield in an error, but it does nothing, Dovecot still
insists for a client certificate.

I afraid that I am trapped by this problem:
http://dovecot.2317879.n4.nabble.com/Problem-with-requiring-client-certificates-for-external-connections-tp475.html

Is there any way to turn off client certs for specific local or remote
IP addresses?

best regards
Christian

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Robert Schetterer]

Am 27.03.2013 08:44, schrieb Timo Sirainen:
> On 27.3.2013, at 0.15, Peer Heinlein  wrote:
> 
>> 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

guess you mean zlib ?

>> *) 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

>> *) 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

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Joerg Heidrich

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Timo Sirainen]

On 27.3.2013, at 0.15, Peer Heinlein  wrote:

> 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

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.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Timo Sirainen]

On 27.3.2013, at 9.34, Peer Heinlein  wrote:

> Am 26.03.2013 23:15, schrieb 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.

Re: [Dovecot] 2.1: Error: Maildir filename has wrong S value, renamed the file from

[Peer Heinlein]

Am 26.03.2013 23:15, schrieb 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

Re: [Dovecot] Gmail like labels, three years later

[Timo Sirainen]

On 27.3.2013, at 5.15, Pablo Vieira  wrote:

> On this post http://www.dovecot.org/list/dovecot/2011-June/059605.html I
> was asking about the possibility of using arbitrary labels on messages,
> much like Gmail does. On following replies, I was told about  few tricks
> that might be used, that the IMAP protocol was being considering UTF-8
> labels and ways to integrate them into the current system, etc., etc., etc.
> That sounds nice and all.
> 
> I'm chiming in three years later only to know if things have changed, both
> at Dovecot and at the IMAP protocol. Are we closer to have proper labels on
> IMAP? Labels that help sorting messages in virtual folders where a message
> can belong in several of them?

My latest idea: Keep using the rather dummy simple IMAP keywords. Use IMAP 
METADATA to create a mapping between keyword <-> human readable name. Dovecot 
is getting close to having native METADATA support. Such IMAP standard would 
still need to be designed though. Anyone up for writing an RFC? :)

[Dovecot] Gmail like labels, three years later

[Pablo Vieira]

On this post http://www.dovecot.org/list/dovecot/2011-June/059605.html I
was asking about the possibility of using arbitrary labels on messages,
much like Gmail does. On following replies, I was told about  few tricks
that might be used, that the IMAP protocol was being considering UTF-8
labels and ways to integrate them into the current system, etc., etc., etc.
That sounds nice and all.

I'm chiming in three years later only to know if things have changed, both
at Dovecot and at the IMAP protocol. Are we closer to have proper labels on
IMAP? Labels that help sorting messages in virtual folders where a message
can belong in several of them?

I consider "label vs folder" a done discussion (since labels can always
include folders; a labels system can always be implemented as a folders
system, but not viceversa; etc), so what's stopping development in that
direction? Have any new energies being devoted to that cause?

I just seen Dovecot is  number 1 among IMAP servers by a large margin.
Congratulations to the devs.

Aleve.