- dovecot - dovecot.org

[Dovecot] Custom password encryption scheme, how to do it?
by Madison Kelly 06 Oct '07

06 Oct '07

Hi all, I'm a fairly recent convert to Dovecot/Postfix from Sendmail, so please be gentle (and assume I know nothing). :) I've got a Postfix/Dovecot/PostgreSQL setup with a custom DB schema for my email. This database is also used for a bigger program I use for all my hosting needs (domains, etc.). Currently, I've set it up to use plain-text authentication while I was developing it and getting things running. Now though it's up and running fine, so I want to increase the strength of my passwords that Postfix/Dovecot use. I currently have two fields in a table called 'users'; 'usr_password' which is plain-text and what Postfix/Dovecot currently use and 'usr_strong_password', which stores a stronger hash and is used by the main program. My question is, can I have Postfix/Dovecot use a custom password hashing system? The way I store my strong password (as used by the web-interface) is; - Take the password provided from the user - Read a stored 'salt' value from the database (unique per user and changed on password [re]sets). - Generate an initial SHA256 hash out of the password+salt. - Re-hash the initial SHA256 hash many thousands of times. - Compare the final hash with the hash stored in 'usr_strong_password'. If I can tell Dovecot how to do this, where would I do it? Is there a document/howto/etc someone could point me to? Is there a file I should look at? Thanks all!! Madi

3 3

[Dovecot] saslauth for digest or cram-md5?
by Knute Johnson 06 Oct '07

06 Oct '07

Is it possible to use saslauth for digest-md5 or cram-md5 authentication? If so how would one go about configuring dovecot? Thanks, -- Knute Johnson Molon Labe...

2 1

[Dovecot] imap sort assertion failure
by Andrew Garner 06 Oct '07

06 Oct '07

The following error occurred after a "SORT (TO) US-ASCII ALL" command. This only seems to happen with "to", all our other tests work as expected. Oct 1 20:32:49 dovecot: IMAP(example(a)example.com): pool_data_stack_realloc(): stack frame changed Oct 1 20:32:49 dovecot: IMAP(example(a)example.com): Raw backtrace: imap [0x80c5ed1] -> imap [0x80c5dec] -> imap [0x80cde63] -> imap [0x80c43c0] -> imap(buffer_write+0x85) [0x80c46f5] -> imap(buffer_append+0x26) [0x80c4766] -> imap [0x80be2f5] -> imap(message_header_decode+0x75) [0x80be3d5] -> imap(message_header_decode_utf8+0x56) [0x80be5f6] -> imap [0x80903c4] -> imap(index_mail_get_first_header+0x3e) [0x809125e] -> imap(mail_get_first_header_utf8+0x26) [0x80b4726] -> imap [0x809386b] -> imap [0x8093900] -> imap [0x809414e] -> imap(index_sort_list_finish+0x33) [0x80949d3] -> imap(index_storage_search_next_nonblock+0x3b6) [0x80924a6] -> imap(mailbox_search_next+0x30) [0x80b5b70] -> imap(imap_sort+0xdd) [0x806407d] -> imap(cmd_sort+0x2a4) [0x805d454] -> imap [0x805e7b9] -> imap [0x805e862] -> imap(client_input+0x65) [0x805ee85] -> imap(io_loop_handler_run+0x162) [0x80cc2a2] -> imap(io_loop_run+0x28) [0x80cb628] -> imap(main+0x4ab) [0x806643b] -> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xc Oct 1 20:32:49 dovecot: child 31161 (imap) killed with signal 6 # dovecot -n # 1.1.beta2: /etc/dovecot/dovecot.conf protocols: imap pop3 listen: 127.0.0.1 disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login first_valid_uid: 89 mail_location: maildir:~/Maildir mail_debug: yes mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock mail_executable(default): /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/rawlog /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugins(default): mail_plugins(imap): mail_plugins(pop3): mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 auth default: mechanisms: plain cram-md5 verbose: yes debug: yes debug_passwords: yes passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail

2 1

[Dovecot] Folder renaming oddities.
by Tan Shao Yi 06 Oct '07

