- dovecot - dovecot.org

[Dovecot] Dovecot stop accepting command When reading disk quota (soft)
by Chan Min Wai 23 Aug '04

23 Aug '04

Hello all, I've face some problem here and I think it should be the way. 1) I'm running Dovecot version 0.99.10.4 (fc1 release) on RH9 2) One of the users have reach the soft disk quota limits 3) Dovecot stop the users from deleting email. What I think was, dovecot should let the user continue to use the services until it reach the hard limits, but pop up message each and every time ;). Anyone have that problem before? Thank You Chan Min Wai

3 3

[Dovecot] Sent, Drafts, Trash folders
by Jason M. Wilde 23 Aug '04

23 Aug '04

I am hosting imap mail for a new affiliate and am offering webmail via squirrelmail as well. Squirrelmail created INBOX.Sent, INBOX.Trash, etc by default and I would like to use these folders for my Dovecot imap users. I am using the mbox format, Postfix and users retrieve mail via the Outlook client remotely in addition to webmail access. Thank you for any help. Jason

2 1

[Dovecot] What about saving your INBOX at ~/mbox ?
by Nico Kadel-Garcia 23 Aug '04

23 Aug '04

Hi, folks. I'm testing out RedHat's "Fedora Core 2" release, which has switched from the old WashU imapd to dovecot-0.99.10. Overall, this looks like a really, really good move on their part: it looks like a very sweet little tool without some of the ingrained idiocy of Mark Crispin insisting that every home directory consist of nothing but mbox files and allowing you to use a configurable subdirectory by default, ~/mail. Cool. There is one feature of the old WashU imapd that I miss, though. That daemonn could be configured to automatically transfer the user's email to the "~/mbox" upon activation of the daemon, effectively reducing the size of the /var/spool/mail/{username}" mail spool and helping keep the user's disk usage in their home directories, not in /var/spool/mail. This can be a good thing for various reasons. But I don't see any way to enable that behavior for dovecot. Is there something I'm missing, or do folks feel it would be reasonable to add? -- Nico Kadel-Garcia Systems Engineer Mitsubish Electric Research Lab <nkadel(a)merl.com>

4 6

[Dovecot] Is 1.0-test stabilising?
by Curtis Maloney 23 Aug '04

23 Aug '04

Has Timo backed off work, and been busy with something else, or has 1.0 really stabilised that much? Seems to me just a couple of weeks ago we were seeing a new test release every few days... now there's been nothing all month... I'm hoping it's ready for release... but if it's just that Timo's busy, well, I can understand that. We're about to receive some new servers, and I hope to migrate from 0.99 to 1.0 as we migrate to the new machines. -- Curtis Maloney

3 3

RE: [Dovecot] Unusual behaviour
by Mark Lidstone 20 Aug '04

20 Aug '04

I thought that Dovecot was supposed to handle that kind of thing? Reading from the website: "Any kind of crash is considered as bug and will be fixed - even if it happens only by deliberately poking the index files." I've done it in the past by just creating the bare folders - they appear in the IMAP folder list then when they're used Dovecot seems to create the sub folders anyway. The issue I'm asking about here is, should the error message say "Internal Error [date time]" rather than something useful? Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== == -----Original Message----- From: Keith Edmunds [mailto:keith@midnighthax.com] Sent: 20 August 2004 12:42 To: dovecot(a)dovecot.org Subject: Re: [Dovecot] Unusual behaviour On Fri, 20 Aug 2004 11:26:44 +0100 "Mark Lidstone" <mlidstone(a)bmtseatech.co.uk> wrote: > I've just noticed something strange in dovecot 0.99.10.5. I created > some IMAP folders from the command line (mkdir .INBOX.Folder1) No: you created a directory. IMAP folders need cur/ tmp/ and new/ as subdirectories under the new folder directory. Keith -- ---------------------------------------------------------------------- Small business computer support: http://www.tiger-computing.co.uk Linux consultancy: http://www.TheLinuxConsultancy.co.uk ----------------------------------------------------------------------

2 1

[Dovecot] Unusual behaviour
by Mark Lidstone 20 Aug '04

20 Aug '04

Hi, I've just noticed something strange in dovecot 0.99.10.5. I created some IMAP folders from the command line (mkdir .INBOX.Folder1) as a different user to the owner of the mailbox. Obviously when I tried to view them via IMAP I got an error message, but the message to the client was "internal error[date time]" where date and time appeared to be the current date and time. Is this correct behaviour? Dovecot was running on FC2, and the client was Mozilla Thunderbird under Windows. Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== ==

