- dovecot - dovecot.org

[Dovecot] dovcot+offlineimap+gmail: INBOX empty, mail doubled
by Uwe Brauer 11 Dec '12

11 Dec '12

Hello I have used for years offlineimap-6.2.0 dovecot-imapd 1:1.2.9 in Kubuntu 10.04 Together with a imap server of my university. Yesterday we switched to google, which I know, is not a real imap server. I have 2 problems and the first I think has to do with either an old version of offlineimap or a bad configuration file: - All folders are downloaded+ Gmail[All Mail] so doubling my mail. - My INBOX folder is empty, however this is the only folder for which offlinemap gives the following warning: Syncing INBOX: Gmail -> MappedIMAP WARNING: UID validity problem for folder INBOX (repo UniLocal) (saved 1309334376; got 1355232397); skipping it So maybe this is also a offlineimap fault. In any case I have googled around and found out that I am not the only person suffering this problem. I have attached my configuration file in the hope that may be somebody could give me a hint. Thanks in advance Uwe Brauer --8<------------------------schnipp------------------------->8--- [general] accounts = Uni ui = Noninteractive.Basic maxsyncaccounts = 1 [Account Uni] localrepository = UniLocal remoterepository = UniRemote [Repository UniLocal] type = IMAP ssl = no remotehost = localhost remoteuser = myuser remotepass = mypasswd maxconnections = 2 [Repository UniRemote] type = Gmail # ssl =no ssl =yes #remotehost = ucimap.ucm.es remotehost = imap.gmail.com remoteuser = myuser remotepass = mypasswd # nametrans = lambda foldername: re.sub ('^\[gmail\]', 'bak', # re.sub ('sent_mail', 'sent', # re.sub ('starred', 'flagged', # re.sub (' ', '_', foldername.lower())))) folderfilter = lambda foldername: foldername in ['INBOX'] idlefolders = ['INBOX'] folderfilter = lambda foldername: foldername not in '[Gmail]/All Mail' sslcacertfile = /etc/ssl/certs/ca-certificates.crt maxconnections = 1 realdelete = yes # Don't sync shared folders # folderfilter = lambda foldername: not re.search('Shared Folders', foldername) # automatic stuff maxsyncaccounts = 1 quick = 10 autorefresh = 5 keepalive = 60 holdconnectionopen = yes # This will suppress anything but errors ui = quiet --8<------------------------schnapp------------------------->8--- --8<------------------------schnipp------------------------->8--- version_ignore=yes first_valid_uid = 1 log_path = /var/log/dovecot.log ssl_cert_file = /etc/ssl/certs/dovecot.pem ssl_key_file = /etc/ssl/private/dovecot.pem # mail_location = maildir:/var/spool/mail/%u # not sure about the following mail_location = maildir:/var/spool/mail/%u:INBOX=/var/spool/mail/%u maildir_copy_with_hardlinks = yes protocol imap { listen = 127.0.0.1:143 ssl_listen = 127.0.0.1:943 } auth default { mechanisms = plain # defines users/passwords passdb passwd-file { args = /etc/dovecot/passwd } userdb static { args = uid=mail gid=mail home=/var/spool/mail/%u } } --8<------------------------schnapp------------------------->8---

1 0

Re: [Dovecot] Automatically Cleaning Kerberos Credential Cache Files
by Maura Dailey 11 Dec '12

11 Dec '12

