- dovecot - dovecot.org

[Dovecot] Problem report
by leslie.polzer＠gmx.net 31 Oct '06

31 Oct '06

Hello guys, Dovecot is a great IMAP server, I really like it :) I recently found an annoying problem, however: To sync my mail, I use OfflineIMAP, which usually works very smoothly. A spam mail with the year set to 2038 produced the error message "Invalid internal date" when OfflineIMAP tried to upload it to the server. Only deleting the messag helped. The usual data: Dovecot 0.99.14-1sarge0 on Debian Sarge x86. It would be nice to remove this date-smartness (?)... Kind regards, Leslie -- gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 http://nic-nac-project.de/~skypher/

2 1

[Dovecot] Continuing problems with zombied dovecot-auth procs; mail-cache-fields.c IMAP procs crashing
by JB Zimmerman 31 Oct '06

31 Oct '06

Folks- Hans Morten Kind was kind enough to confirm the issue I'm having with large mailboxes and the mail-cache-fields.c file (line 26: unreached error in logs when the imap process crashes out on large Maildirs). Has anyone implemented a fix for this that is both tested and applicable without making manual code changes myself, since I don't trust myself slashing about in source files? Ideally, has this problem been noted for fixing in a newer version? Failing that, if I downgrade to the 0.99 version shipped with RHEL4, has anyone found that to be more reliable? I used the 1.0rc10 in order to gain access to the 'namespace' conf directives so that upgrading from our current Courier Maildir installations would be as seamless as possible, but at the moment, I'm looking at having to roll back to Courier in order to fix this (and the next) problem. Also, we have found that using 1.0rc10 on RHEL4, using pam-ldap for account info and pam-krb for auth, has resulted in the eventual inaccessability of mail due to many zombied and unresponsive dovecot-auth processes. Restarting dovecot the first few times it becomes unresponsive will fix the problem, presumably by instantiating new auth procs, but eventually this no longer works since the restart doesn't actually kill off the zombied auth procs and the socket stops responding. Has anyone run into this problem? Thanks, J.B. Zimmerman RHEL4AS, fully updated, using the AT rpms: dovecot-1.0-0_27.rc10.el4.at --

1 0

[Dovecot] [Patch] vpopmail plaintext passwords
by Remi Gacogne 31 Oct '06

31 Oct '06

Hello, This patch enables APOP and CRAM-MD5 when using vpopmail auth. Remi Gacogne Aqua Ray SARL

2 2

[Dovecot] Multiple certificates
by Phill Edwards 31 Oct '06

31 Oct '06