2 1

[Dovecot] Question: email system architecture
by Gland Vador 18 Aug '04

18 Aug '04

Hi, I have a question about how to implement a mail system, but I don't know where to ask. Until now, I have a mail system who receive mail by postfix and transport it through procmail to the /var/spool/mail/username mailbox. From here it is retrieved through dovecot (POP3). Now I have two more users, I want to implement a IMAP server, and also provide a webmail (squirrelmail) interface. And in order to filter spam, I want to install spamassassin. Until now it was thunderbird who made the filterring, but with a webmail interface it's no more possible. So suppose that I have configured procmail to deliver "good" mail in an Inbox folder and "spam" in a SPAM folder. This for each user mailbox. I also have configured dovecot as IMAP server and any IMAP client can see the two folder with spam and ham. And here comes my implementation problem. If a user see a "good" mail in his spam folder (or vice-versa) he will take this mail and move to his inbox folder. But, I want to be able to say to spamassassin to learn that this message is ham, with the command sa-learn, and also remove the x-spam* headers. And I don't see a good way to do that. In my opinion, it should be the MUA task, but spamassassin is server based. It's any way that dovecot when it moves the mail between tho folders can call an external script who will make this job in fonction of source/destination folder? Maybe it's a silly question (I don't know IMAP and his possibilities). In this case, can anyone explain (or point to) me a way to do that ? Sorry for this long message. Edd.

4 5

[Dovecot] We couldn't drop root group privileges.
by Greg M 16 Aug '04

16 Aug '04

Hello all, This is my first post to this list. I have tried finding this answer online but while it seems that there are some people out there asking, I cant seem to get an answer to it. I have installed Dovecot some many month ago, and just recently I have been getting an error while trying to log into one of my accounts that I used all the time. The error that comes up is pop3: We couldn't drop root group privileges I have seen where someone else has asked this same question, but there was no response to the list. Anyone have any ideas? I use squirrel mail to check the account as well as KMail (IMAP), and have even tried logging in through telnet to port 110 to see if it was a client issue, but it appears to be dovecot. I am using BSD 4.9 and Exim if that helps any. Thanks a bunch, for now I have to ssh into the machine to check my mail via PINE or mail. -Greg M.

2 1

[Dovecot] Imap process killed
by Yann Rouillard 16 Aug '04

16 Aug '04