On 12/10/2012 05:31 PM, Ben Morrow wrote: > At 3PM -0500 on 10/12/12 you (Maura Dailey) wrote: >> I'm in a situation here at work where I'm trying to support a mixed >> network of OS X and RHEL desktop machines with a Postfix/Dovecot >> combination. >> - user account information is stored in LDAP >> - user credentials are in MIT Kerberos >> - server is running RHEL 6/Dovecot 2.0.9/Postfix 2.6.6 >> >> I am currently using the PAM passdb module to authenticate my users (I >> began to have trouble with using GSSAPI directly). After I implemented >> it, a few weeks later, I noticed that some users were no longer getting >> their mail if they hadn't logged in during the past day. Postfix's mailq >> showed that hundreds of messages were backing up in the queue. I >> eventually tracked it down to leftover Kerberos credential cache files >> (/tmp/krb5cc_????) sitting in /tmp on the mail server. The presence of >> expired credential files was preventing Postfix from delivering mail to >> those users' mail spools. If I delete the credential files manually, >> Postfix immediately delivers the queued emails. > This is rather odd. Is krb5-authenticated NFS involved here, or does > Postfix's delivery make any other use of Kerberos? The only other thing > I can think of is that so many expired ccaches are accumulating that the > user goes over their inode quota. Each user has one credential cache file in /tmp on the mail server after logging into Dovecot. We aren't using randomized names, so everything is in the standard format /tmp/krb5cc_uid. We do use KRB5 authenticated (and encrypted) NFS, but we don't deliver mail to home directories. Since all users are "real" users, and our office size is small, everyone has a mail spool directory on the mail server. Postfix is configured to use Dovecot for Kerberos. The relevant lines in its /etc/postfix/main.cf are as follows: smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject smtpd_sasl_security_options = noanonymous >> Currently, I have a cron job deleting the files manually every night. >> Obviously, this is a cruddy solution. > Well, I don't know about that: obviously, it would be a good idea to > work out what's going on here, in case it causes anything else to go > wrong, but a cronjob clearing out /tmp is a good idea in any case. Fair enough. And of course, I get a cache file every time I use sudo or log in through a GUI. Those aren't cleaned up either! Maybe I should be deleting credential cache files on all the machines every night. Those cache files have never given me a problem, though. >> I have Dovecot configured on a >> RHEL 6 box. The Pam stack on a RHEL 6 machine uses sssd (pam_sss.so) for >> authentication with Kerberos, not pam_krb5.so. I'm trying to track down >> which piece of the puzzle is responsible for cleaning up leftover >> credential caches. Is there a configuration option I can pass to >> Dovecot's passdb directly to clean up these cache files? > There are two relevant Dovecot settings: passing setcred=yes to the pam > passdb will make Dovecot call pam_setcred, and passing session=yes will > make it open and immediately close a PAM session. (Probably it ought to > wait until the IMAP user logs out to close the session, but currently it > can't do that because of the way the passdb lookups are done.) Changing > either of these may have an effect, depending on when exactly your PAM > module creates and destroys ccaches. I've tried session=yes by itself, but I don't think I've tried it with setcred=yes. I'll throw it in there and give it a try after I send this email. >> Do others >> generally have more success using a custom PAM stack with pam_krb5.so >> instead of pam_sss.so? > Well, I don't use RH (I use FreeBSD), but I use and would recommend Russ > Allbery's pam_krb5.so, which may or may not be the same as the normal > pam_krb5.so provided by your system. It has options to control whether > and where ccaches are created; assuming Dovecot doesn't need krb5 creds > (say, for NFS), you would probably be better off telling it not to > create a permanent ccache at all. > > http://www.eyrie.org/~eagle/software/pam-krb5/ I haven't had to configure pam_krb5.so directly before (we use the Red Hat/Fedora configured default, pam_sss.so, which claims to be a one stop shop for LDAP/Kerberos/NIS,etc.), but it does seem to have more options. We certainly don't need credential caches to stick around for email users. All the mail spools are stored on locally mounted storage on the mail server. >> Poring over sssd's configuration options didn't >> reveal anything useful. I'm still not sure why Postfix even cares if >> there are expired credential cache files in /tmp at all. >> >> I'm back to trying GSSAPI directly again as well in the meantime on a >> few test clients. When I used that in the past, users were getting >> issued duplicate Kerberos tickets and users were forced to log into the >> mail server directly using SSH after a day in order to get their mail to >> work (seemingly a related issue). If I get those same errors again, I'll >> start another thread. > This certainly does all sound related. What are the ccache files called: > are they just /tmp/krb5cc_UID or is there a random portion as well? Are > they being created with the correct permissions, and are there any > security policies (SELinux or ACLs of some kind) set up which might > interfere with their creation or destruction? No random portion (the only application we have configured with random ccache names is SSH), just the usual /tmp/krb5cc_uid. Permissions appear correct, they belong to the appropriate user and group accounts. The SELinux permissions are set to: system_u:object_r:user_tmp_t:s0. This is different from the machine's credential cache (system_u:object_r:gssd_tmp_t:s0), but I've disabled and re-enabled SELinux during different parts of my testing and didn't notice any errors. Using GSSAPI directly doesn't create any cached credential files on the server. However, I just verified that I'm still sporadically getting the duplicate tickets (two lines for imap/hostname.server.com(a)SERVER.COM, with identical expiration dates). It comes and goes. I have a few users testing it for me, and they'll let me know if their logins break tomorrow like they have in the past once the normal log in period elapses. Since the "fix" for that problem is to log into the mail server, I have a hard time testing for the problem myself (being logged into the mail server nearly continuously just now). > What happens if you log in as an ordinary user (preferably using the > same PAM stack as Dovecot uses), use klist to find the ccache name and > 'ls -i' to find its inode number, then manually kinit again? Does the > kinit succeed, and does the new ccache have a different inode number > from before? Does the ccache file get removed when you log out? I've noticed that the ccache files for regular users do not get deleted when they log out. On another user's workstation, I found a ccache file for my account from a week ago (my current session was using a randomly generated SSH ccache file). I ran a command with sudo to force it to reauthenticate with pam_sss, and the timestamp on the ccache file was updated and the inode changed. My best guess is that pam_sss.so just doesn't do ccache cleanup. > Ben > Thanks for taking a look, I appreciate all the suggestions. This problem's been driving me up a wall for weeks now. I only just managed to narrow down the cause in the last few days. If I can't get a fix working in Dovecot, I'll try tackling it from a different perspective. I understand why Dovecot might not be cleaning up credential files (especially if it's just calling PAM normally), but I definitely do not understand why Postfix is behaving the way it does. If I can just get GSSAPI to work, I could probably bypass the problem as well. - Maura Dailey maura(a)eclipse.ncsc.mil

2 2

[Dovecot] Switch from MySQL/CourierMail to MySQL/Dovecot
by Robert Moskowitz 11 Dec '12

11 Dec '12

Hello, new here. I am a Centos/Fedora user, and for the past 3 years have been running my mail server using Postfix/MySQL/CourierMail/Squirrelmail on Fedora. The current incantation of the tutorial is at: http://www.howtoforge.com/virtual-users-and-domains-with-postfix-courier-my… Well it is time to rebuild my mailserver; this time on Centos 6.3. My goal is to use supplied rpms, not to build my own (and rebuild everytime there is an important update). So I am pulling quotas which has been a pain anyway, and I am investigating using Dovecot in place of CourierMail. In Centos 6.3, the version of Dovecot is: 2.0.9-2 I am looking for a tutorial to assist in the setup, as I am nowhere an expert on any of this (I am a communications security expert in the IETF and IEEE 802). There are a couple items that I have come to depend on in my current setup that are musts in anything new: Virtual user/domain That is, not only virtual domains, but also users defined by domain. So in the MySQL user table, the email value is set to user@domain. Thus a user can receive/send mail from multiple domains with the same addr and only those domains defined for the user in the user table. Obviously there is no coupling of Linux user accounts and email accounts. CourierMail is storing mail under /home/vmail/domain/user/... Encrypted passwords The passwords in the user table in MySQL are encrypted. This will be used to auth the user for POPing or IMAPing and sending their mail. I have encountered a few tutorials where it seems like passwords are stored in the clear? Anyway, not much else! Well as far as the user interface is concerned. Postfix with clamav and spamassassin and maybe one or two extras. And SquirrelMail for Webmail. A better gui than phpMyAdmin for maintaining the tables would be nice, but I don't have a lot of users, so it works well enough. Can someone point me to a tutorial best suited to my needs? Also any firewall rules, as I don't want to turn off iptables (and ip6tables) and any SELinux policy rules to add. Oh, and IPv6 will be a must in the near future, so anything needed to ensure IPv6 working right as well. Thanks

2 3

[Dovecot] Automatically Cleaning Kerberos Credential Cache Files
by Maura Dailey 11 Dec '12

11 Dec '12

I'm in a situation here at work where I'm trying to support a mixed network of OS X and RHEL desktop machines with a Postfix/Dovecot combination. - user account information is stored in LDAP - user credentials are in MIT Kerberos - server is running RHEL 6/Dovecot 2.0.9/Postfix 2.6.6 I am currently using the PAM passdb module to authenticate my users (I began to have trouble with using GSSAPI directly). After I implemented it, a few weeks later, I noticed that some users were no longer getting their mail if they hadn't logged in during the past day. Postfix's mailq showed that hundreds of messages were backing up in the queue. I eventually tracked it down to leftover Kerberos credential cache files (/tmp/krb5cc_????) sitting in /tmp on the mail server. The presence of expired credential files was preventing Postfix from delivering mail to those users' mail spools. If I delete the credential files manually, Postfix immediately delivers the queued emails. Currently, I have a cron job deleting the files manually every night. Obviously, this is a cruddy solution. I have Dovecot configured on a RHEL 6 box. The Pam stack on a RHEL 6 machine uses sssd (pam_sss.so) for authentication with Kerberos, not pam_krb5.so. I'm trying to track down which piece of the puzzle is responsible for cleaning up leftover credential caches. Is there a configuration option I can pass to Dovecot's passdb directly to clean up these cache files? Do others generally have more success using a custom PAM stack with pam_krb5.so instead of pam_sss.so? Poring over sssd's configuration options didn't reveal anything useful. I'm still not sure why Postfix even cares if there are expired credential cache files in /tmp at all. I'm back to trying GSSAPI directly again as well in the meantime on a few test clients. When I used that in the past, users were getting issued duplicate Kerberos tickets and users were forced to log into the mail server directly using SSH after a day in order to get their mail to work (seemingly a related issue). If I get those same errors again, I'll start another thread. The output of doveconf -N: # 2.0.9: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-279.14.1.el6.x86_64 x86_64 Red Hat Enterprise Linux Server release 6.3 (Santiago) ext4 auth_cache_size = 10 k auth_cache_ttl = 5 hours auth_default_realm = server.com auth_gssapi_hostname = hostname.server.com auth_krb5_keytab = /etc/dovecot/dovecot.keytab auth_mechanisms = gssapi plain auth_realms = server.com auth_username_format = %n auth_verbose = no disable_plaintext_auth = yes listen = * mail_location = maildir:/var/spool/mail/%u mail_privileged_group = mail mbox_read_locks = fcntl mbox_write_locks = fcntl namespace { inbox = yes location = prefix = separator = / type = private } passdb { driver = pam } protocols = pop3 imap service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } } ssl = yes ssl_cert = </usr/share/ssl/private/mail.server.com.pem ssl_key = </usr/share/ssl/private/mail.server.com.pem userdb { driver = passwd } protocol imap { imap_client_workarounds = tb-extra-mailbox-sep mail_plugins = " listescape" } Thanks for any pointers, Maura Dailey maura(a)eclipse.ncsc.mil

2 1

[Dovecot] dsync help?
by Torbjorn Astlind 10 Dec '12

10 Dec '12

Hi all, I have dovecot serving aprox 200 users through mbox, but the time has come to migrate to a new server, and to use Maildir. Using rsync from the old server I get all user data, i.e /home/*, and inboxes i.e /var/mail/* to a new server. This has worked well for some time as backup. The dsync should convert everything to Maildir, and it does... to an extent. (linebrakes for easy viewing) What I see, is that often, the /home/mail/xxx is NOT resulting in /home/xxx/Maildir/cur All mailboxes from /home/xxx, are properly converted to /home/xxx/Maildir/.name_of_ box Am I misunderstanding something? I get it to work sometimes if I delete the ~/Maildir completely before doing the dsync. All, and any help most welcome, Torbjörn for i in `cat /home2/torbjorn/SCRIPTS/userlist.txt`; do dsync -D -v -f -u $i -c /etc/dovecot/alt_config/10-mail.MBOX.conf backup maildir:~/Maildir; done > /home2/torbjorn/SCRIPTS/mb2mdRES.txt 2>&1 the -c 10.mail.MBOX.conf contains, the parts I think are relevant for the dsync operation: mail_location = mbox:~/home:INBOX=/home/mail/%u namespace { type = private separator = '/' inbox = yes } dsync(root): Debug: Effective uid=501, gid=501, home=/home/torbjorn dsync(root): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mbox:~/home:INBOX=/home/mail/torbjorn dsync(root): Debug: fs: root=/home/torbjorn/home, index=, control=, inbox=/home/mail/torbjorn, alt= dsync(root): Debug: Effective uid=501, gid=501, home=/home/torbjorn dsync(root): Debug: Namespace : type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/Maildir dsync(root): Debug: maildir++: root=/home/torbjorn/Maildir, index=, control=, inbox=/home/torbjorn/Maildir, alt= dsync(root): Debug: Namespace : /home/torbjorn/Maildir doesn't exist yet, using default permissions dsync(root): Debug: Namespace : Using permissions from /home/torbjorn/Maildir: mode=0700 gid=-1 dsync(torbjorn): Debug: Namespace : Using permissions from /home/torbjorn/home: mode=0700 gid=-1

1 0

[Dovecot] IMAP instead of Maildir on Ubuntu Precise
by Thufir 10 Dec '12

10 Dec '12

Why is dovecot using Maildir and not IMAP. Or is it using even using Maildir at all? Currently I'm using mailman, postfix and dovecot to manage a mailing list. Mail is sent to thufir(a)dur.bounceme.net which the "mail server delivery agent stack provided by Ubuntu server team" of dovecot-postfix handles fine, keeping it locally, so far as it goes. The mail ends up in /home/thufir/Maildir, which the balsa mail client reads fine, as it handles Maildir fine. However, I would like to use dovecot-imapd which is installed. However, it's not clear quite how to switch over to IMAP. I see: root@dur:~# root@dur:~# nl /usr/share/dovecot/protocols.d/imapd.protocol 1 protocols = $protocols imap root@dur:~# root@dur:~# grep protocol /etc/dovecot/dovecot.conf # Enable installed protocols !include_try /usr/share/dovecot/protocols.d/*.protocol root@dur:~# which indicates to me that IMAP is configured. So, why is mail showing up using Maildir? I'm looking at: "Once you have chosen, amend the following line in the file /etc/dovecot/dovecot.conf: protocols = pop3 pop3s imap imaps" https://help.ubuntu.com/community/Dovecot Admittedly, I've not looked too closely into Dovecot man pages as I don't want to get too deep into the weeds on that if it's not even Dovecot I need to configure. I'm assuming that it's dovecot which is using Maildir: root@dur:/etc/postfix# root@dur:/etc/postfix# grep dovecot main.cf smtpd_sasl_type = dovecot smtpd_sasl_path = private/dovecot-auth mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m "${EXTENSION}" root@dur:/etc/postfix# Can I force dovecot to only ever use IMAP and never use anything else? Is it maybe postfix which is using Maildir, and this is why my mail shows up as Maildir type mail? thanks, Thufir thufir@dur:~$ thufir@dur:~$ head .balsa/config -n 20 [mailbox-Inbox] Path=/var/mail/thufir Type=LibBalsaMailboxMbox Name=Inbox [mailbox-Outbox] Path=/home/thufir/Maildir/outbox Type=LibBalsaMailboxMbox Name=Outbox [mailbox-Sentbox] Path=/home/thufir/Maildir/sentbox Type=LibBalsaMailboxMbox Name=Sentbox [mailbox-Draftbox] Path=/home/thufir/Maildir/draftbox Type=LibBalsaMailboxMbox Name=Draftbox thufir@dur:~$

3 5

[Dovecot] Copying mailbox from one mailserver to another?
by Bjørn T Johansen 10 Dec '12

10 Dec '12

I see there is a tool called dsync that can do this but what are the cons of using dsync compared to just package the mailbox using tar and then untar the mailbox on the new server? Regards, BTJ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 2

[Dovecot] Performance problems while running doveadm purge
by Jost Krieger 08 Dec '12

08 Dec '12

I have a rather large and active mdbox (28 GB, 3M mess, 1200 deliveries/day). I usually have no problems working with those mails, and there is some batch processing going on (via doveadm). Every few weeks I try my luck running doveadm purge, and this a) crunches about 5GB (to be expected), b) takes rather long (ok), c) leads to long stretches of blocked mdbox, which is the problem. I always turn off the batch processing, but deliveries take so long that they sometimes give up after timeout (they will come back later), and the IMAP clients get blocked for long minutes. Sometimes even the purge run aborts because of 3-minute-timeouts. What could be going on here (2.1.10)? Jost -- | Jost.Krieger+sig(a)ruhr-uni-bochum.de Please help stamp out spam! | | Postmaster, JAPH, resident answer machine at RUB Comp. Center | | Sincere words are not sweet, sweet words are not sincere. | | Lao Tse, Tao Te King 81 |

3 2

[Dovecot] Dovecot director doveadm with switch "-A" error
by Ramon Frontera 08 Dec '12

08 Dec '12

Hi, we have a problem with our director proxy configuration. When we run on proxy server the doveadm command with -A switch, fails with the error: # doveadm -D quota get -A doveadm(user1): Debug: auth input: user=user1 proxy starttls=any-cert doveadm(user1): Error: Proxy is missing destination host doveadm: Error: Failed to iterate through some users If we execute the command with a single user, director assigns host and goes well, Example: # doveadm -D quota get -u user1 doveadm(user1): Debug: auth input: user=user1 proxy starttls=any-cert host=xx.xx.xx.xx proxy_refresh=450 Quota name Type Value Limit % User quota STORAGE 159401 2621440 6 User quota MESSAGE 341 - 0 We have tried different configurations and all goes wrong with this "-A" switch, Timo please, could you tell us if we have a missconfiguration or its a possible director bug ?? We really want execute the expire plugin on ours directors and them redirect to the backends servers of every user. thanks in advance. Our doveconf -n: # dovecot -n # 2.1.10: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-279.14.1.el6.x86_64 x86_64 CentOS release 6.3 (Final) auth_cache_size = 3 k auth_cache_ttl = 15 mins auth_debug = yes auth_verbose = yes base_dir = /var/run/dovecot/ default_client_limit = 30000 default_process_limit = 5000 dict { expire = mysql:/etc/dovecot/dovecot-dict-expire.conf.ext } director_doveadm_port = 990 director_mail_servers = mailserver1 mailserver2 director_servers = proxy1 doveadm_proxy_port = 24245 lmtp_proxy = yes mail_debug = yes mail_plugins = expire quota managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace inbox { location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { args = /etc/dovecot/dovecot-ldap-users.conf.ext driver = ldap } plugin { expire = Trash expire2 = Trash/* expire_dict = proxy::expire } postmaster_address = postmaster<at>company protocols = imap pop3 lmtp sieve service auth { client_limit = 27048 unix_listener /var/spool/postfix/private/auth { mode = 0666 } unix_listener auth-userdb { group = dovecot mode = 0660 } } service director { fifo_listener login/proxy-notify { mode = 0600 user = $default_login_user } inet_listener { port = 9090 } unix_listener director-userdb { mode = 0660 } unix_listener login/director { mode = 0666 } } service doveadm { executable = doveadm-server director inet_listener doveadm-server { port = 24245 } } service imap-login { executable = imap-login director inet_listener imap { port = 143 } inet_listener imaps { port = 993 ssl = yes } } service ipc { unix_listener ipc { user = dovecot } } service lmtp { client_limit = 1 inet_listener lmtp { port = 30025 } } service managesieve-login { executable = managesieve-login director } service pop3-login { executable = pop3-login director inet_listener pop3 { port = 110 } inet_listener pop3s { port = 995 ssl = yes } } ssl = required ssl_cert = </etc/pki/tls/certs/imap.crt ssl_key = </etc/pki/tls/private/imap.uib.es_privatekey.pem syslog_facility = local1 userdb { driver = prefetch } userdb { args = /etc/dovecot/dovecot-ldap-users.conf.ext driver = ldap } verbose_proctitle = yes protocol lmtp { auth_socket_path = director-userdb mail_plugins = expire quota sieve quota passdb { args = /etc/dovecot/dovecot-ldap-pass.conf.lmtp driver = ldap } } protocol doveadm { auth_socket_path = director-userdb } protocol imap { mail_max_userip_connections = 20 mail_plugins = expire quota } protocol pop3 { pop3_client_workarounds = outlook-no-nuls oe-ns-eoh } local ip/24/24 { doveadm_password = supersecretpassword } -- ------------------------------------------ Ramon Frontera Gallardo Universitat de les Illes Balears

2 9

[Dovecot] Dovecot G+ community
by Patrick Ben Koetter 08 Dec '12

08 Dec '12

For those who own a G+ account and don't mind seeing colors in a browser once in a while instead of staring at a black/white terminal all day long, join the Dovecot G+ community <https://plus.google.com/communities/112967413753095884716> p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich

1 0