- dovecot - dovecot.org

[Dovecot] ssl certs
by lenny＠edpausa.com 10 Mar '06

10 Mar '06

is it possible to use 2 different sets of ssl certificates, for 2 different hostnames ( e.g. pop.domain.com and imap.domain.com ) ? thank you

4 3

[Dovecot] POP3 extension to accept UIDL ranges?
by Matthias Andree 10 Mar '06

10 Mar '06

Greetings, is anybody aware of an extension to POP3 that supports UIDL ranges? It would be very useful for keep-messages-on-server setups (yes, I know, IMAP4 domain) to be able to do UIDL 21-42 to obtain just these 22 UIDs (this would always have to be a multi-line reply, just like UIDL without argument). If such a thing does not exist yet, perhaps a keyword such as "[X]UIDLRANGES" in the CAPA response might advertise this feature to clients. Regards, -- Matthias Andree

2 2

[Dovecot] Migrating UW-IMAP to Dovecot on Solaris 9
by Bertrand Leboeuf 09 Mar '06

09 Mar '06

In the process of migrating to Dovecot 1.0beta3, any tips or step-by-step instructions that might relate to Solaris 9. Thanks Bertrand Leboeuf leboeuf(a)emt.inrs.ca

2 1

[Dovecot] Two namespaces with same prefix.
by Václav Haisman 09 Mar '06

09 Mar '06

Hi, I have yet another problem. First let me explain my setup. I used to use pine a lot so there are mbox mailboxes in ~/mail. Recently I added a Maildir too and moved most of the mbox mailboxes into Maildir format. Now I thoght it would be nice to have them all "in line" in Thunderbird so I tried this configuration: namespace private { separator = / prefix = location = %h/mbox inbox = yes } namespace private { separator = / prefix = location = maildir:%h/Maildir } The problem is that with this configuration I cannot access the ~/mail/box mailboxes. Thunderbird responds with "Mailbox doesn't exist: box" Is such kind of configuration with two namespaces having same prefix unsupported? Vaclav Haisman

2 1

[Dovecot] Dovecot LDA doesn't build against 1.0beta3
by Luca Corti 09 Mar '06

09 Mar '06