I have dovecot version 1.0 relese 0.beta8.2.fc5 installed on my FC5 linux box. It acts as an IMAP server to my home LAN. I connect to it from the home PCs over SSL and have installed a certificate in the domain imap.edwards.home to enable this. However, I also use a web site called www.xs2mail.com which retrieves the email from my IMAP server (which has a public DNS entry called XXX.homelinux.com) and displays them in a web interface. I used to run uw-imap and this all worked fine. But since I went to Dovecot I can't use that site any more because it gives me this message: Login failure: Certificate failure for XXX.homelinux.com: self signed certificate: /C=AU/ST=NSW/L=Sydney/O=Edwards/OU=IMAP server/CN=imap.edwards.home/emailAddress=philledwards(a)gmail.com I assume it's getting upset because the certificate is for imap.edwards.home but the domain it's connecting to is XXX.homelinux.com. Is there a way to resolve this? I read something about using virtual servers but all I could find is this in a post somewhere - I don't know which file it goes, where in that file etc: <snip> 1.0-tests support "virtual servers", where this is possible: server foo { listen = 1.2.3.4 ssl_cert_file = /etc/ssl/certs/foo.cer } server bar { listen = 1.2.3.5 ssl_cert_file = /etc/ssl/certs/bar.cer } </snip> Can anyone help me figure this out? (PS - I can't just set up my own IMAP web interface because I can't run anything on port 80 with my ISP and I can't get out of our company firewall on anything other than port 80). Thanks in advance, Phill

3 5

[Dovecot] www.dovecot.org misconfigured?
by Steven F Siirila 30 Oct '06

30 Oct '06

I am having difficulting getting to www.dovecot.org and wiki.dovecot.org. My browser tells me it can't find them. Anyone know what's up? -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs(a)umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593

5 5

[Dovecot] dovecot auth + postifx: how to disable PLAIN and LOGIN without TLS?
by Lev Serebryakov 29 Oct '06

29 Oct '06

Hello dovecot, I want to have all authorization in one place and don't use Cyrus-SASL. I cobfigure postfix 2.3.3 to use dovecot-SASL. I have next lines in main.cf: smtpd_sasl_security_options = noplaintext,noanonymous smtpd_sasl_tls_security_options = noanonymous But PLAIN and LOGIN are advertised by postfix :( Is it bug of postfix or dovecot-auth? I don't want to disable these mechanisms in auth {} stanza of dovecot.conf, because they are Ok over SSL/TLS. It works for dovecot-pop3 and dovecot-imap, but not for postfix :( postfix 2.3.3, dovecot 1.0rc10. -- Best regards, Lev mailto:lev@serebryakov.spb.ru

3 4

[Dovecot] LSUB and namespaces - how to get rid of multible prefixes
by Henrik Ostergaard Madsen 28 Oct '06

28 Oct '06

I'm using dovecot 1.0.rc7 and Squirrelmain 1.4.8 using IMAP on a Debian 3.1 Testing system, and I'm having a problem. When Squirrelmail (or other IMAP clients) submits an LSUB "" "*%", dovecot responds with: Request: A004 LSUB "" "*%" Response: * LSUB () "/" "INBOX.Sent" * LSUB () "/" "INBOX.Trash" * LSUB () "/" "INBOX.Drafts" * LSUB () "/" "mail/Sent" * LSUB () "/" "mail/Trash" * LSUB () "/" "mail/Drafts" * LSUB () "/" ".mail/Sent" * LSUB () "/" ".mail/Trash" * LSUB () "/" ".mail/Drafts" * LSUB () "/" "Sent" * LSUB () "/" "Trash" * LSUB () "/" "Drafts" * LSUB () "/" "INBOXSent" * LSUB () "/" "INBOXTrash" * LSUB () "/" "INBOXDrafts" * LSUB () "/" "./INBOX.Sent" * LSUB () "/" "./INBOX.Trash" * LSUB () "/" "./INBOX.Drafts" * LSUB () "/" "Test" Lsub completed. This is in spite of that only INBOX.Sent, INBOX.Trash, INBOX.Drafts and Test actually exists. I have tried with no explicit namespaces, only one with no prefix or with prefix "/", and with that again and all the above prefixes marked as hidden, but with absolutely no change in the LSUB repons. Due to this, Squirrelmail shows up a whole bunch of folders, but only the correct ones (without prefixes) works.. This has been the same with a few prior versions of dovecot 1.0 , but not with dovecot 0.99. It is the same for Squirrelmail 1.4.7, but I do not think the client matters.. Is there a setting or way to deal with this - or is it a bug? Regards, Henrik

2 2

[Dovecot] "dovecot dead but subsys locked" problem
by Carla Tironi Farinati 27 Oct '06

27 Oct '06

Hi, Following the advice of someone really helpfull here, I just installed Postfix/Dovecot (from rpms). I'm running CentOs 4.4. I followed this guide: http://www.howtoforge.com/linux_postfix_virtual_hosting I've got two problems, a)my server is now listed as RCB, whatever that means, I suppose that's close to spamming. "0: Connection refused. Your IP address is blocked(Spamhaus XBL) - see http://www.spamhaus.org/query/bl?ip=216.32.68.90 " b)[root@server ssl]# /etc/init.d/dovecot restart Stopping Dovecot Imap: [FAILED] Starting Dovecot Imap: [ OK ] [root@server ssl]# /etc/init.d/dovecot status dovecot dead but subsys locked I deleted the sybsys file and tried to restart it. It crashes and show the error agsin. The logs don't show up anything unusual. I also see in the logs: Oct 25 22:50:07 server postfix/virtual[24712]: 48BA5904990: to=<carlatf(a)ithaki.net>, relay=virtual, delay=1, status=deferred (mailbox /var/spool/vmail/ithaki.net/carlatf: cannot open file: Is a directory) Of course it's a directory!. I created it following the guide! I reinstalled Dovecot with the latest sources and nothing. I also turn off SSL from dovecot's config file, nothing. Any ideas dovecot gurus!? Best regards, Carla

4 4

[Dovecot] Clustering (replication and proxying) plans for the future
by Timo Sirainen 27 Oct '06

27 Oct '06

I wrote this mostly so that I won't forget my thoughts. Most likely won't be implemented anytime soon. I haven't thought through all the locking issues. It would require a distributed lock manager in any case. I think there are already several existing ones, so one of them could probably be used for Dovecot. Each mail server would consult a master server for getting namespace configuration and location for shared/public mailboxes. If the data is stored in some central SQL server there could just as well be multiple master servers (or even each server be their own master). Whenever trying to open a shared mailbox that doesn't exist in the current server, the imap process would automatically create a new connection for the destination server and start proxying the data. The proxy would be a somewhat dummy proxy, which just forwards the client's commands to it and doesn't even try to understand the replies from the remote server. So admin will have to be careful to use only servers which have all the capabilities that were announced by the original server. So, then the replication. Each namespace could be configured to be available either by proxying or by replication: namespace public { prefix = example/ location = proxy:imap.example.com } namespace public { prefix = example/ replicated_to = host1.example.com host2.example.com # If multi-master, we'll need to use global locking. If not, the # replicated_to servers contain only slaves. multi_master = yes location = maildir:~/Maildir } The way this would work is that each imap process connects via UNIX socket to a replication process, which gets input from all the imap processes. The replication process keeps track of how much has been sent to each other server and also the acks it has received from them. So if the network dies temporarily it'll start writing the changes to the disk until it reaches some limit, after which a complete resync will be necessary. Dovecot already writes all the changes to a mailbox first to a transaction log file and and only afterwards it updates the actual mailbox. The contents of the new mails aren't stored there though. The replication could work simply by sending the transaction logs' contents to the replicatio process which passes it onto other servers, which finally sync their local mailboxes based on that data. Since Dovecot already is able to sync mailboxes based on the transaction log's contents this should be pretty easy to implement. Of course the new mails' contents also have to be sent. This could be prioritized lower than the transaction traffic, so that each server always has very up-to-date view of the mailbox metadata, but not necessarily the contents of all the mails. If the server finds itself in a situation that it doesn't have some specific mail, it'll send a request to the replication process to fetch it ASAP from another server. The reply will then take the highest priority in the queue. Normally when opening or reading the mailbox there's really no need to do any global locking. The server will show the mailbox's state to be what it has last received from the replication process. Whenever modifying the mailbox a global lock is required. Here's also the problem that if the network is down between two servers, they both think that they got the global lock. If they did any conflicting changes, they'll have to be resolved when both of them again see each others. Dovecot's transactions in general aren't order-dependent so most of the conflicts can be resolved by just having the replication master decide which way the transactions were done and then sending the transactions back to all of the servers in that order. Adding new messages is a problem however. UIDs must be always growing and they must be unique. I think Cyrus solved this by having 64bit global UIDs which really uniquely identify the messages (ie. first 32bits contain server-specific UID), and then the 32bit IMAP UIDs. If there are any conflicts with the IMAP UIDs, they're given new UIDs (which invalidates clients' cache for those messages, but that can't be helped). Resyncing works basically by requesting a list of all the mailboxes, opening each one of them and requesting new transactions from the log files with <UID validity>, <log file sequence>, <log file offset> triplet. If UID validity has changed or log file no longer exists, a full resync needs to be done. Also if the log file contains a lot of changes, it's probably faster to do a full resync. Full resync would then be just sending the whole dovecot.index file. Conflict resolving could also require a full resync if transaction logs were lost. That'd work again by the master receiving everyone's dovecot.index files, deciding what to do with them and sending the modified version back to everyone. Each server has different transaction logs, so the log file sequences can't be directly used between servers. So the replication process probably will have to keep track of every server's log seq/offset. Also when receiving full dovecot.index files they'll have to be updated in some way. Then there's the problem of how to implement the receiving side. If the user already has a process connected to the replication process it could be instructed to update the mailboxes. But since this doesn't happen all that often, there also needs to be some replication-writer process which writes all the received transactions to the mailboxes. Now, when exactly should these replication-writer processes be created then? If all users have the same UNIX user ID, then there could be a spool of processes always running and doing the writing. Although this worries me a bit since the same process is handling different users' data. More secure way, and the only way if users have different UNIX UIDs, is to launch a separate writer process for each user. It probably isn't a great idea to do that immediately when receiving data for a user, but to queue data for the user for a while and then once enough has been received or some timeout has occurred, the writer process would be executed. There probably should be some shared in-memory cache with a memory limit of some megabytes, after which data is written to disk up to a configurable amount. Only after that is full or timeout for the user is reached, the writer process is executed and the data is sent to it. All this replication stuff could also be used to implement a remote mail storage (ie. smarter proxying). The received indexes/transactions could simply be kept in memory, and all the mails that aren't already cached in memory could just be requested from the master whenever needed. I'm not sure if there's much point in doing this over dummy proxying though.

2 2

[Dovecot] dovecot.org not resolving!
by /dev/rob0 27 Oct '06

27 Oct '06

I had to bypass my unknown sender/recipient domain restrictions to receive list mail and send this. It's hard to say without a whois server for .fi, but it appears that the problem might be with the procontrol.fi. domain. Action to fix the problem is needed ASAP! I've emailed Timo offlist; also tried to get him in IRC. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header

2 1