Hi, I get the following message each time I try to access a mailbox. dovecot: [ID 684838 mail.error] child 27041 (imap) killed with signal 11 Using dovecot 1.0-test32 under Solaris 9. Using truss I get the following lines: 27041: read(0, " 2 s e l e c t " I N".., 4096) = 18 27041: open64("/var/mail/toto", O_RDWR|O_CREAT|O_EXCL, 0660) Err#17 EEXIST 27041: time() = 1092672589 27041: open64("", O_RDWR) Err#14 EFAULT 27041: Incurred fault #6, FLTBOUNDS %pc = 0xFF1B347C 27041: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 27041: Received signal #11, SIGSEGV [default] 27041: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000 I attached the complete result of the truss command and my configuration file. Any idea what is the problem ? Cheers, Yann ## Dovecot 1.0 configuration file # '#' character and everything after it is treated as comments. Extra spaces # and tabs are ignored. If you want to use either of these explicitly, put the # value inside quotes, eg.: key = "# char and trailing whitespace " # 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 = /var/run/dovecot/ # Protocols we want to be serving: # imap imaps pop3 pop3s protocols = imap # 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", although with multiple protocols you probably want to move this # setting inside protocol imap/pop3 { ... } section, so you can specify # different ports for IMAP/POP3. #listen = * # IP or host address where to listen in for SSL connections. Defaults # to above if not specified. #ssl_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 = /usr/local/public/ssl/certs/imapd.pem ssl_key_file = /usr/local/public/ssl/certs/imapd.pem # File containing trusted SSL certificate authorities. Usually not needed. #ssl_ca_file = # Request client to send a certificate. #ssl_verify_client_cert = no # SSL parameter file. Master process generates this file for login processes. # It contains Diffie Hellman and RSA parameters. #ssl_parameters_file = /var/run/dovecot/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 # SSL ciphers to use #ssl_cipher_list = all:!low # Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability). Note that 127.*.*.* and # IPv6 ::1 addresses are considered secure, this setting has no effect if # you connect from those addresses. 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 = # For informational messages, use this logfile instead of the default #info_log_path = # Prefix for each line written to log file. % codes are in strftime(3) # format. #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. Note that # everything in this directory is deleted when Dovecot is started. #login_dir = /var/run/dovecot/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 = no # 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 = 32 # 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 ## ## 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 = 200 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 # Grant access to these extra groups for mail processes. Typical use would be # to give "mail" group write access to /var/mail to be able to create dotlocks. #mail_extra_groups = # ':' 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, eg.: # # %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 # # See doc/variables.txt for full list. Some examples: # # default_mail_env = maildir:/var/mail/%1u/%u/Maildir # default_mail_env = mbox:~/mail/:INBOX=/var/mail/%u # default_mail_env = mbox:/var/mail/%d/%n/:INDEX=/var/indexes/%d/%n # default_mail_env = mbox:~/mail/:INBOX=/var/mail/%u:INDEX=MEMORY # 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 = # 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 mail keyword name. It's only forced when trying # to create new keywords. #mail_max_keyword_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. # Note that OpenBSD 3.3 and older don't work right with mail_read_mmaped = yes. #mail_read_mmaped = no # Don't use mmap() at all. This is required if you store indexes in remote # filesystems (NFS or clustered filesystem). #mmap_disable = no # Don't write() to mmaped files. This is required for some operating systems # which use separate caches for them, such as OpenBSD. #mmap_no_write = no # Don't use fcntl() locking. Alternatives are dotlocking and other tricks # which may be slower. Required for NFS. fcntl_locks_disable = yes # By default LIST command returns all entries in maildir beginning with dot. # Enabling this option makes Dovecot return only entries which are directories. # This is done by stat()ing each entry, so it causes more disk I/O. # (For systems setting struct dirent->d_type, this check is free and it's # done always regardless of this setting) #maildir_stat_dirs = 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 messages are immutable. #maildir_check_content_changes = no # Which locking methods to use for locking mbox. There's four 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. # lockf : May not exist in all systems. Doesn't work with NFS. # # You can use multiple locking methods; if you do the order they're declared # in is important to avoid deadlocks if other MTAs/MUAs are using multiple # locking methods as well. Some operating systems don't allow using some of # them simultaneously. #mbox_read_locks = fcntl #mbox_write_locks = dotlock fcntl # 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. It could 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 # 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. #mail_process_size = 256 # Log prefix for mail processes. See doc/variables.txt for list of possible # variables you can use. #mail_log_prefix = "%Up(%u): " ## ## IMAP specific settings ## protocol imap { # Login executable location. #login_executable = /usr/libexec/dovecot/imap-login # IMAP executable location #mail_executable = /usr/libexec/dovecot/imap # This would write rawlogs into ~/dovecot.rawlog/ directory: #mail_executable = /usr/libexec/dovecot/rawlog /usr/libexec/dovecot/imap # Maximum IMAP command line length in bytes. Some clients generate very long # command lines with huge mailboxes, so you may need to raise this if you get # "Too long argument" or "IMAP command line too large" errors often. #imap_max_line_length = 65536 # Support for dynamically loadable modules. #mail_use_modules = no #mail_modules = /usr/lib/dovecot/imap # 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. #imap_client_workarounds = } ## ## POP3 specific settings ## protocol pop3 { # Login executable location. #login_executable = /usr/libexec/dovecot/pop3-login # POP3 executable location #mail_executable = /usr/libexec/dovecot/pop3 # Don't try to set mails non-recent with POP3 sessions. This is mostly # intended to reduce disk I/O. With maildir it doesn't move files from # new/ to cur/, with mbox it doesn't write Status-header. #pop3_mails_keep_recent = no # Support for dynamically loadable modules. #mail_use_modules = no #mail_modules = /usr/lib/dovecot/pop3 # Workarounds for various client bugs: # outlook-no-nuls: # Outlook and Outlook Express hang if mails contain NUL characters. # This setting replaces them with 0x80 character. #pop3_client_workarounds = } ## ## Authentication processes ## # You can have multiple authentication processes. With plaintext authentication # the password is checked against each process, the first one which succeeds is # used. This is useful if you want to allow both system users (/etc/passwd) # and virtual users to login without duplicating the system users into virtual # database. # Executable location #auth_executable = /usr/libexec/dovecot/dovecot-auth # Set max. process size in megabytes. #auth_process_size = 256 # 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/domain to use if none was specified. This is used for both # SASL realms and appending @domain to username in plaintext logins. #auth_default_realm = # 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 = no auth default { # Space separated list of wanted authentication mechanisms: # plain digest-md5 cram-md5 apop anonymous mechanisms = plain # 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 # mysql <config path>: a MySQL database, see doc/dovecot-mysql.conf userdb = passwd # Where password database is kept: # passwd: /etc/passwd or similiar, using getpwnam() # shadow: /etc/shadow or similiar, using getspnam() # pam [<service> | *]: PAM authentication # checkpassword <path>: checkpassword executable 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 # mysql <config path>: a MySQL database, see doc/dovecot-mysql.conf passdb = pam # 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. Note that passwd # authentication with BSDs internally accesses shadow files, which also # requires roots. 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. #chroot = # Number of authentication processes to create #count = 1 # Require a valid SSL client certificate or the authentication fails. #ssl_require_client_cert = no } # PAM doesn't provide a way to get uid, gid or home directory. If you don't # want to use a separate user database (passwd usually), you can use static # userdb. #auth onlypam { # mechanisms = plain # userdb = static uid=500 gid=500 home=/var/mail/%u # passdb = pam # user = dovecot-auth #} #auth ldap { # mechanisms = plain # userdb = ldap /etc/dovecot-ldap.conf # passdb = ldap /etc/dovecot-ldap.conf # user = dovecot-auth #} #auth virtualfile { # mechanisms = plain digest-md5 # userdb = passwd-file /etc/passwd.imap # passdb = passwd-file /etc/passwd.imap # user = dovecot-auth #} # It's possible to export the authentication interface to other programs, # for example SMTP server which supports talking to Dovecot. Client socket # handles the actual authentication - you give it a username and password # and it returns OK or failure. So it's pretty safe to allow anyone access to # it. Master socket is used to a) query if given client was successfully # authenticated, b) userdb lookups. # listener sockets will be created by Dovecot's master process using the # settings given inside the auth section #auth default_with_listener { # mechanisms = plain # passdb = passwd # userdb = pam # socket listen { # master { # path = /var/run/dovecot/auth-master # #mode = 0600 # # Default user/group is the one who started dovecot-auth (root) # #user = # #group = # } # client { # path = /var/run/dovecot-auth-client # mode = 0660 # } # } #} # connect sockets are assumed to be already running, Dovecot's master # process only tries to connect to them. They don't need any other settings # than path for the master socket, as the configuration is done elsewhere. # Note that the client sockets must exist in login_dir. #auth external { # socket connect { # master { # path = /var/run/dovecot/auth-master # } # } #}

2 1

[Dovecot] no local users - mbox all under /var/spool/mail/
by Daniel 15 Aug '04

15 Aug '04

Hi there, im new to dovecot but I made my way trough configuring it. I almost get it running at least for one IMAP user. The problem is I got no local user thus no home directories, all Mailboxes are in mbox format under: /var/spool/mail: Looks like this: -SNIP- drwx------ 3 web1p2 poponly 19 2004-08-13 00:05 indexes -rw------- 1 nobody nobody 0 2004-03-26 21:51 nobody -rw------- 1 root root 0 2004-03-26 21:51 root -rw------- 1 web1p2 poponly 14 2004-08-13 00:10 .subscriptions -rw------- 1 web1p2 poponly 8571 2004-08-13 00:10 Trash -rw-rw---- 1 web0p1 root 23068262 2004-08-12 21:27 web0p1 -rw-rw---- 1 web0p2 root 17749 2004-08-12 23:55 web0p2 ... -SNAP I´ve set up the mail-environment this way: default_mail_env = mbox:/var/spool/mail/:INBOX=/var/spool/mail/%u:INDEX=/var/spool/mail/indexes/%u The problem is, that the directory "indexes" has permisions that only the owner can write to (well, I could change permissions, but?) and that the ".subscription" file and "Trash" folder is directly in this directory. So if I add a second user (e.g. web0p1) I got error messages imho due to the use of the "same" folder....? What would be the proposed setup for this system with mostly non-local users without real home directories and all their mbox in a shared directory? Thanks for your time! Daniel

2 1

[Dovecot] LDAP-auth not working
by Roger Bystrom 15 Aug '04

15 Aug '04

I have set up dovecot to use ldap authentication, but it only results in dovecot crashing without any error message that would indicate why this is the case. I have spent *many* hours trying to fix this problem, but not found any solution as to why it should crash. maillog: Aug 15 10:05:08 era dovecot: Dovecot starting up Aug 15 10:05:09 era dovecot: Auth process died too early - shutting down Aug 15 10:05:09 era dovecot: child 20833 (auth) killed with signal 11 Aug 15 10:05:09 era imap-login: fd_send(-1) failed: Broken pipe Settings to indicate ldap in dovecot.conf: auth_userdb = ldap /etc/dovecot-ldap.conf auth_passdb = ldap /etc/dovecot-ldap.conf Basically, the settings in dovecot-ldap.conf is: hosts = localhost:389 dn = cn=dovecot,ou=servers,dc=remiss,dc=org dnpass = nada base = dc=remiss,dc=org deref = never scope = subtree user_attrs = uid,homeDirectory,,,uidNumber,gidNumber user_filter = (&(objectClass=posixAccount)(uid=%u)) pass_attrs = uid,userPassword using ldapsearch -x -D "cn=dovecot,ou=servers,dc=remiss,dc=org" -w nada .... is successful. Therefor I am wondering what in the world that causes "Auth process" to die too early. Output of strace -f dovecot -F is available from http://remiss.org/download/log Pid of auth-process here is 23286. Any help is appreciated. Thanks, Roger.

2 2

[Dovecot] Dovecot Local Delivery Agent
by news.gmane.org 12 Aug '04

12 Aug '04

Hi I noticed in a post that Timo might start work on a LDA Great! If so, here is something I would really like included. Support for PAM There is quite a lengthy reason behind this. In my organisation, user accounts are created on ldap. It is up to the services to create home directories whenever the user first uses them. For instance, Samba will do this the first time they connect to their windows home share. This achieved in other places using pam, using the pam_mkhomedir module. The MTA we run, Exim, is incapable of creating the home directory automatically, or using PAM for local delivery, thus we have the problem that when an account is created in the LDAP directory, it cannot receive email until the user first logs in through IMAP - Dovecot calls pam, which creates the home directory :-) Also attributing to this is the fact that exim is configured to deliver email into $home using maildir format rather than a mbox mail spool. We needed to do this because of the huge size of some of the inboxes of our users. This caused a severe amount of i/o blocking. So far, I have been unable to find a LDA capable of doing this. Since we migrated to dovecot, performance has improved ten-fold. I will give it a week then show you the graphs to prove it! Keep up the great work! Regards -- Chris Hills IT Services North East Worcestershire College