06 Oct '07

Hi Timo, We are observing some weird behaviour when we try to rename an inferior folder, followed by the superior folder. These folders have an asterisk in the name. * LIST (\HasChildren) "." "*Own Family" * LIST (\HasChildren) "." "*Own Family.Tour" * LIST (\HasNoChildren) "." "*Own Family.Maid" * LIST (\HasNoChildren) "." "*Own Family.Tour.NZ" a OK List completed. a rename "*Own Family.Tour.NZ" "Own Family.Tour.NZ" a OK Rename completed. a LIST "" * * LIST (\HasChildren) "." "*Own Family" * LIST (\HasNoChildren) "." "*Own Family.Tour" * LIST (\HasNoChildren) "." "*Own Family.Maid" * LIST (\HasNoChildren) "." "Own Family.Tour.NZ" a OK List completed. a rename "*Own Family.Tour" "Own Family.Tour" a rename "*Own Family.Tour" "Own Family.Tour"a NO Internal error occurred. Refer to server log for more information. [2007-10-02 11:02:59] a LIST "" * * LIST (\HasChildren) "." "*Own Family" * LIST (\HasNoChildren) "." "*Own Family.Maid" * LIST (\HasChildren) "." "Own Family.Tour" * LIST (\HasNoChildren) "." "Own Family.Tour.NZ" dovecot: Oct 02 11:02:59 Error: IMAP(XXX): rename(/XXX/Maildir/.*Own Family.TourNZ, /XXX/Maildir/.Own Family.TourNZ) failed: No such file or directory It seems that the renaming of the folder succeeds, though the "a NO Internal error occurred" is reported. However, when the folders do not have an asterisk in the name. * LIST (\HasChildren) "." "Own Family" * LIST (\HasNoChildren) "." "Own Family.Maid" * LIST (\HasChildren) "." "Own Family.Tour" * LIST (\HasNoChildren) "." "Own Family.Tour.NZ" a rename "Own Family.Tour.NZ" "*Own Family.Tour.NZ" a OK Rename completed. a rename "Own Family.Tour" "*Own Family.Tour" a OK Rename completed. a LIST "" * * LIST (\HasChildren) "." "Own Family" * LIST (\HasNoChildren) "." "Own Family.Maid" * LIST (\HasChildren) "." "*Own Family.Tour" * LIST (\HasNoChildren) "." "*Own Family.Tour.NZ" The rename operation completes successfully with no error. Is there something that I am doing wrong? P.S., Will it be possible to also request the mail-log plugin to log rename operations too? :) Thanking in advance. Cheers, Tan Shao Yi

2 2

[Dovecot] Dovecot + OCFS2
by Jon Blazquez 06 Oct '07

06 Oct '07

Hello, We are running Red Hat Enterprise Linux AS release 4 (Nahant Update 4) with OCFS2 for our mail servers. There are three nodes in the cluster with shared storage and OCFS2 filesystem on it. The filesystem is used for mail storage(using Maildir layout) and is accessed by smtpd, pop3 and imap processes(DOVECOT). The system works fine but when there are mailing lists the load increases dramatically. It only occurs when there are mailing lists. We have tested it in lab with good results and now in production we are having some load problems caused by dovecot´s deliver process. In lab we had sent lots of mails but always to a few accounts. It was OK. Now there are sent less mails but there are more accounts. The load increases until it reaches about 100 and only restart fixes the problem. The umounting of the OCFS2 filesystem is not possible even when all process accessing it are killed. Any suggestions? TIA Info: Three nodes. OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4) Mailbox format: Maildir SMTP daemon: Dovecot deliver + Sendmail OCFS2 version: 1.2.5-6 Kernel Version: 2.6.9-42.0.10.ELsmp Pop3 and imap daemon: Dovecot 1.0.3 -- _________________________________________________ Jon Blázquez Diez jblazquez(a)unav.es Servicios Informáticos https://www.unav.es/SI/ Universidad de Navarra https://www.unav.es _________________________________________________

4 4

[Dovecot] Subscribe to root of Maildir namespace?
by Adam Tilghman 06 Oct '07

