[Dovecot] Dovecot don't recognise new messages in maildir /new

[Tim Wagner]

Hi,

sorry for the imprecise information.

Postfix is configured for virtual hosting the different lookup tables are stored in a mysql db. The delivery path for the different email addresses is always '/mail/domainpart/localpart/', of course without the 'new/'! :-)

My dovecot.conf follows

base_dir = /var/run/dovecot/
protocols = imaps pop3s
disable_plaintext_auth = yes
login_user = dovecot
login_process_size = 32
login_process_per_connection = yes
login_processes_count = 3
login_max_processes_count = 128
login_max_logging_users = 256
login_greeting = Dovecot ready.
login_log_format_elements = user=<%u> method=%m rip=%r lip=%l %c
login_log_format = %$: %s
max_mail_processes = 128
default_mail_env = maildir:/mail/%d/%n/
mailbox_idle_check_interval = 10
mail_full_filesystem_access = no
protocol imap {
}
protocol pop3 {
}
auth_executable = /usr/libexec/dovecot/dovecot-auth
auth_debug = yes
auth default {
}

I hope it helps to discover the problem.

Thanks!

On Wed, Jan 25, 2006 at 02:18:53PM +0000, Stroller wrote:
> 
> On 24 Jan 2006, at 12:41, Tim Wagner wrote:
> >I'm using Postfix as MTA, the new messages deliver by postfix to  the 
> >maildir:
> >/mail/domain.tld/userpart/new/
> 
> Does /mail/domain.tld/userpart/new/ have [new|cur|tmp]  subdirectories, please?
> 
> I would normally expect to tell Postfix to deliver to "/path/to/ maildir/" 
> (note trailing slash - I think this is used to indicate  delivery to a maildir 
> rather than a mbox) and have Postfix sort out  the rest. The "new" bit in the 
> end is normally a maildir subfolder  and your IMAP server will move read 
> messages from "/path/to/maildir/ new/" to "/path/to/maildir/cur/" - because the 
> [new|cur|tmp]  subdirectories are standard within the maildir structure you 
> don't  need to mention them in any of your configuration files.
> 
> >Is there a bug known or do i something wrong?
> 
> Well, you could document the problem better. Examples of  configurations files 
> and an `ls -l` showing the full path to a  problem email message might very 
> well help.