Here's what I get. Btw I'm on Linux/UltraSparc: gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -o deliver deliver.o duplicate.o imparse.o mail-send.o map.o sieve-cmu.o smtpclient.o -Wl,--export-dynamic libsieve/libsieve.a /root/luca/dovecot-1.0.beta3/src/lib-storage/register/libstorage-register.a /root/luca/dovecot-1.0.beta3/src/lib-storage/index/maildir/libstorage_maildir.a /root/luca/dovecot-1.0.beta3/src/lib-storage/index/mbox/libstorage_mbox.a /root/luca/dovecot-1.0.beta3/src/lib-storage/index/dbox/libstorage_dbox.a /root/luca/dovecot-1.0.beta3/src/lib-storage/index/libstorage_index.a /root/luca/dovecot-1.0.beta3/src/lib-index/libindex.a /root/luca/dovecot-1.0.beta3/src/lib-storage/libstorage.a /root/luca/dovecot-1.0.beta3/src/lib-storage/subscription-file/libstorage_subscription_file.a /root/luca/dovecot-1.0.beta3/src/lib-imap/libimap.a /root/luca/dovecot-1.0.beta3/src/lib-mail/libmail.a /root/luca/dovecot-1.0.beta3/src/lib-dict/libdict.a /root/luca/dovecot-1.0.beta3/src/lib-charset/libcharset.a /root/luca/dovecot-1.0.beta3/src/lib/liblib.a -ldl libsieve/libsieve.a(script.o)(.text+0x2e4): In function `sieve_script_parse': /root/luca/dovecot-lda/src/libsieve/script.c:141: undefined reference to `yylineno' libsieve/libsieve.a(script.o)(.text +0x2f8):/root/luca/dovecot-lda/src/libsieve/script.c:141: undefined reference to `yylineno' libsieve/libsieve.a(sieve.o)(.text+0x1184): In function `sieveparse': /root/luca/dovecot-lda/src/libsieve/sieve.c:1311: undefined reference to `sievelex' libsieve/libsieve.a(sieve.o)(.text+0x11bc): In function `sieve_parse': /root/luca/dovecot-lda/src/libsieve/sieve.y:551: undefined reference to `yyrestart' libsieve/libsieve.a(sieve.o)(.text+0x1210): In function `sieveerror': /root/luca/dovecot-lda/src/libsieve/sieve.y:568: undefined reference to `yylineno' libsieve/libsieve.a(sieve.o)(.text +0x1218):/root/luca/dovecot-lda/src/libsieve/sieve.y:568: undefined reference to `yylineno' libsieve/libsieve.a(addr.o)(.text+0x62c): In function `addrparse': /root/luca/dovecot-lda/src/libsieve/addr.c:958: undefined reference to `addrlex' collect2: ld returned 1 exit status make[3]: *** [deliver] Error 1 make[3]: Leaving directory `/root/luca/dovecot-lda/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/luca/dovecot-lda/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/luca/dovecot-lda' make: *** [all] Error 2 thanks -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: Our ISP is having {switching,routing,SMDS,frame relay} problems

2 4

[Dovecot] Dovecot + FreeBSD 6.0 + pam_ldap + nss_ldap
by Frank Bonnet 09 Mar '06

09 Mar '06

Hello all I am new to dovecot and I have some troubles to make it working on a FreeBSD 6.0 box On this machine I have nss_ldap + pam_ldap working to login users but dovecot is not working for "ldap" users, it works only for users that are "really" in /etc/passwd file. I have configured dovecot to use the passwd auth mechanism as the OS is suppose to do the job, but it won't work. See attached my dovecot.conf file. Thanks for any help. -- Regards Frank Bonnet

1 0

[Dovecot] Default SELinux policy on Fedora FC4 prevents dovecot service from starting
by slohcine＠verizon.net 09 Mar '06

09 Mar '06

Hello, I recently setup a Fedora FC4 server to host e-mail and webapps. During the install, I turned on SELinux in active mode. All apps seems to work OK but Dovecot daemon won't start. In the audit log, I see this entry when I try to start the dovecot daemon. type=AVC msg=audit(1141464818.541:40305): avc: denied { read } for pid=1989 comm="dovecot" name=dovecot.pem dev=md2 ino=3646976 scontext=system_u:system_r:dovecot_t tcontext=system_u:object_r:cert_t tclass=file type=PATH msg=audit(1141499436.214:3266533): item=0 name="/etc/pki/dovecot/dovecot.pem" inode=3646976 dev=09:02 mode=0100600 ouid=0 ogid=0 rdev=00:00 I put SELinux into permissive mode and Dovecot works OK. Looks like dovecot does not assume the correct security context when it initializes and reads the cert file. My question for the list is what changes should I make to the SELinux policy to safely permit dovecot to read the file? I'm no expert at SELinux but hoping for some direction, or another way to solve this problem. Ideally, I'd like to keep SELinux in enforcing mode. Many thanks, Eric

2 1

[Dovecot] MySQL problem when using Dovecot as proxy
by Christian Jensen 09 Mar '06

09 Mar '06

Hi, I have just installed Dovecot as a POP3 proxy with great success. Its works flawlessly when i keep to the standard but since I am proxying a Microsoft Exchange 2003 (because the build-in POP3 in MS sux bigtime) I would very much like to use account names like: DOMAIN\username and this doesn't work when I include that in the MySQL table. In the logfile it clearly writes DOMAIN\username so its some kind of translation between dovecot and MYSQL. Any suggestions. I another solution would be to allow all users instead of having to create them in the MySQL table. Is this possible ? /Christian P.S Before Dovecot some Outlook users could only download max. 250kB through POP3 - now with Dovecot there is NO LIMIT! :)

1 0

[Dovecot] :INDEX and :CONTROL in 0.99.14
by Karl Latiss 09 Mar '06

09 Mar '06

Before anyone say "upgrade" for various reasons I can't right now (and at any rate everything else works well with this version). My problem is that I can't get :INDEX and :CONTROL working at all: default_mail_env = maildir:~/:INDEX=/home/dovecot/index/%d/% n:CONTROL=/home/dovecot/control/%d/%n ls -l /home/dovecot/ total 8 drwxrwxrwx 3 dovecot dovecot 4096 Mar 8 07:52 control drwxrwxrwx 3 dovecot dovecot 4096 Mar 8 07:55 index (I've made everything 777 for testing) The error I get is: Mar 8 09:54:26 host imap(user(a)domain.com): mkdir (/home/dovecot/index/domain.com/user/.INBOX) failed: Permission denied If I su to the user(a)domain.com user I can manually create the directory OK. I'm using LDAP for authentication if that makes any difference. Any clues? Pointers? Need more information? -- Karl Latiss <karl.latiss(a)atvert.com.au> Atvert Systems

3 7

[Dovecot] Can I install in the following fashion?
by Stewart Dean 08 Mar '06

08 Mar '06

<permit me my perhaps foolish preference...an explanation> I run mail service for a small college. I've long joked that if someone stole the mail server, the phone would ring before the alarm (which has a 1 minute delay) did, that the user base expected 25x8x367 coverage. Making updates/upgrades to the mail server feels like a tightrope walk with no net. I always appreciated UofWIMAP because there is one binary. Doing and upgrade or backing it out is simplicity itself. I could compile the single binary on my compile machine, test the same binary on my testbed, and then drop it in my production machine and it would work with a minimum of surprises. So portable, so predictable, no security risk of a compiler on a production machine. Of course, /most/ of open source software has all these bits and pieces scattered everywhere. Oh, it may install initially just dandy, but come the day when It's Time For The Upgrade.... 1) can I do it quick and clean and 2) can I recover to what I had before quickly and correctly if the upgrade flops?????? Alas, Dovecot is sprinkled in many, many pieces...but at least, I think (right?) that they are all in the prefix-dir. Gulp. So. I am hoping I can do this: Build/Test Install 1) build/install in /usr/local/dovecot_bld/ Build### in the expectation that everything will be stuck down there. I don't want to put it into /usr/local/ because it will be in there with everything else....no way to get just the dovecot stuff.. 2) tar up the contents of my prefix directory and extract it over on my testbed under /usr/local/dovecot. Notice that the path to dovecot's "stuff" has changed from /usr/local/dovecot_bld/ Build### to /usr/local/dovecot I'm hoping that this won't be a problem. I will point the line in inetd at it and Everything Will Work. 3) Assuming I don't change anything and everything tests out (flawlessly!), I............. Introduction to Production (assuming that all the mailboxes, homedirs and the like have been sorted out) 1) make a tarball of the current working dovecot executables dir (/usr/local/dovecot) 2) extract the tarball there as before on the testbed machine and everything is fine. 2) if the update flops, I can bring back the tarball of the previous Dovecot incarnation My Questions: A) Will this work or are there dependencies I'm not aware of? B) Is there Some Better Way or..... I have this ongoing <ahem> discussion with the Open Source wonks that delight in many, many modules, libraries, etc. I /know/ the reasons a developer would want to do things that way, but, for those of use fielding the application, it's /so/ much easier and success/failure recovery is /so/ much more likely if....there are only one or two or three chunks that we can drop in or quickly back out. I realize that the developer is coding in large part for the utter joy of creating a wondrous, living, breathing edifice of code, that works, that works cleanly, that works as none has before. Yes. But I would think (IMHO) that the developer would receive a greater portion of the ego rush (also a big part of the developer stimulus) of overwhelming application acceptance (and thunderous applause), if he or she made it easy to support and upgrade! You see a sysadmin is so often an utter coward (I confess), who doesn't like unpleasant surprises, whose managment Really Doesn't Like Unpleasant Surprises. When I do my job really well, nobody knows I've done anything. OK...let me have it. -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean(a)bard.edu voice: 845-758-7475, fax: 845-758-7035

6 7