06 Oct '07

Our users currently make use of a single namespace, mbox format: namespace private { separator = / prefix = hidden = no inbox = yes location = mbox:~/:INBOX=/var/spool/mail/%u:INDEX=/var/spool/poptemp/dovecot/%u } I'd like to give them access to additional Maildir-format storage area, so to the above I've added: namespace private { separator = / prefix = archive/ hidden = no location = maildir:/newmail/%-3.3i/%u/:INDEX=/var/spool/poptemp/dovecot/%u.a-thumper-mail } I can set up subfolders of archive/, and they work as expected. I can also designate the "root" of archive/ as INBOX and that works properly. But "SUBSCRIBE archive" fails. Is it possible to subscribe to the "root" of this new Maildir heirarchy as if it were just another folder? If not, would this be a useful feature to add? Thanks, -- Adam Tilghman | Systems Support / Academic Computing | +1 858 822 0711 agt(a)ucsd.edu | University of California, San Diego | fax +1 858 534 7018

2 1

[Dovecot] problematic ACL with shared folders and maildir
by Dominik L. Borkowski 05 Oct '07

05 Oct '07

Hello, Recently we have been asked to deploy some shared imap folders within our instance of dovecot. However, we ran into a problem with how ACLs are implemented, and consequences regarding maildir++ mailboxes. Long story short: * IMAP clients sees the hierarchy as a tree: sample/1, where 1 is a child of sample * on the filesystem, sample/1 is represented as .sample and .sample.1, both on the same level This presents a problem: dovecot-acl file meant for sample mailbox does not apply to mailbox 1. In fact, a user with permissions to create mailboxes under sample, will not be able to access those mailboxes, once created. Wonder if anybody has been in a similar predicament, and found a solution. Any hints would be greatly appreciated. PS) I'm also documenting this process, maybe others will find it useful: https://collaboration.vbi.vt.edu/display/~dom/dovecot+-+shared+imap+folders -- Dominik L. Borkowski - Senior Systems Administrator Virginia Bioinformatics Institute - www.vbi.vt.edu

1 0

Re: [Dovecot] How to upgrade a running Dovecot?
by Jerry Yeager 05 Oct '07

05 Oct '07