6 10

Re: [Dovecot] Newbie about Mbox or Maildir
by alan premselaar 11 Aug '04

11 Aug '04

Zoong Pham wrote: > > >>-----Original Message----- >>From: dovecot-bounces(a)dovecot.org >>[mailto:dovecot-bounces@dovecot.org]On >>Behalf Of nino(a)swiftdsl.com.au >>Sent: Tuesday, 10 August 2004 3:07 PM >>To: dovecot(a)dovecot.org >>Subject: [Dovecot] Newbie about Mbox or Maildir > > >>Thanks in advance. I am not sure if my system is setup to use >>'mbox' or >>'maildir'. How do I find this out? > > >>I am running an OpenBSD (v3.5) box with an Intel P3 >>motherboard. I have >>installed the OpenBSD port of Dovecot (0.99.10) and have >>manually started >>dovecot and configured the ssl certificates as per the >>documentation. As >>far as I can tell there is no problems but I am confused >>about 'mbox' and >>'maildir' > > > It's mbox. > The default MTA of OpenBSD is Sendmail. > More specifically, this is related to your local delivery agent (LDA). Although I'm not extremely familiar with default OpenBSD installations, it's been typical for default RedHat installations (up to and including RH 9) to have sendmail installed and configured to use procmail for its LDA. while recent versions of procmail can support maildir format, it defaults to using mbox format. alan

