- dovecot - dovecot.org

[Dovecot] debian unstable : mutt polling imap mailboxes
by Kai Hendry 02 Mar '04

02 Mar '04

Package: dovecot Version: 0.99.10.4-2 I am accessing my IMAP folder on my ~/Maildir using mutt via Dovecot and I have this problem whereby mutt incorrectly reports I have new mail in a "mailboxes" polled mailbox. This happens all the time when I press the key bound to change mailbox. I use courier IMAP at school, and I have not experienced this problem. A bug with dovecot or mutt?

3 3

[Dovecot] Dovecot failing silently on startup
by Julian Melville 02 Mar '04

02 Mar '04

I'm puzzled... I'm running the Debian package of Dovecot 0.99.10.4 on a Debian (testing) server, and it's basically doing nothing on startup for an extended period. After a while (maybe 10 minutes or more) it all suddenly starts working, all without logging anything untoward. All the dovecot processes appear to start OK, and 'Dovecot starting up' is logged to the syslog. If you telnet to an IMAP or POP3 port at this point, it will successfully connect but there's no response (i.e. no '* OK dovecot ready'). Nothing else on this server is failing in this way; e.g. Apache and PostgreSQL are running fine throughout this period. Has anyone else seen anything like this? Cheers, Julian.

2 1

[Dovecot] severe problem
by Ewald Geschwinde 01 Mar '04

01 Mar '04

I have debian knoppix and postfix + dovecot imap My problem is the following: Feb 29 18:51:14 cybserv imap-login: Login: xx(a)xxx.xx [xx.xx.xx.xx] Feb 29 18:51:14 cybserv dovecot: child 13959 (imap) killed with signal 11 Feb 29 18:52:41 cybserv imap-login: Disconnected [xx.xxx.xx.xx] Feb 29 18:52:41 cybserv dovecot: child 13952 (login) killed with signal 11 I'm using the debian package for the version 0.99.10.4-2 Always when someone tries to login the server throws this error I don't know whats going wrong I'm using a postgresql backend Regards Ewald Geschwinde

2 1

[Dovecot] SSL 143/notls stuff
by Mark Williamson 27 Feb '04

27 Feb '04

Hi Everyone, Just trying to work out how totally disable SSL/TLS support on port 143 while enabling SSL support on port 993 In the config file when I comment out the setting "ssl_disable = yes", I have Webmail client that will no longer be able to auth against port 143, Now I can get the Webmail client to sort of work via using the setting the port to "143/notls" but the main problem with that is that the WEbmail client does not support that setting correctly, giving the Webmail issues in other areas. Anyway is there a way of enabling SSL support on 993, and a way to let port 143 to auth with out the need of using a setting port "143/notls" Cheers Mark Williamson

2 3

[Dovecot] [OT] How is the Changelog file created?
by Sven Kirmess 26 Feb '04

26 Feb '04

How is the Changelog file created? I assume there is a tool which grabs this information from the CVS repository. What's the name of this tool? Sven

3 3

[Dovecot] Set only INDEX path
by Kilian CAVALOTTI 26 Feb '04

26 Feb '04

Hi folks, I'd like to know if I can set the INDEX path in the default_mail_env, without setting the format and location of mailboxes (something like default_mail_env = :INDEX=/var/mail/indexes/%u) I want to let each user choose whether he prefers to store his mail in mbox or maildir format, so I don't want to /force/ the configuration in the default_mail_env variable, but let the autodetection feature of Dovecot do the job. The problem is that home folders are NFS mounted on the mail server. So I'd like to put the indexes somewhere locally on the mail server. I tried to set the default_mail_env with various combinations of ':' and INDEX, but with no success, I invariably get "Fatal: Failed to create storage with data..." error messages. Is there any solution to my problem ? ;) TIA, -- Kilian

1 0

[Dovecot] More than one auth method with dovevot 0.99.10.4 - how?
by Raymond Scholz 25 Feb '04

25 Feb '04

We're setting up a server with qmail/vpopmail and dovecot. In addition to vpopmail users we want non-virtual, local users to be able to authenticate and have them read the Maildir in their real $HOME. vpopmail userdb/passwd works fine. Now how do I tell dovecot to use passwd (or PAM) userdb/passdb authentication too? /etc/dovecot.conf: [...] auth = default auth_mechanisms = plain auth_userdb = vpopmail auth_passdb = vpopmail auth_user = root auth_verbose = yes auth = local auth_mechanisms = plain auth_userdb = passwd /etc/passwd auth_passdb = pam auth_user = root auth_verbose = yes #auth_methods = default local EOF I think, I'm supposed to put the auth_methods line somewhere. Without it, dovecot only tries authentication using the first auth process definition: | Feb 25 00:01:49 server1 dovecot-auth: vpopmail(rscholz): unknown user (rscholz@) after loggin in with ". login rscholz secret_password" at the IMAP server. Putting the auth_methods line behind the two auth processes (or somewhere in the middle) gives me: | Starting mail server: dovecotFatal: Error in configuration file /etc/dovecot.conf line 456: Unknown setting: methods Putting it above all auth processes gives me: | Starting mail server: dovecotFatal: Error in configuration file /etc/dovecot.conf line 362: Authentication process name not defined yet Hm, I'm lost here. System is Debian i386 stable (woody) with dovecot_0.99.10.4-2.deb backported from Debian unstable. Cheers, Ray -- Hfr fgebat rapelcgvba!

2 2

[Dovecot] Mailbox formats
by Kenneth Porter 25 Feb '04

25 Feb '04