On Oct 5, 2007, at 12:41 PM, dovecot-request(a)dovecot.org wrote: > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 5 Oct 2007 10:25:49 +0100 > From: Mike Brudenell <pmb1(a)york.ac.uk> > Subject: Re: [Dovecot] How to upgrade a running Dovecot? > To: Dovecot Mailing List <dovecot(a)dovecot.org> > Message-ID: <B9A4EC9A-82C0-4250-BC98-606695775041(a)york.ac.uk> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Hi, Jerry/et al - > Hello Mike, (stuff chomped out) > >>> Scenario 2: Altered SSL Certificates >>> ===================================== >>> I need to replace our current certificates and have prepared new >>> files containing the replacement certificate and private key. Am I >>> right in thinking that I can simply modify dovecot.conf to point at >>> the new files and send a HUP signal to dovecot? Specifically, will >>> new connections use the revised certificates, and existing >>> connections continue to work OK without interruption? >> >> Ehh not really, the auth child processes can be killed and new ones >> started. See your next scenario question. > > ...So here you're saying that although the "dovecot" master process > re-reads the configuration file, it doing so has no effect on the > existing authenticator child processes? And is it these processes > that are dealing with the SSL connection? ... I'd have thought it was > either the "imap-login" or "imap" processes? > Just to be clear about this for myself, (instead of relying on the 'ol saying 'that is how it used to work' -- because I am switching over to 1.1 from 1.0.n your question takes on new relevance for me as well) I tested this and yes it works as before, the new files seem to be used for the new connections (all of the dovecot auth processes are killed on the HUP signal -- dovecot itself just rereads the conf file and new auth listeners are started -- assuming that you use Dovecot for the auth mechanism to Postfix) and existing connections seem to handle things okay. I did find something new (or I have not noticed it before) If you kill (not just restart) the Dovecot process itself and restart it with existing connections (someone was connected to IMAPS when you killed Dovecot) Dovecot will not restart, complaining that port 993 is taken already. This happens regardless of the shutdown_clients = yes/no setting. This may be particular to the new version 1.1, I do not know. > Jerry

1 0

[Dovecot] Thunderbird and imap alerts
by Marco De Benedetto 05 Oct '07

05 Oct '07

Is Thunderbird supposed to show alerts sent via post-login scripts as in the wiki example? dovecot-imapd 1.0.5-1 (Debian) Thunderbird (Icedove) 2.0.0.4 (Debian) # dovecot -n|grep 'mail_executable(imap)' mail_executable(imap): /usr/local/sbin/dovecot-alert.sh # cat /usr/local/sbin/dovecot-alert.sh #!/bin/sh echo "* OK [ALERT] Hello World." exec /usr/lib/dovecot/imap Logging in with Thunderbird I get this alert: "Mail server imap.example.org is not an IMAP4 server". -- Thank you, Marco De Benedetto

1 0

Re: [Dovecot] How to upgrade a running Dovecot?
by Jerry Yeager 05 Oct '07

05 Oct '07

> Have you considered sending out a message to each user to the effect that on some day, darned-early a.m. the system will be offline for 30 minutes for maintenance (no incoming email will be lost, etc., etc.). > Message: 3 > Date: Thu, 4 Oct 2007 13:57:03 +0100 > From: Mike Brudenell <pmb1(a)york.ac.uk> > Subject: [Dovecot] How to upgrade a running Dovecot? > To: Dovecot Mailing List <dovecot(a)dovecot.org> > Message-ID: <06B4C604-41E3-4061-96B2-C7C719E21D49(a)york.ac.uk> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Greetings - > > Could someone confirm how to perform various upgrades on a live > system running Dovecot please? > > > Scenario 1: Change to dovecot.conf > =================================== > If I make a change to dovecot.conf am I right in thinking I can > simply send a HUP signal to the main dovecot process to get it to re- > read the configuration file and act on its revised content? > Yes, this is correct. > > Scenario 2: Altered SSL Certificates > ===================================== > I need to replace our current certificates and have prepared new > files containing the replacement certificate and private key. Am I > right in thinking that I can simply modify dovecot.conf to point at > the new files and send a HUP signal to dovecot? Specifically, will > new connections use the revised certificates, and existing > connections continue to work OK without interruption? > > Ehh not really, the auth child processes can be killed and new ones started. See your next scenario question. > Scenario 3: Software Upgrade > ============================= > I build a particular version of Dovecot into the tree /usr/local/ > dovecot-A.B.C and then have a symlink called "dovecot" pointing at > the this directory. To upgrade I can then build the new version > into /usr/local/dovecot-X.Y.Z and test. > > To actually switch over the live service to the new X.Y.Z version do > I need to: > > a) Totally shut down the old A.B.C version of Dovecot, thereby > breaking all > open connections for users? or > > b) Assuming I am using "shutdown_clients = no" can I just kill the > master > "dovecot" process and then start up the new version? > See the preface, do the update when you typically have few folks using the system -- which gives you fewer complaints from users should things break on their end. > Ideally I want existing connections to remain running, but new > connections to start up using the new X.Y.Z version of Dovecot. > > The comment for "shutdown_clients" implies this, but also says: > > "This however means that after master process has died, the > client > processes can't write to log files anymore." > > So if I understand this correctly then with "shutdown_clients = no" > in force then the sequence and behaviour is this? ... > > 1. Old version A.B.C of Dovecot running, clients can log > through the > master "dovecot" process to the logfiles. > > 2. Kill the old master "dovecot" process, start new X.Y.Z > version up. > > 3. New connections get served by version X.Y.Z. > Old connections DON'T get killed and can continue, BUT can > no longer > write anything to the logfiles? > > > With many thanks, > Mike B-) > > -- > The Computing Service, University of York, Heslington, York Yo10 > 5DD, UK > Tel:+44-1904-433811 FAX:+44-1904-433740 > > * Unsolicited commercial e-mail is NOT welcome at this e-mail > address. * > > > > >

4 3