2 2

[Dovecot] mkdir imap with user@domain.com
by wiki kaha 11 Aug '04

11 Aug '04

I have a bit a problem. In a virtual domain enviroment i use for login "user(a)domain.com" and the password. in the mysql authentication it works beautiful with %d and %u placeholder. Now when is whould like ad a folder via imap i get an error imap(user(a)domain.com): mkdir(/var/mail/domain.com/user@domain.com/.test) failed: No such file or directory It should be mkdir(/var/mail/domain.com/user/.test) Is there a way to configure this? Thanks Regards Karl-Heinz __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 2

[Dovecot] [PATCH] RPA authentication mechanism
by Andrey Panin 10 Aug '04

10 Aug '04

Hello all, attached patch implements Compuserve RPA athentication mechanism. Tested with: - Eudora 6 (uses Compuserve "Virtual Key" RPA software); - TheBat! 2.11 (uses it's own RPA implementation). I hope it can be useful for someone. Best regards. -- Andrey Panin | Linux and UNIX system administrator pazke(a)donpac.ru | PGP key: wwwkeys.pgp.net

2 2

FW: [Dovecot] dovecot-auth: Aug 04 10:48:29 Fatal: Unknown userdb type'mysql'
by Alex Low (e-wise) 10 Aug '04

10 Aug '04

After better looking in the config.log, We found this, mysql wasn't compiled because of this; /usr/lib/mysql/libmysqlclient.a(my_compress.o)(.text+0xd8): In function `my_compress_alloc': : undefined reference to `compress' /usr/lib/mysql/libmysqlclient.a(my_compress.o)(.text+0x171): In function `my_uncompress': : undefined reference to `uncompress' I am using Fedora Core 2, using own compiled mysql 4.x rpm's. Timo Sirainen wrote: It looks like it's needed to be linked with zlib. Hmm. I haven't heard this to be necessary before. It seems to be statically linked in my mysql library. I think it'd work with: LDFLAGS=-lz ./configure --with-mysql And indeed adding -lz to LDFLAGS= in the spec file helped. Anyways I have dovecot rpm for Fedora Core 2 compiled with mysql 4. So if anybody want it, mail away. Greets, Alex _____ From: dovecot-bounces(a)dovecot.org [mailto:dovecot-bounces@dovecot.org] On Behalf Of Alex Low (e-wise) Sent: woensdag 4 augustus 2004 11:15 To: dovecot(a)dovecot.org Subject: [Dovecot] dovecot-auth: Aug 04 10:48:29 Fatal: Unknown userdb type'mysql' Hi, I am trying this way(mailinglist), as I cant find good 'support'/howto/tutorials on the website. I am running Fedora Core II, using postfix with mysql, and I want to use dovecot as imap server. Now I installed Dovecot using dag wieers SRPM, I compiled it with mysql, pgsql; %configure \ --with-ssl="openssl" \ --with-ssldir="%{_datadir}/ssl" \ --with-ldap \ --with-pgsql \ --with-mysql \ --with-cyrus-sasl2 \ --with-rawlog %{__make} %{?_smp_mflags} After compiling it, I installed the rpm. No problem at all. I configure the dovecot.conf like this; #auth = plain digest-md5 #auth_methods = plain digest-md5 auth_userdb = mysql /etc/dovecot-mysql.conf auth_passdb = mysql /etc/dovecot-mysql.conf default_mail_env = maildir:/home/mail/virtual/%d/%n # 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 = /tmp/dovecot/log1 # For informational messages, use this logfile instead of the default info_log_path = /tmp/dovecot/log2 Then I try run it: [root@octa SPECS]# cat /tmp/dovecot/log1 dovecot-auth: Aug 04 10:48:29 Fatal: Unknown userdb type 'mysql' dovecot: Aug 04 10:48:29 Error: Auth process died too early - shutting down dovecot: Aug 04 10:48:29 Error: child 2118 (auth) returned error 89 imap-login: Aug 04 10:48:29 Fatal: fd_send(-1) failed: Broken pipe dovecot-auth: Aug 04 11:04:39 Fatal: Unknown userdb type 'mysql' dovecot: Aug 04 11:04:39 Error: Auth process died too early - shutting down dovecot: Aug 04 11:04:39 Error: child 11137 (auth) returned error 89 imap-login: Aug 04 11:04:39 Fatal: fd_send(-1) failed: Broken pipe imap-login: Aug 04 11:04:39 Fatal: fd_send(-1) failed: Broken pipe [root@octalys SPECS]# cat /tmp/dovecot/log2 dovecot: Aug 04 10:48:28 Info: Dovecot starting up dovecot: Aug 04 11:04:38 Info: Dovecot starting up [root@octalys SPECS]# Can anyone tell me whats wrong please ? Thank you in advance, Alex

1 0

RE: [Dovecot] Newbie about Mbox or Maildir
by Zoong Pham 10 Aug '04

10 Aug '04

> -----Original Message----- > From: dovecot-bounces(a)dovecot.org > [mailto:dovecot-bounces@dovecot.org]On > Behalf Of nino(a)swiftdsl.com.au > Sent: Tuesday, 10 August 2004 3:07 PM > To: dovecot(a)dovecot.org > Subject: [Dovecot] Newbie about Mbox or Maildir > Thanks in advance. I am not sure if my system is setup to use > 'mbox' or > 'maildir'. How do I find this out? > I am running an OpenBSD (v3.5) box with an Intel P3 > motherboard. I have > installed the OpenBSD port of Dovecot (0.99.10) and have > manually started > dovecot and configured the ssl certificates as per the > documentation. As > far as I can tell there is no problems but I am confused > about 'mbox' and > 'maildir' It's mbox. The default MTA of OpenBSD is Sendmail. I have similar configuration here. Let me know if you need any help. Cheers, Zoong PHAM UNIX systems Administrator ICT - Information, Communications & Technology Mercy Health & Aged Care 678 Victoria Street Richmond 3121 ___________________________________________________________________________________ THIS EMAIL IS CONFIDENTIAL. If you have received this email in error please forward it to information(a)mercy.com.au. It may contain personal information and it is intended for the addressee only. If you receive this email in error you must not use, copy forward, print or otherwise disseminate any information it contains. Mercy Health & Aged Care is a Catholic community benefit organisation. Each year one in twenty Victorian families are touched by the services we provide. Visit www.mercy.com.au for more information. Our services include: * Mercy Hospital for Women - East Melbourne (moving to Heidelberg in 2005) * Werribee Mercy Hospital - Werribee * Mount Alvernia Mercy Hospital - Bendigo * Mercy Hospice - Western suburbs * O'Connell Family Centre - Canterbury * Corporate Office - Richmond * Rice Village - Geelong * Tullamore Mercy - Montrose * Eventide Mercy - Colac * Bethlehem Home for the Aged - Bendigo *

1 0

[Dovecot] Newbie about Mbox or Maildir
by nino＠swiftdsl.com.au 10 Aug '04

10 Aug '04

Hi, Thanks in advance. I am not sure if my system is setup to use 'mbox' or 'maildir'. How do I find this out? I am running an OpenBSD (v3.5) box with an Intel P3 motherboard. I have installed the OpenBSD port of Dovecot (0.99.10) and have manually started dovecot and configured the ssl certificates as per the documentation. As far as I can tell there is no problems but I am confused about 'mbox' and 'maildir' Any assistance is appreciated. Thankyou NS

1 0

[Dovecot] Debian sarge release and dovecot
by Jaldhar H. Vyas 10 Aug '04

10 Aug '04

In what must surely be the first sign of the apocalypse, Debian is actually freezing in preperation for a new release. Probably the last day for uploads will be August 17. Is there likely to be another dovecot release by then? In the event of 0.99.10.9 being the released version, are there any other patches Debian users would like me to include? -- Jaldhar H. Vyas <jaldhar(a)debian.org> La Salle Debain - http://www.braincells.com/debian/

3 4

[Dovecot] Problem moving folders with Thunderbird
by Loek 10 Aug '04

10 Aug '04

I can move around folders to sub-folders in an IMAP account on my dovecot server, but when I try to move a sub-folder back to the top-level (by dragging it to the account name), I get an error: "The current command did not succeed. The mailserver responded: Mailbox exists." It doesn't exist on the server though, and I can create a folder with that name on the top-level. But it is a little annoying. I am using TB 0.7.2. I tried different IMAP server settings in Thunderbird under the account options, but without success. Loek

3 3

[Dovecot] Both mbox and Maildir
by Yann Rouillard 09 Aug '04

09 Aug '04

Hi, I would like to know if it's possible to configure dovecot so that it use mbox file format for the INBOX mailbox but Maildir format for all the subfolders. My problem is I would like an IMAP server which allow to easily create folders and subfolders of folders, but at the same time I don't want to break all MUA which rely on /var/mail/johndoe in mbox format. Thanks in advance. Yann

2 1

Re: [Dovecot] Dovecot Local Delivery Agent
by Apostolos Papayanakis 09 Aug '04

09 Aug '04

Timo, a very simple save-only LDA would be enough for many configurations. Other full featured LDAs such as procmail could also use dovecot-LDA as the final delivering program. This would keep gigantic mboxes always indexed, and make access on them snappy always, especially on the important first access. However this should not take many programming resources away from releasing a robust, migration-ready v1.0. I am eager to migrate 25,000 users (~100GB), onto dovecot and then provide them more disk space, which now I dare not allow them. Keep up the excelent work! apap > Date: Mon, 9 Aug 2004 02:03:53 +0300 > From: Timo Sirainen <tss(a)iki.fi> > Subject: Re: [Dovecot] Dovecot Local Delivery Agent > To: Dovecot mailing list <dovecot(a)dovecot.org> > ... > Anyway, I'm still hoping someone else to do the LDA so I don't have to > worry about it.

1 0

[Dovecot] Little problem with dovecot using mbox format
by Jd 09 Aug '04

09 Aug '04

Hi everyone, this is my first post on this mailing list. I recently installed postfix+dovecot+fetchmail on OpenBSD for my dad's office. (dovecot is setup as an imap server using mbox). Everything worked flawlessly...until now. I don't know why, but now some emails seem to de-double themselves. For exemple, yesterday morning I printed out all the emails. To my surprise 30 minutes later, I received 60 'new'' emails. But these 60 emails weren't new, they were all copies of emails I had printed out earlier. Some emails were repeated some 10-15 times. Now we never got this kind of problem until recently. Has anyone ever experienced this kind of problem? If so how did you fix the situation? Most responses I got from the openBSD mailing list was to use maildir format. Any insight into this? Thanks, Jean-Daniel BTW we don't get THAT much email, maybe 200 a day for that 1 account that seems to be acting weird now.

3 2

Re: [Dovecot] Dovecot Local Delivery Agent
by Mark E. Mallett 09 Aug '04

09 Aug '04

On Mon, Aug 09, 2004 at 02:07:27AM +0300, Timo Sirainen wrote: > On 7.8.2004, at 07:25, Mark E. Mallett wrote: [ I hope you don't mind me answering this back on the list; it seems like it's relevant. ] > > >That's probably just a result of my poor communications skills. I did > >include very brief LICENSE and FUTURE files with the sources, and those > >files probably led you to that conclusion. For clarification, I do > >intend that the program be open source, but I feel that there are some > >things that I should still finish up myself before foisting it off on > >any potential contributers. It's not a matter of "I don't want you to > >have it" -- it's more a matter of "I don't feel right burdening you > >with > >filling in holes just yet" (for the generic "you"). (That makes it > >sound like it's not usable: it's quite usable right now. There are > >just > >features still left to add.) > > > >Plus, as with many other packages and maintainers, I just want to > >control any official version. > > Well, doesn't that mean that it's currently not really open source? As > in I can't modify and re-distribute it (with possibly different name)? My current goal is to make it mature enough and good enough where people might actually want to do that -- as I say, by finishing up some of the things that are still undone. Also there are a couple of things that are hardwired to the environment here (particularly, the way that the IP addresses are extracted for DNSBL tests), that I felt that I should make more general before making it open. The latest sources are available online to anybody who wants them, for use in your own environment, for experimentation and trial, but not for redistribution; but indeed if there was some demand I would probably open it up sooner than later. So far nobody has been beating down the door for it (admittedly I haven't really mentioned it in very many places; I think only here and on the bsdi-users list). But yeah, the plan is to make it so that you can modify it and redistribute it. I don't have any kind of hard and fast position on when, though. I'm sure most anyone could convince me to open it up most any time, if there was good reason to do so. mm

1 0

[Dovecot] search functionality
by Cor Bosman 06 Aug '04

06 Aug '04

Hi all, if I give the following command in test32: A004 UID SEARCH CHARSET ISO-8859-1 ALL TEXT {4} Test The response is: * SEARCH A004 OK Search completed. If I say: A004 UID SEARCH CHARSET ISO-8859-1 ALL FROM {4} Test The response is: * SEARCH 217 350 A004 OK Search completed. The RFC says that 'TEXT' is supposed to result in a list of messages where the search string is in either the body or the header. Obviously the string is there in this example, else the FROM search wouldnt have given a result. Tracing the process shows that dovecot never actually checks the email messages for the string. It does for a BODY search but not for a TEXT search. Is this on purpose? Cor

2 1