I'm currently using mbox and mbx with UW-IMAP, mbox for space efficiency and mbx for folders with lots of messages for time efficiency without a large space cost. I've avoided maildir because it has a relatively high space cost; mbox has no inter-message cost while maildir wastes on average half a sector plus an inode for each message. What other formats are there, and has anyone come up with a good format that gives both good time and space characteristics without sacrificing reliability? (I'm aware of the file format list in the UW-IMAP distro: <http://www.washington.edu/imap/documentation/formats.txt.html>)

2 2

[Dovecot] Pam trouble
by Benjamin Dabelow 25 Feb '04

25 Feb '04

Hi folks, I can't get dovecot to authenticate properly against ldap/pam. I've been fiddling with it for several days now, to no avail. It keeps crashing with: Child died with signal 11 The system is Solaris9. Enclosed is a trace of dovecot-auth for a connection to pop with correct username and password and my config. Any help is appreciated. Cheers Benjamin Trace----------------------------------------------------- 29964: poll(0x00052E28, 9, 4999) (sleeping...) 29964: poll(0x00052E28, 9, 4999) = 0 29964: poll(0x00052E28, 9, 0) = 0 29964: poll(0x00052E28, 9, 4999) (sleeping...) 29964: poll(0x00052E28, 9, 4999) = 1 29964: accept(3, 0xFFBFFAD0, 0xFFBFFAC8, 1) = 13 29964: fstat64(13, 0xFFBFF920) = 0 29964: getsockopt(13, SOL_SOCKET, 0x2000, 0xFFBFFA20, 0xFFBFFA1C, 0) = 0 29964: setsockopt(13, SOL_SOCKET, 0x2000, 0xFFBFFA20, 4, 0) = 0 29964: fcntl(13, F_SETFL, 0x00000080) = 0 29964: fstat64(13, 0xFFBFF9D8) = 0 29964: llseek(13, 0, SEEK_CUR) Err#29 ESPIPE 29964: getsockname(13, 0xFFBFF928, 0xFFBFF924, 1) = 0 29964: write(13, "\0\0 u\f\0\0\001", 8) = 8 29964: poll(0x00052E28, 10, 2917) = 1 29964: read(13, "\0\0 u1C", 4096) = 4 29964: poll(0x00052E28, 10, 2917) (sleeping...) 29964: poll(0x00052E28, 10, 2917) = 0 29964: poll(0x00052E28, 10, 0) = 0 29964: poll(0x00052E28, 10, 4999) (sleeping...) 29964: poll(0x00052E28, 10, 4999) = 1 29964: read(14, "\0\0\001\0\0\001\0\0\001".., 4092) = 16 29964: write(14, "\0\0\001\0\0\001\0\0\0\0".., 20) = 20 29964: poll(0x00052E28, 10, 1664) = 1 29964: read(14, "\0\0\002\0\0\001\0\0\011".., 4076) = 29 29964: pipe() = 15 [16] 29964: fork1() = 29981 29964: lwp_schedctl(SC_STATE|SC_PREEMPT, 0, 0xFFBFF7AC) = 0 29964: close(16) = 0 29981: fork1() (returning as child ...) = 29964 29981: getpid() = 29981 [29964] 29981: close(15) = 0 29981: lwp_schedctl(SC_STATE|SC_PREEMPT, 0, 0xFFBFF4A4) = 0 29981: open("/etc/pam_debug", O_RDONLY) Err#2 ENOENT 29981: stat64("/etc/pam.conf", 0xFFBFF4C0) = 0 29981: open("/etc/pam.conf", O_RDONLY) = 15 29981: mmap(0x00000000, 1893, PROT_READ, MAP_PRIVATE, 15, 0) = 0xFEBA0000 29981: munmap(0xFEBA0000, 1893) = 0 29981: close(15) = 0 29981: stat64("/usr/lib/security/pam_unix.so.1", 0xFFBFF400) = 0 29981: stat("/usr/lib/security/pam_unix.so.1", 0xFFBFED44) = 0 29981: open("/usr/lib/security/pam_unix.so.1", O_RDONLY) = 15 29981: fstat(15, 0xFFBFED44) = 0 29981: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 15, 0) = 0xFEBA0000 29981: mmap(0x00000000, 212992, PROT_READ|PROT_EXEC, MAP_PRIVATE, 15, 0) = 0xFEB40000 29981: mmap(0xFEB6A000, 36767, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 15, 106496) = 0xFEB6A000 29981: munmap(0xFEB5A000, 65536) = 0 29981: resolvepath("/usr/lib/security/pam_unix.so.1", "/usr/lib/security/pam_unix.so.1", 1023) = 31 29981: memcntl(0xFEB40000, 24652, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 29981: close(15) = 0 29981: stat("/usr/lib/libc.so.1", 0xFFBFEC84) = 0 29981: stat("/usr/lib/libpam.so.1", 0xFFBFEC84) = 0 29981: stat("/usr/lib/libnsl.so.1", 0xFFBFEC84) = 0 29981: stat("/usr/lib/libcmd.so.1", 0xFFBFEC84) = 0 29981: stat("/usr/lib/libmp.so.2", 0xFFBFEC84) = 0 29981: munmap(0xFEBA0000, 8192) = 0 29981: stat64("/usr/lib/security/pam_openldap.so.1", 0xFFBFF400) = 0 29981: stat("/usr/lib/security/pam_openldap.so.1", 0xFFBFED44) = 0 29981: open("/usr/lib/security/pam_openldap.so.1", O_RDONLY) = 15 29981: fstat(15, 0xFFBFED44) = 0 29981: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 15, 0) = 0xFEBA0000 29981: mmap(0x00000000, 106496, PROT_READ|PROT_EXEC, MAP_PRIVATE, 15, 0) = 0xFEB20000 29981: mmap(0xFEB38000, 3928, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 15, 32768) = 0xFEB38000 29981: munmap(0xFEB2A000, 57344) = 0 29981: resolvepath("/usr/lib/security/pam_openldap.so.1", "/usr/lib/security/pam_openldap.so.1", 1023) = 35 29981: memcntl(0xFEB20000, 6704, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 29981: close(15) = 0 29981: stat("/opt/OpenLDAP2/lib/libc.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libc.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libc.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libldap.so.2", 0xFFBFEC84) = 0 29981: mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFEB10000 29981: stat("/opt/OpenLDAP2/lib/liblber.so.2", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libnsl.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libnsl.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libnsl.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libcrypt_i.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libcrypt_i.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libcrypt_i.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libresolv.so.2", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libresolv.so.2", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libresolv.so.2", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libpam.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libpam.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libpam.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libdl.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libdl.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libdl.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libpthread.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libpthread.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libpthread.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/librt.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/librt.so.1", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/librt.so.1", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libdb-4.0.so", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libdb-4.0.so", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/lib/libdb-4.0.so", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libssl.so.0.9.7", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libssl.so.0.9.7", 0xFFBFEC84) = 0 29981: stat("/opt/OpenLDAP2/lib/libcrypto.so.0.9.7", 0xFFBFEC84) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libcrypto.so.0.9.7", 0xFFBFEC84) = 0 29981: munmap(0xFEBA0000, 8192) = 0 29981: open64("/var/run/name_service_door", O_RDONLY) = 15 29981: fcntl(15, F_SETFD, 0x00000001) = 0 29981: door_info(15, 0xFEEC2668) = 0 29981: close(15) = 0 29981: stat("/usr/lib/nss_files.so.1", 0xFFBFDE64) = 0 29981: open("/etc/passwd", O_RDONLY) = 15 29981: fstat64(15, 0xFFBFE2D8) = 0 29981: brk(0x00081460) = 0 29981: brk(0x00083460) = 0 29981: fstat64(15, 0xFFBFE180) = 0 29981: ioctl(15, TCGETA, 0xFFBFE264) Err#25 ENOTTY 29981: read(15, " r o o t : x : 0 : 1 : Z".., 8192) = 710 29981: read(15, 0x00080594, 8192) = 0 29981: llseek(15, 0, SEEK_CUR) = 710 29981: close(15) = 0 29981: stat("/usr/lib/nss_ldap.so.1", 0xFFBFDE64) = 0 29981: open("/usr/lib/nss_ldap.so.1", O_RDONLY) = 15 29981: fstat(15, 0xFFBFDE64) = 0 29981: mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 15, 0) = 0xFEBA0000 29981: mmap(0x00000000, 163840, PROT_READ|PROT_EXEC, MAP_PRIVATE, 15, 0) = 0xFEAE0000 29981: mmap(0xFEAFC000, 4828, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 15, 49152) = 0xFEAFC000 29981: mmap(0xFEAFE000, 35640, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFEAFE000 29981: munmap(0xFEAEE000, 57344) = 0 29981: resolvepath("/usr/lib/nss_ldap.so.1", "/usr/lib/nss_ldap.so.1", 1023) = 22 29981: memcntl(0xFEAE0000, 9792, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 29981: close(15) = 0 29981: stat("/opt/OpenLDAP2/lib/libldap.so.2", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/liblber.so.2", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libdb-4.0.so", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libdb-4.0.so", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/lib/libdb-4.0.so", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libdl.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libdl.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/lib/libdl.so.1", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libnsl.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libnsl.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/lib/libnsl.so.1", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libresolv.so.2", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libresolv.so.2", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/lib/libresolv.so.2", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libpthread.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libpthread.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/lib/libpthread.so.1", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/librt.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/librt.so.1", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/lib/librt.so.1", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libssl.so.0.9.7", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libssl.so.0.9.7", 0xFFBFDDA4) = 0 29981: stat("/opt/OpenLDAP2/lib/libcrypto.so.0.9.7", 0xFFBFDDA4) Err#2 ENOENT 29981: stat("/usr/local/ssl/lib/libcrypto.so.0.9.7", 0xFFBFDDA4) = 0 29981: munmap(0xFEBA0000, 8192) = 0 29981: sigaction(SIGPIPE, 0xFFBFE2B8, 0xFFBFE3F8) = 0 29981: sigprocmask(SIG_SETMASK, 0xFEBEA0B4, 0xFFBFE308) = 0 29981: sigprocmask(SIG_SETMASK, 0xFFBFE2F4, 0x00000000) = 0 29981: getpid() = 29981 [29964] 29981: getuid() = 0 [0] 29981: open("/etc/ldap.conf", O_RDONLY) = 15 29981: fstat64(15, 0xFFBFCA38) = 0 29981: fstat64(15, 0xFFBFC8E0) = 0 29981: ioctl(15, TCGETA, 0xFFBFC9C4) Err#25 ENOTTY 29981: read(15, " # @ ( # ) $ I d : l".., 8192) = 6190 29981: read(15, 0x0008018C, 8192) = 0 29981: llseek(15, 0, SEEK_CUR) = 6190 29981: close(15) = 0 29981: open64("/var/run/name_service_door", O_RDONLY) = 15 29981: fcntl(15, F_SETFD, 0x00000001) = 0 29981: door_info(15, 0xFEEC2668) = 0 29981: close(15) = 0 29981: open("/etc/inet/ipnodes", O_RDONLY) = 15 29981: fstat64(15, 0xFFBFADA8) = 0 29981: brk(0x00083460) = 0 29981: brk(0x00085460) = 0 29981: fstat64(15, 0xFFBFAC50) = 0 29981: ioctl(15, TCGETA, 0xFFBFAD34) Err#25 ENOTTY 29981: read(15, " #\n # I n t e r n e t".., 8192) = 61 29981: read(15, 0x0008257C, 8192) = 0 29981: llseek(15, 0, SEEK_CUR) = 61 29981: close(15) = 0 29981: open64("/var/run/name_service_door", O_RDONLY) = 15 29981: fcntl(15, F_SETFD, 0x00000001) = 0 29981: door_info(15, 0xFEEC2668) = 0 29981: close(15) = 0 29981: open("/etc/hosts", O_RDONLY) = 15 29981: fstat64(15, 0xFFBFAD28) = 0 29981: fstat64(15, 0xFFBFABD0) = 0 29981: ioctl(15, TCGETA, 0xFFBFACB4) Err#25 ENOTTY 29981: read(15, " #\n # I n t e r n e t".., 8192) = 107 29981: read(15, 0x0008257C, 8192) = 0 29981: llseek(15, 0, SEEK_CUR) = 107 29981: close(15) = 0 29981: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 15 29981: setsockopt(15, tcp, TCP_NODELAY, 0xFFBFD724, 4, 1) = 0 29981: fcntl(15, F_GETFL, 0xFF1FE9E0) = 2 29981: fstat64(15, 0xFFBFD468) = 0 29981: getsockopt(15, SOL_SOCKET, 0x2000, 0xFFBFD568, 0xFFBFD560, 0) = 0 29981: fstat64(15, 0xFFBFD4D8) = 0 29981: getsockopt(15, SOL_SOCKET, 0x2000, 0xFFBFD5D8, 0xFFBFD5D4, 0) = 0 29981: setsockopt(15, SOL_SOCKET, 0x2000, 0xFFBFD5D8, 4, 0) = 0 29981: fcntl(15, F_SETFL, 0x00000082) = 0 29981: connect(15, 0x0007F9E8, 16, 1) = 0 29981: fcntl(15, F_GETFL, 0xFF1FE9F8) = 130 29981: fstat64(15, 0xFFBFD468) = 0 29981: getsockopt(15, SOL_SOCKET, 0x2000, 0xFFBFD568, 0xFFBFD560, 0) = 0 29981: fstat64(15, 0xFFBFD4D8) = 0 29981: getsockopt(15, SOL_SOCKET, 0x2000, 0xFFBFD5D8, 0xFFBFD5D4, 0) = 0 29981: setsockopt(15, SOL_SOCKET, 0x2000, 0xFFBFD5D8, 4, 0) = 0 29981: fcntl(15, F_SETFL, 0x00000002) = 0 29981: getpeername(15, 0xFFBFD708, 0xFFBFD2E8, 1) = 0 29981: open64("/var/run/name_service_door", O_RDONLY) = 17 29981: fcntl(17, F_SETFD, 0x00000001) = 0 29981: door_info(17, 0xFEEC2668) = 0 29981: close(17) = 0 29981: open("/etc/inet/ipnodes", O_RDONLY) = 17 29981: fstat64(17, 0xFFBFAC98) = 0 29981: fstat64(17, 0xFFBFAB40) = 0 29981: ioctl(17, TCGETA, 0xFFBFAC24) Err#25 ENOTTY 29981: read(17, " #\n # I n t e r n e t".., 8192) = 61 29981: read(17, 0x0008257C, 8192) = 0 29981: llseek(17, 0, SEEK_CUR) = 61 29981: close(17) = 0 29981: open64("/var/run/name_service_door", O_RDONLY) = 17 29981: fcntl(17, F_SETFD, 0x00000001) = 0 29981: door_info(17, 0xFEEC2668) = 0 29981: close(17) = 0 29981: open("/etc/hosts", O_RDONLY) = 17 29981: fstat64(17, 0xFFBFAC18) = 0 29981: fstat64(17, 0xFFBFAAC0) = 0 29981: ioctl(17, TCGETA, 0xFFBFABA4) Err#25 ENOTTY 29981: read(17, " #\n # I n t e r n e t".., 8192) = 107 29981: llseek(17, 0, SEEK_CUR) = 107 29981: close(17) = 0 29981: uname(0xFFBFD110) = 1 29981: time() = 1077620847 29981: write(15, " 01D020101 w188016 1 . 3".., 31) = 31 29981: poll(0xFFBFD1C0, 1, -1) = 1 29981: read(15, " 0\f020101 x07\n", 8) = 8 29981: read(15, "01\004\004\0", 6) = 6 29981: time() = 1077620847 29981: brk(0x00085460) = 0 29981: brk(0x00087460) = 0 29981: brk(0x00087460) = 0 29981: brk(0x00089460) = 0 29981: brk(0x00089460) = 0 29981: brk(0x0008B460) = 0 29981: brk(0x0008B460) = 0 29981: brk(0x0008D460) = 0 29981: time() = 1077620847 29981: getpid() = 29981 [29964] 29981: brk(0x0008D460) = 0 29981: brk(0x00093460) = 0 29981: brk(0x00093460) = 0 29981: brk(0x00097460) = 0 29981: brk(0x00097460) = 0 29981: brk(0x0009B460) = 0 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: open("/dev/urandom", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 17 29981: poll(0xFFBFD3B0, 1, 10) = 1 29981: read(17, "029F\0 XA5B2F0C7 U &1FE6".., 32) = 32 29981: close(17) = 0 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getuid() = 0 [0] 29981: getpid() = 29981 [29964] 29981: time() = 1077620847 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: write(15, "8095010301\0 l\0\0\0 \0".., 151) = 151 29981: read(15, "160301\0 J02\0", 7) = 7 29981: brk(0x0009B460) = 0 29981: brk(0x0009D460) = 0 29981: time() = 1077620847 29981: time() = 1077620847 29981: getpid() = 29981 [29964] 29981: read(15, "\0 F0301 @ ; 0 oBFEE1DE1".., 72) = 72 29981: read(15, "1603010412", 5) = 5 29981: read(15, "\v\0040E\004\v\004\b 082".., 1042) = 1042 29981: brk(0x0009D460) = 0 29981: brk(0x0009F460) = 0 29981: getpid() = 29981 [29964] 29981: read(15, "160301\004", 5) = 5 29981: read(15, "0E\0\0\0", 4) = 4 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: getpid() = 29981 [29964] 29981: brk(0x0009F460) = 0 29981: brk(0x000A1460) = 0 29981: write(15, "160301\08610\0\082\080 /".., 198) = 198 29981: read(15, "140301\001", 5) = 5 29981: read(15, "01", 1) = 1 29981: read(15, "160301\0 0", 5) = 5 29981: read(15, "9197ADECFE9AFB )DF83 $8A".., 48) = 48 29981: time() = 1077620847 29981: write(15, "170301\0 DF0F1E H pC386".., 90) = 90 29981: time() = 1077620847 29981: poll(0xFFBFD230, 1, 30000) = 1 29981: read(15, "170301\0 ", 5) = 5 29981: read(15, "DBFFF9B9EC g WEE iE0 , Z".., 32) = 32 29981: read(15, "170301\0 0", 5) = 5 29981: read(15, "7F >BDCE96B4 = zE587F1 ]".., 48) = 48 29981: time() = 1077620847 29981: setsockopt(15, SOL_SOCKET, SO_KEEPALIVE, 0xFFBFDB88, 4, 1) = 0 29981: fcntl(15, F_SETFD, 0x00000001) = 0 29981: getsockname(15, 0xFEAFE2F8, 0xFFBFDB84, 1) = 0 29981: getpeername(15, 0xFEAFE308, 0xFFBFDB84, 1) = 0 29981: time() = 1077620847 29981: getpid() = 29981 [29964] 29981: getuid() = 0 [0] 29981: time() = 1077620847 29981: write(15, "170301\0 $1D1086B7 { #".., 266) = 266 29981: poll(0xFFBFD1E0, 1, -1) = 1 29981: read(15, "170301\0 ", 5) = 5 29981: read(15, " 3 0 @B7AA14 j9284E2D4\t".., 32) = 32 29981: read(15, "1703010180", 5) = 5 29981: read(15, "92 | e850589C27F <CDB0 a".., 384) = 384 29981: poll(0xFFBFD1E0, 1, -1) = 1 29981: read(15, "170301\0 ", 5) = 5 29981: read(15, "DABDA1 `8DBDD795B117E4D3".., 32) = 32 29981: read(15, "170301\0 0", 5) = 5 29981: read(15, "8AA2B9 y1A MFEC3FCDB J".., 48) = 48 29981: time() = 1077620847 29981: time() = 1077620847 29981: stat("/usr/lib/nss_files.so.1", 0xFFBFE2D4) = 0 29981: open("/etc/shadow", O_RDONLY) = 17 29981: fstat64(17, 0xFFBFE878) = 0 29981: fstat64(17, 0xFFBFE720) = 0 29981: ioctl(17, TCGETA, 0xFFBFE804) Err#25 ENOTTY 29981: read(17, " r o o t : f s i o o X 9".., 8192) = 308 29981: read(17, 0x0008CB34, 8192) = 0 29981: llseek(17, 0, SEEK_CUR) = 308 29981: close(17) = 0 29981: stat("/usr/lib/nss_ldap.so.1", 0xFFBFE2D4) = 0 29981: sigaction(SIGPIPE, 0xFFBFE728, 0xFFBFE868) = 0 29981: sigprocmask(SIG_SETMASK, 0xFEBEA0B4, 0xFFBFE778) = 0 29981: sigprocmask(SIG_SETMASK, 0xFFBFE764, 0x00000000) = 0 29981: getpid() = 29981 [29964] 29981: getuid() = 0 [0] 29981: getpid() = 29981 [29964] 29981: getuid() = 0 [0] 29981: time() = 1077620847 29981: write(15, "170301\0 8D81 R r r89".., 266) = 266 29981: poll(0xFFBFD650, 1, -1) = 1 29981: read(15, "170301\0 ", 5) = 5 29981: read(15, " 61ED503E3C40EC7A3 R\t (".., 32) = 32 29981: read(15, "170301\0F0", 5) = 5 29981: read(15, "D61F k # \F1\v l wFFE3 r".., 240) = 240 29981: poll(0xFFBFD650, 1, -1) = 1 29981: read(15, "170301\0 ", 5) = 5 29981: read(15, " 898 8DB2CD bB9 m8B84C5".., 32) = 32 29981: read(15, "170301\0 0", 5) = 5 29981: read(15, "9F >C5BCA687 X .EEA2 > i".., 48) = 48 29981: time() = 1077620847 29981: time() = 1077620847 29981: Incurred fault #6, FLTBOUNDS %pc = 0xFF053364 29981: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004 29981: Received signal #11, SIGSEGV [default] 29981: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000004 29964: poll(0x00052E28, 11, 999) = 1 29964: read(15, 0xFFBFF958, 512) = 0 29964: time() = 1077620847 29964: write(4, " d o v e c o t - a u t h".., 61) = 61 29964: write(14, "\0\0\001\0\0\003\0\0\0\0".., 20) = 20 29964: close(15) = 0 29964: poll(0x00052E28, 10, 446) = 0 29964: poll(0x00052E28, 10, 0) = 0 29964: waitid(P_ALL, 0, 0xFFBFF998, WEXITED|WTRAPPED|WNOHANG) = 0 29964: time() = 1077620848 29964: write(4, " d o v e c o t - a u t h".., 74) = 74 29964: waitid(P_ALL, 0, 0xFFBFF998, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD 29964: poll(0x00052E28, 10, 998) = 0 29964: poll(0x00052E28, 10, 0) = 0 29964: poll(0x00052E28, 10, 4999) (sleeping...) 29964: poll(0x00052E28, 10, 4999) = 1 29964: read(14, 0x0007C051, 4047) = 0 29964: close(14) = 0 29964: poll(0x00052E28, 9, 2885) (sleeping...) dovecot.conf---------------------------------------------------- ## Dovecot 1.0 configuration file # Default values are shown after each value, it's not required to uncomment # any of the lines. Exception to this are paths, they're just examples # with real defaults being based on configure options. The paths listed here # are for configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # --with-ssldir=/etc/ssl # Base directory where to store runtime data. base_dir = /usr/local/dovecot/run/ # Protocols we want to be serving: # imap imaps pop3 pop3s protocols = imap pop3 imaps pop3s # IP or host address where to listen in for connections. It's not currently # possible to specify multiple addresses. "*" listens in all IPv4 interfaces. # "[::]" listens in all IPv6 interfaces, but may also listen in all IPv4 # interfaces depending on the operating system. You can specify ports with # "host:port". imap_listen = * pop3_listen = * # IP or host address where to listen in for SSL connections. Defaults # to above non-SSL equilevants if not specified. #imaps_listen = #pop3s_listen = # Disable SSL/TLS support. ssl_disable = yes # PEM encoded X.509 SSL/TLS certificate and private key. They're opened before # dropping root privileges, so keep the key file unreadable by anyone but # root. Included doc/mkcert.sh can be used to easily generate self-signed # certificate, just make sure to update the domains in dovecot-openssl.cnf #ssl_cert_file = /etc/ssl/certs/dovecot.pem #ssl_key_file = /etc/ssl/private/dovecot.pem # SSL parameter file. Master process generates this file for login processes. # It contains Diffie Hellman and RSA parameters. ssl_parameters_file = /usr/local/dovecot/run/ssl-parameters.dat # How often to regenerate the SSL parameters file. Generation is quite CPU # intensive operation. The value is in hours, 0 disables regeneration # entirely. ssl_parameters_regenerate = 24 # Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability) #disable_plaintext_auth = no # Use this logfile instead of syslog(). /dev/stderr can be used if you want to # use stderr for logging (ONLY /dev/stderr - otherwise it is closed). log_path = /var/log/dovecot.log # For informational messages, use this logfile instead of the default info_log_path = /var/log/dovecot.info # Prefix for each line written to log file. % codes are in strftime(3) # format. Note the extra space at the end of line. #log_timestamp = "%b %d %H:%M:%S " ## ## Login processes ## # Directory where authentication process places authentication UNIX sockets # which login needs to be able to connect to. The sockets are created when # running as root, so you don't have to worry about permissions. #login_dir = /usr/local/dovecot/run/login # chroot login process to the login_dir. Only reason not to do this is if you # wish to run the whole Dovecot without roots. #login_chroot = yes ## ## IMAP login process ## login = imap # Executable location. #login_executable = /usr/local/dovecot/libexec/dovecot/imap-login # User to use for the login process. Create a completely new user for this, # and don't use it anywhere else. The user must also belong to a group where # only it has access, it's used to control access for authentication process. login_user = dovecot # Set max. process size in megabytes. If you don't use # login_process_per_connection you might need to grow this. #login_process_size = 16 # Should each login be processed in it's own process (yes), or should one # login process be allowed to process multiple connections (no)? Yes is more # secure, espcially with SSL/TLS enabled. No is faster since there's no need # to create processes all the time. #login_process_per_connection = yes # Number of login processes to create. If login_process_per_user is # yes, this is the number of extra processes waiting for users to log in. #login_processes_count = 3 # Maximum number of extra login processes to create. The extra process count # usually stays at login_processes_count, but when multiple users start logging # IN AT THE SAME time more extra processes are created. To prevent fork-bombing # we check only once in a second if new processes should be created - if all # of them are used at the time, we double their amount until limit set by this # setting is reached. This setting is used only if login_process_per_use is yes. #login_max_processes_count = 128 # Maximum number of connections allowed in login state. When this limit is # reached, the oldest connections are dropped. If login_process_per_user # is no, this is a per-process value, so the absolute maximum number of users # logging in actually login_processes_count * max_logging_users. #login_max_logging_users = 256 ## ## POP3 login process ## # Settings default to same as above, so you don't have to set anything # unless you want to override them. login = pop3 # Exception to above rule being the executable location. #login_executable = /usr/libexec/dovecot/pop3-login ## ## Mail processes ## # Maximum number of running mail processes. When this limit is reached, # new users aren't allowed to log in. #max_mail_processes = 1024 # Show more verbose process titles (in ps). Currently shows user name and # IP address. Useful for seeing who are actually using the IMAP processes # (eg. shared mailboxes or if same uid is used for multiple accounts). #verbose_proctitle = no # Show protocol level SSL errors. #verbose_ssl = no # Valid UID range for users, defaults to 500 and above. This is mostly # to make sure that users can't log in as daemons or other system users. # Note that denying root logins is hardcoded to dovecot binary and can't # be done even if first_valid_uid is set to 0. #first_valid_uid = 500 #last_valid_uid = 0 # Valid GID range for users, defaults to non-root/wheel. Users having # non-valid GID as primary group ID aren't allowed to log in. If user # belongs to supplementary groups with non-valid GIDs, those groups are # not set. #first_valid_gid = 1 #last_valid_gid = 0 # ':' separated list of directories under which chrooting is allowed for mail # processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too). # This setting doesn't affect login_chroot or auth_chroot variables. # WARNING: Never add directories here which local users can modify, that # may lead to root exploit. Usually this should be done only if you don't # allow shell access for users. See doc/configuration.txt for more information. #valid_chroot_dirs = # Default chroot directory for mail processes. This can be overridden by # giving /./ in user's home directory (eg. /home/./user chroots into /home). #mail_chroot = # Default MAIL environment to use when it's not set. By leaving this empty # dovecot tries to do some automatic detection as described in # doc/mail-storages.txt. There's a few special variables you can use: # # %u - username # %n - user part in user@domain, same as %u if there's no domain # %d - domain part in user@domain, empty if user there's no domain # %h - home directory # # You can also limit a width of string by giving the number of max. characters # after the '%' character. For example %1u gives the first character of # username. Some examples: # # maildir:/var/mail/%1u/%u/Maildir # mbox:~/mail/:INBOX=/var/mail/%u # mbox:/var/mail/%d/%n/:INDEX=/var/indexes/%d/%n # default_mail_env = maildir:/maildir/%u/Maildir # Space-separated list of fields to cache for all mails. Currently these # fields are allowed followed by a list of commands they speed up: # # Envelope - FETCH ENVELOPE and SEARCH FROM, TO, CC, BCC, SUBJECT, # SENTBEFORE, SENTON, SENTSINCE, HEADER MESSAGE-ID, # HEADER IN-REPLY-TO # Body - FETCH BODY # Bodystructure - FETCH BODY, BODYSTRUCTURE # MessagePart - FETCH BODY[1.2.3] (ie. body parts), RFC822.SIZE, # SEARCH SMALLER, LARGER, also speeds up BODY/BODYSTRUCTURE # generation. This is always set with mbox mailboxes, and # also default with Maildir. # # Different IMAP clients work in different ways, that's why Dovecot by default # only caches MessagePart which speeds up most operations. Whenever client # does something where caching could be used, the field is automatically marked # to be cached later. For example after FETCH BODY the BODY will be cached # for all new messages. Normally you should leave this alone, unless you know # what most of your IMAP clients are. Caching more fields than needed makes # the index files larger and generate useless I/O. # # With maildir there's one extra optimization - if nothing is cached, indexing # the maildir becomes much faster since it's not opening any of the mail files. # This could be useful if your IMAP clients access only new mails. #mail_cache_fields = MessagePart # Space-separated list of fields that Dovecot should never set to be cached. # Useful if you want to save disk space at the cost of more I/O when the fields # needed. #mail_never_cache_fields = # Workarounds for various client bugs: # oe6-fetch-no-newmail: # Never send EXISTS/RECENT when replying to FETCH command. Outlook Express # seems to think they are FETCH replies and gives user "Message no longer # in server" error. Note that OE6 still breaks even with this workaround # if synchronization is set to "Headers Only". # outlook-idle: # Outlook and Outlook Express never abort IDLE command, so if no mail # arrives in half a hour, Dovecot closes the connection. This is still # fine, except Outlook doesn't connect back so you don't see if new mail # arrives. #client_workarounds = # Dovecot can notify client of new mail in selected mailbox soon after it's # received. This setting specifies the minimum interval in seconds between # new mail notifications to client - internally they may be checked more or # less often. Setting this to 0 disables the checking. # NOTE: Evolution client breaks with this option when it's trying to APPEND. #mailbox_check_interval = 0 # Like mailbox_check_interval, but used for IDLE command. #mailbox_idle_check_interval = 30 # Allow full filesystem access to clients. There's no access checks other than # what the operating system does for the active UID/GID. It works with both # maildir and mboxes, allowing you to prefix mailboxes names with eg. /path/ # or ~user/. mail_full_filesystem_access = no # Maximum allowed length for custom flag name. It's only forced when trying # to create new flags. #mail_max_flag_length = 50 # Save mails with CR+LF instead of plain LF. This makes sending those mails # take less CPU, especially with sendfile() syscall with Linux and FreeBSD. # But it also creates a bit more disk I/O which may just make it slower. #mail_save_crlf = no # Use mmap() instead of read() to read mail files. read() seems to be a bit # faster with my Linux/x86 and it's better with NFS, so that's the default. #mail_read_mmaped = no # Copy mail to another folders using hard links. This is much faster than # actually copying the file. This is problematic only if something modifies # the mail in one folder but doesn't want it modified in the others. I don't # know any MUA which would modify mail files directly. IMAP protocol also # requires that the mails don't change, so it would be problematic in any case. # If you care about performance, enable it. #maildir_copy_with_hardlinks = no # Check if mails' content has been changed by external programs. This slows # down things as extra stat() needs to be called for each file. If changes are # noticed, the message is treated as a new message, since IMAP protocol # specifies that existing message are immutable. #maildir_check_content_changes = no # Which locking methods to use for locking mbox. There's three available: # dotlock: Create <mailbox>.lock file. This is the oldest and most NFS-safe # solution. If you want to use /var/mail/ like directory, the users # will need write access to that directory. # fcntl : Use this if possible. Works with NFS too if lockd is used. # flock : May not exist in all systems. Doesn't work with NFS. # # You can use both fcntl and flock too; if you do the order they're declared # with is important to avoid deadlocks if other MTAs/MUAs are using both fcntl # and flock. Some operating systems don't allow using both of them # simultaneously, eg. BSDs. If dotlock is used, it's always created first. #mbox_locks = dotlock fcntl # Should we create dotlock file even when we want only a read-lock? Setting # this to yes hurts the performance when the mailbox is accessed simultaneously # by multiple processes, but it's needed for reliable reading if no other # locking methods are available. #mbox_read_dotlock = no # Maximum time in seconds to wait for lock (all of them) before aborting. #mbox_lock_timeout = 300 # If dotlock exists but the mailbox isn't modified in any way, override the # lock file after this many seconds. #mbox_dotlock_change_timeout = 30 # umask to use for mail files and directories #umask = 0077 # Drop all privileges before exec()ing the mail process. This is mostly # meant for debugging, otherwise you don't get core dumps. Note that setting # this to yes means that log file is opened as the logged in user, which # might not work. It could also be a small security risk if you use single UID # for multiple users, as the users could ptrace() each others processes then. #mail_drop_priv_before_exec = no ## ## IMAP process ## # Executable location #imap_executable = /usr/libexec/dovecot/imap # Set max. process size in megabytes. Most of the memory goes to mmap()ing # files, so it shouldn't harm much even if this limit is set pretty high. #imap_process_size = 256 # Support for dynamically loadable modules. #imap_use_modules = no #imap_modules = /usr/lib/dovecot/imap ## ## POP3 process ## # Executable location #pop3_executable = /usr/libexec/dovecot/pop3 # Set max. process size in megabytes. Most of the memory goes to mmap()ing # files, so it shouldn't harm much even if this limit is set pretty high. #pop3_process_size = 256 # Support for dynamically loadable modules. #pop3_use_modules = no #pop3_modules = /usr/lib/dovecot/pop3 ## ## Authentication processes ## # You can have multiple processes; each time "auth = xx" is seen, a new # process definition is started. The point of multiple processes is to be # able to set stricter permissions to others. For example, plain/PAM # authentication requires roots, but if you also use digest-md5 authentication # for some users, you can authenticate them without any privileges in a # separate auth process. Just remember that only one auth process is asked # for the password, so you can't have different passwords with different # processes (unless they have different auth methods, and you're ok with # having different password for each method). # Authentication process name. auth = default # Space separated list of wanted authentication mechanisms: # plain digest-md5 anonymous auth_mechanisms = plain # Space separated list of realms for SASL authentication mechanisms that need # them. You can leave it empty if you don't want to support multiple realms. # Many clients simply use the first one listed here, so keep the default realm # first. #auth_realms = # Default realm to use if none was specified. #auth_default_realm = # Where user database is kept: # passwd: /etc/passwd or similiar, using getpwnam() # passwd-file <path>: passwd-like file with specified location # static uid=<uid> gid=<gid> home=<dir template>: static settings # vpopmail: vpopmail library # ldap <config path>: LDAP, see doc/dovecot-ldap.conf # pgsql <config path>: a PostgreSQL database, see doc/dovecot-pgsql.conf #auth_userdb = passwd auth_userdb = ldap /usr/local/dovecot/etc/dovecot-ldap.conf # Where password database is kept: # passwd: /etc/passwd or similiar, using getpwnam() # shadow: /etc/shadow or similiar, using getspnam() # pam [<service> | *]: PAM authentication # passwd-file <path>: passwd-like file with specified location # vpopmail: vpopmail authentication # ldap <config path>: LDAP, see doc/dovecot-ldap.conf # pgsql <config path>: a PostgreSQL database, see doc/dovecot-pgsql.conf auth_passdb = pam imap #auth_passdb = ldap /usr/local/dovecot/etc/dovecot-ldap.conf #auth_executable = /usr/libexec/dovecot/dovecot-auth # Set max. process size in megabytes. #auth_process_size = 256 # User to use for the process. This user needs access to only user and # password databases, nothing else. Only shadow and pam authentication # requires roots, so use something else if possible. auth_user = root # Directory where to chroot the process. Most authentication backends don't # work if this is set, and there's no point chrooting if auth_user is root. #auth_chroot = # Number of authentication processes to create #auth_count = 1 # List of allowed characters in username. If the user-given username contains # a character not listed in here, the login automatically fails. This is just # an extra check to make sure user can't exploit any potential quote escaping # vulnerabilities with SQL/LDAP databases. If you want to allow all characters, # set this value to empty. #auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@ # Username to use for users logging in with ANONYMOUS SASL mechanism #auth_anonymous_username = anonymous # More verbose logging. Useful for figuring out why authentication isn't # working. auth_verbose = yes # digest-md5 authentication process. It requires special MD5 passwords which # /etc/shadow and PAM doesn't support, so we never need roots to handle it. # Note that the passwd-file is opened before chrooting and dropping root # privileges, so it may be 0600-root owned file. #auth = digest_md5 #auth_methods = digest-md5 #auth_realms = #auth_userdb = passwd-file /etc/passwd.imap #auth_passdb = passwd-file /etc/passwd.imap #auth_user = imapauth #auth_chroot = # if you plan to use only passwd-file, you don't need the two auth processes, # simply set "auth_methods = plain digest-md5" -- Benjamin Dabelow benja.dabelow(a)gmx.net Staufenbergstr. 88 benja-dabelow.gmxhome.de/start.html 74081 Heilbronn Germany

3 3

[Dovecot] help: The current command did not succeed. The mail server responded: Invalid mask.
by Bodo Gelbe 25 Feb '04

25 Feb '04

Am tryin to move from uw-imapd to dovecot, using dovecot ver 0.99.10.4. Reading with Mozilla Mail v 1.4. I made some test accounts and they seem to be working fine, but my older existing accounts give error messages whenever I connect or subscribe to mailboxes within them. The message that appears on the client is: "The current command did not succeed. The mail server responded: Invalid mask." it appears two or three times in an alert box (on windows) then everything seems to work. The masks (I've put a syslog call into the code) are: "~%", "~%~%" and "~*". The test accounts I created don't have this problem. Thanks in advance for any advice, -- Bodo Gelbe

2 1

[Dovecot] Dovecot and Mulberry
by Kenneth Porter 25 Feb '04

25 Feb '04

FYI. Does Dovecot implement BODYSTRUCTURE? An eval copy of Mulberry can be downloaded from <http://www.cyrusoft.com/mulberry/>. ------------ Forwarded Message ------------ Date: Tuesday, February 10, 2004 6:56 PM +0100 From: Lennart Petersson <lennart(a)informatik.gu.se> To: mulberry-discuss(a)cyrusoft.com Subject: Dovecot and Mulberry I've recently changed my imap-server from Courier to Dovecot <http://dovecot.procontrol.fi/> for testing purposes and have seen some strange behaviour from Mulberry. Most annoying is that suddenly some incoming mail are parsed wrong, i.e. even if the mail has has proper Content-Type: text/plain; charset="iso-8859-1" and Content-Transfer-Encoding: quoted-printable, it is displayed as 7bit and us-ascii. All these =F6 and so on is irritating. The only way remedy the problem is to quit mulberry and start again and almost always the email is displayed properly. And if the mail that gets misinterpreted is a multi-part email mulberry only reports that it has one part. But if you view the mail in raw all the parts are there. I've yet to see a pattern in then mulberry starts this misinterpretations. Sometimes it is a email from pine or a mail from a mailinglist or from outlook or ... A collegue that also uses dovecot but mutt instead of mulberry doesn't have this problems. Should I blame Dovecot or Mulberry? Anyone one with experience with dovecot (or any other imap-server that supports Maildirs)? Lennart ---------- End Forwarded Message ---------- ------------ Forwarded Message ------------ Date: Tuesday, February 10, 2004 1:12 PM -0500 From: Cyrus Daboo <daboo(a)cyrusoft.com> To: Lennart Petersson <lennart(a)informatik.gu.se>, mulberry-discuss(a)cyrusoft.com Subject: Re: Dovecot and Mulberry Hi Lennart, --On Tuesday, February 10, 2004 6:56 PM +0100 Lennart Petersson <lennart(a)informatik.gu.se> wrote: | A collegue that also uses dovecot but mutt instead of mulberry doesn't | have this problems. Should I blame Dovecot or Mulberry? | | Anyone one with experience with dovecot (or any other imap-server that | supports Maildirs)? If you see problems with proper interpretation of MIME structure and MIME parameters etc, then it is almost certainly a server bug. Mulberry uses the IMAP server's BODYSTRUCTURE response to determine the MIME structure of a message on the server without having to download the entire message and parse it locally - that is one of the major benefits of IMAP. The details you see listed in the mailbox pane (addresses, subject, attachment types) and the parts listed in the message pane's Parts list are all derived from the server response. If the server gets it wrong, then you will see the incorrect data/structure in Mulberry too. To confirm that it really is a server bug, try copying the message to a local Mulberry mailbox and look at it from the local mailbox. It should appear correctly in that case, because Mulberry will do MIME parsing itself for local messages. To fully diagnose this, put the problem messages in their own IMAP mailbox, then turn protocol logging for IMAP on in Mulberry using <http://www.cyrusoft.com/mulberry/faq/logging.html> and open the mailbox to show the list of message. Then turn logging off and send me (or inspect yourself) the log files. NB Clients that do not take advantage of IMAP's benefits by using BODYSTRUCTURE (and other similar features) will not 'expose' the server bug as they never use that data from the server. PS Getting the BODYSTRUCTURE response wrong is the most common server bug that we see - particularly in relatively new servers. -- Cyrus Daboo ---------- End Forwarded Message ----------

2 1

[Dovecot] X-UID
by Paul Adams 25 Feb '04

25 Feb '04

What is the function of the X-UID header in mbox format? Mozilla Thunderbird 0.5 seems to regard it as a simple numbering of the messages; i.e., that the first message in the mbox should have X-UID: 1. Dovecot seems to treat it simply as an ordered unique identifier. Thus, the first message in my actual mbox has X-UID: 3849658. (There are only a few dozen messages in the box.) Running Thunderbird 0.5 against a Dovecot IMAP server with mbox format, Thunderbird displays these UID numbers in the message list, which is fairly useless -- I want a numbered list of my messages starting at 1 (which Pine, for example, is happy to provide). I'm just wondering whether this is Dovecot's fault, Thunderbird's fault, or an ambiguity in the mbox standard. thanks, Paul

2 1

[Dovecot] auth_executable
by Helmut Zeilinger 25 Feb '04

25 Feb '04

Hi, i am new to dovecot and i don't know what i can do with the "auth_executable" setting in the "dovecot.conf" file. Can i invoke an external program for authentification? If yes, is there a description what this program/script has to do? Thanks Helmut

2 1

[Dovecot] [PATCH] POP3: Fix RFC1939 non-compliance in STAT, LIST and UIDL commands
by Nic Bellamy 25 Feb '04

25 Feb '04

Hi all, attached is a patch against 0.99.10.4 that fixes the STAT, LIST and UIDL POP3 command output in the case that they're issued after one or more messages have been deleted. Examples of incorrect behavior (bad spots marked with '***') C: STAT S: +OK 2 806 C: LIST S: +OK 2 messages: S: 1 403 S: 2 403 S: . C: UIDL S: +OK S: 1 1076749908.12 S: 2 1076749908.13 S: . C: DELE 1 S: +OK Marked to be deleted. C: STAT *** S: +OK 2 806 C: LIST *** S: +OK 2 messages: *** S: 1 403 S: 2 403 S: . C: UIDL S: +OK *** S: 1 1076749908.12 S: 2 1076749908.13 S: . What it should have been is: [snip] C: DELE 1 S: +OK Marked to be deleted. C: STAT S: +OK 1 403 C: LIST S: +OK 1 messages: S: 2 403 S: . C: UIDL S: +OK S: 2 1076749908.13 S: . It's unlikely the above issue has been causing much in the way of problems, as it's very rare for mail clients to use any of the faulty commands after they've deleted messages (they tend to do it once at the beginning of the POP3 session and cache the results). Regards, Nic. -- Nic Bellamy <nic(a)bellamy.co.nz> Bellamy Consulting -- Software & Security -- http://www.bellamy.co.nz/ -- Phone: +64-6-377-4957 Fax: +64-6-377-0505 Mobile: +64-21-251-8954 --

2 1

[Dovecot] RE: Question on folders
by Alex S Moore 25 Feb '04

25 Feb '04

I have read and read the dovecot docs on maildir folders and think that this is what I want. However, the MUA programs that I use, SylpheedClaws, Evolution, Mozilla seem to react differently to how I setup the folders. Is there a good FAQ on this subject somewhere? I think that I want to setup a virtual domain and am looking for documents. Alex

4 4

[Dovecot] too large imap.index.data files
by Network Wizards 25 Feb '04

25 Feb '04

Hi, I have noticed that imap.index.data are often too large files (several MiBs). Is there a way to limit their size or to shrink dimension or to assign another directory where those file are stored? thank you will

5 4

Re: [Dovecot] Pam trouble
by Benjamin Dabelow 25 Feb '04

25 Feb '04

Hi Alex, > Are you using Solaris 9 native ldap? What configure options did you use > when building dovecot? I'm using OpenLDAP, but I think it's a pam rather than ldap problem. Dovecot check for the existance of a user alright, but fails when checking the password. My build script is enclosed. Cheers Benjamin Buildscript----------------------------------------------------- #!/bin/bash ## Defaults CC="gcc" CXX="g++" LDPATH="/usr/local/lib:/usr/sfw/lib:/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3" CPPFLAGS="-I/usr/local/include -I/usr/sfw/include" LDFLAGS="-L/usr/local/lib -L/usr/sfw/lib" CFLAGS= #SSL LDPATH="$LDPATH:/usr/local/ssl/lib" CPPFLAGS="$CPPFLAGS -I/usr/local/ssl/include" LDFLAGS="$LDFLAGS -L/usr/local/ssl/lib -lssl -lcrypto" #BerkeleyDB LDPATH="$LDPATH:/usr/local/BerkeleyDB/lib" CPPFLAGS="$CPPFLAGS -I/usr/local/BerkeleyDB/include" LDFLAGS="$LDFLAGS -L/usr/local/BerkeleyDB/lib -ldb" CFLAGS="$CFLAGS -ldb" AUTH_CFLAGS="-I/usr/local/BerkeleyDB/include -L/usr/local/BerkeleyDB/lib -ldb" AUTH_LIBS="-ldb" #GDBM LDPATH="$LDPATH:/usr/local/gdbm/lib" CPPFLAGS="$CPPFLAGS -I/usr/local/gdbm/include" LDFLAGS="$LDFLAGS -L/usr/local/gdbm/lib -lgdbm" #LDAP LDPATH="$LDPATH:/opt/OpenLDAP/lib" CPPFLAGS="$CPPFLAGS -I/opt/OpenLDAP/include" LDFLAGS="$LDFLAGS -L/opt/OpenLDAP/lib -lldap -llber -lresolv" #Finishing LDFLAGS="-R$LDPATH $LDFLAGS" export LDFLAGS CPPFLAGS CFLAGS echo -e "\nLDFLAGS=$LDFLAGS" echo -e "\nCPPFLAGS=$CPPFLAGS" echo -e "\nCFLAGS=$CFLAGS" cd dovecot-0.99.10.4 echo -e "\nPress RETURN to configure or CTRL+C to cancel." read ./configure --prefix=/usr/local/dovecot --with-ldap=/opt/OpenLDAP --with-ssl=openssl --with-storages=maildir echo -e "\nPress RETURN to make or CTRL+C to cancel." read make -- Benjamin Dabelow benja.dabelow(a)gmx.net Staufenbergstr. 88 benja-dabelow.gmxhome.de/start.html 74081 Heilbronn Germany

2 3

[Dovecot] IMAP subfolders
by Manuel Moran Vaquero 25 Feb '04

25 Feb '04

Hi: I am using dovecot since the first day on my server (so I have no other mailbox formats). I can't create any subfolders under any IMAP folders. Is this still an issue of dovecot? In mozilla, the operation is simply ignored. With outlook, you can't even click "Accept" if you select to create a subfolder, rather than a top level folder. I have Fedora Core 1, and didn't touch anything special in the configuration file (just one line which enabled pop3 and imap). I have seen the list archives but the existing thread about the issue seems to say that the problem is solved. (?) Thanks in advance for replies Manuel Moran

5 6

Re: [Dovecot] ":" in filenames
by Timo Sirainen 24 Feb '04

24 Feb '04

On Tue, 2004-02-24 at 05:57, Lars Hansson wrote: > dovecot seems to have an issue with :'s in pathnames: > imap(test.user): Fatal: Failed to create storage with data: /home/ > hosted/example.com/users/test:user > > This causes a bit of a problem with vmailmgr since it, by default, > replaces .'s in maildir path with :'s. > I'm curious as to why :'s in paths are an issue? Do they have special > meaning to dovecot? Hmm.. They do. default_mail_env format is: "storage_format:data" and both mbox and maildir in "data" part treat it as "path:option:option2:..". So, Dovecot above thought "/home/hosted/example.com/users/test" was the storage format and "user" the data part for it. You could change default_mail_env = maildir:~/ but then Dovecot would think "user" as being unknown option.. I'm not sure what to do about this.. ':' was selected because it's PATH separator as well, so people rarely have directories containing ':' in it's name. Maybe it could be escaped as "\:"..

1 0

[Dovecot] ":" in filenames
by Lars Hansson 24 Feb '04

24 Feb '04

dovecot seems to have an issue with :'s in pathnames: imap(test.user): Fatal: Failed to create storage with data: /home/ hosted/example.com/users/test:user This causes a bit of a problem with vmailmgr since it, by default, replaces .'s in maildir path with :'s. I'm curious as to why :'s in paths are an issue? Do they have special meaning to dovecot? --- Lars Hansson

1 0

[Dovecot] dovecot-nightly/NetBSD - Fwd: CVS commit: wip/dovecot-nightly
by tom＠replic8.net 22 Feb '04

22 Feb '04

hello everybody, i just commited a pkgsrc for dovecot nightly cvs-snapshots to the pkgsrc-wip repository for NetBSD - this will hopefully go into base pkgsrc, soon. please see http://pkgsrc-wip.sourceforge.net/ on how to obtain pkgsrc-wip. ----- Forwarded message from Tom Hensel <tomhensel(a)users.sourceforge.net> ----- Date: Sun, 22 Feb 2004 11:18:52 -0800 From: Tom Hensel <tomhensel(a)users.sourceforge.net> Reply-To: pkgsrc-wip-discuss(a)lists.sourceforge.net Subject: CVS commit: wip/dovecot-nightly To: pkgsrc-wip-cvs(a)lists.sourceforge.net Module name: pkgsrc-wip Committed by: tomhensel Date: Sun Feb 22 19:18:52 UTC 2004 Import into wip/dovecot-nightly Log Message: Dovecot is an IMAP and POP3 server for Linux/UNIX-like systems, written with security primarily in mind. Although it's written in C, it uses several coding techniques to avoid most of the common pitfalls. A nightly CVS-snapshot is available at http://dovecot.procontrol.fi/nightly/ which includes major changes from Dovecot 0.99.10.4; please see the ChangeLog file inside the distribution archive. For more information on Dovecot see http://dovecot.procontrol.fi/ Status: Vendor Tag: tomhensel Release Tags: tomhensel_20040222 N wip/dovecot-nightly/PLIST N wip/dovecot-nightly/distinfo N wip/dovecot-nightly/Makefile N wip/dovecot-nightly/DESCR N wip/dovecot-nightly/files/dovecot.sh N wip/dovecot-nightly/patches/patch-aa N wip/dovecot-nightly/patches/patch-ab No conflicts created by this import To generate a diff of this commit: Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ pkgsrc-wip-cvs mailing list pkgsrc-wip-cvs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-cvs ----- End forwarded message -----

1 0

[Dovecot] Dovecot -- basic setup
by Tom 19 Feb '04

19 Feb '04

Hey all, After some kind soul made me understand what I can expect from Dovecot, I feel really embarassed for not being able to set it up correctly. What I already had was ~/Mail, containing about six maildirs. Exim got mail, delivered it to procmail, and procmail dropped it in my inbox; a needless extra step that I keep for future, ehm, needs that I might start to care about when I can just succesfully use the most basic mail configuration I can think of. As far as I understood, I just have to point Dovecot to my maildir for it to serve my mail when I connect appropriately with a client. When I test that with KMail connecting to localhost, I get a bizarre overview of my mailfolders, that looks like this: http://www.xs4all.be/~verbreyt/img/scrots/dovecot-kmail.jpg The error message on top is what I get when I try to catch up with any possible new mail: "Unable to get information about folder antwort.index. The server replied: Internal error." Syslog says "lstat(/home/tom/Mail/.antwort.index/cur) failed: Not a directory". Could be, of course: the directory should be ~/Mail/antwort/cur. After I ran KMail and got those errors, ~/Mail, previously only containing some folders, each in turn containing cur/, new/ and tmp/, is stuffed with index files, and three new folders (cur/, new/ and tmp/) directly in the toplevel. ##### $ ls -a Mail . .drafts.index.ids .sent.index.ids .. inbox sent-mail antwort .INBOX .sent-mail.index .antwort.index .inbox.index .sent-mail.index.ids .antwort.index.ids .inbox.index.ids spam check .inbox.index.sorted .spam.index .check.index new .spam.index.ids .check.index.ids outbox tmp cur .outbox.index trash .customflags .outbox.index.ids .trash.index drafts sent .trash.index.ids .drafts.index .sent.index ##### I'm not sure just where it all goes wrong. Yes, I feel stupid about that, but what did, then, did I misunderstand? The only relevant thing in /etc/dovecot.conf I guess would be "default_mail_env" which I have set to "maildir:~/Mail:INBOX=~/Mail/inbox". Documentation may be sparse, it'd still make me sad to be the cause of it being extended for use by the clueless. :-/ Grateful for any corrections, Tom -- "Mongolian drivers do not care much about pedestrians." -- np: Predominance - Luftschiffe (flac)

2 1

[Dovecot] File synchronization friendly indexes
by Aredridel 19 Feb '04

19 Feb '04

I've been doing some tests of file synchronization with Unison (think "two way rsync"), and run into one problem: Synching between servers has conflicts on the index file. I can manually exclude, but what seems to me to be a really wonderful feature would be to, preferably, make the indexes somewhat atomic, so that files, once written, don't change (this is a feature of maildirs in general), and barring that, that they include the machine name as part of the filename, so there's no conflicts. Also, on a completely unrelated and somewhat offtopic note: I'd love to hear some brainstorms on how to prevent duplicate messages when maildirs are synched, files are moved from new on one or more ends, flags are changed inconsistently, and synched back. Ari

2 1

[Dovecot] More Benchmarks, and a question about indexing
by Anthony Wendell Kay 18 Feb '04

18 Feb '04

Hi, We are thinking of converting to Dovecot to lighten our I/O load. I have done some performace tests comparing UW-IMAP to Dovecot when using mbox format if anyone is interested. They primarily examine the I/O improvements that can be gained from using Dovecot over UW when staying with mbox format: http://whizzo.uoregon.edu/public/src/mailperf/results.html I had too much cached for this set of tests, and I am going to re-run some with the recommended cache settings...so stay tuned. Anyway, we are stuck with the mbox format for the forseeable future, and I noticed how hard hitting Dovecot is on initial access to a large mailbox, so we need a way to pre-create some of those indexes. I saw in the docs that such an indexer has been planned, but does anyone have a hack for doing it now? -- Anthony Kay Phone: (541) 346-1719 Student Consultant Key Signature: 7195 40B9 FC4F 6F43 C04A University of Oregon Computing Center B4D9 BAF1 C76E AB6E 33E5 "Don't wish your life away." - Mom's best advice

4 4

[Dovecot] LDAP configuration
by Giacomo Cariello 18 Feb '04

18 Feb '04

Hello, I've just installed dovecot to replace courier-imap and I've found out it didn't support some of the typical LDAP userPassword schemes, so I've written some based on OpenSSL API. Furthermore I noticed that the MD5 one seems broken. If it isn't a requirement to ship its own implementation of a crypto algorithm, I would send in a patch to replace schema checks with those based on libcrypto. I also noticed that if I try connecting to an account that doesn't contain a real maildir (es. maildir:%h/.mail, but .mail doesn't exist), the imap segv's. I suppose it would be cool to ship a maildirmake program and have imap use it whenever necessary, if a flag allows it to do so. Giacomo Cariello, jwk(a)bug.it KeyID: 3072/1024/0x409C9044 Fingerprint: 7984 10FD 0460 4202 BF90 3881 CDE4 D78E 409C 9044 "Put that mic in my hand and let me kick out the jams!" - MC5

2 2