userdb / user map with director
This is with dovecot-ee 2.2.18.2 on RHEL6
To handle backend and frontend on same machine, I'm using the following
hack, as previously outlined here:
[in director instance config]
passdb {
# See thread ending in:
# http://dovecot.org/pipermail/dovecot/2012-June/083817.html
# for why this has to be sql instead of 'static'
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}
[in /etc/dovecot/dovecot-sql.conf]
driver = sqlite
connect = /etc/dovecot/empty.db
password_query = select 'y' as proxy, \
NULL as password, \
'y' as nopassword, \
case '%a' \
when '110' then '10110' \
when '995' then '10110' \
when '143' then '10143' \
when '993' then '10143' end \
as port;
This works, but I was getting a failure on usernames, since director
instance didn't have a userdb.
So I tried the following:
[in config]
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf
}
userdb {
driver = prefetch
}
and appended the following to the SQL query:
password_query = select '%u' AS user, \
Then I see the following error in the log when I try to run the map
"Trying to iterate users, but userdbs don't support it"
and doveadm -i director director map returns:
Error: User listing returned failure
Error: user listing failed
[...]
I'm sure I'm missing something obvious, so is there an easy fix to make
this mapping work?
w
Re: EL6 EE package dependencies
On Fri, Apr 03, 2015 at 09:28:32AM +0900, Timo Sirainen wrote: > On 03 Apr 2015, at 04:22, Will Yardley wrote: > > I've been trying to upgrade Dovecot-ee package (on EL6/x86_64) from > > 2.2.15.8-1 to 2.2.16.2-1. It's complaining on these two dependencies: > > > > liblz4.so.1 > > libtextcat.so.0 > > > > Anyone know what packages I need to satisfy these dependencies? > Those dependencies came a bit unintentionally (maybe I should add some > --disable-auto-libs configure option to require explicit --with-* > parameters). 2.2.16.2-2 removes these dependencies. Thanks! I was able to figure out the right packages thanks to Eric's pointers, but this is even better. w
Re: EL6 EE package dependencies
On Thu, Apr 02, 2015 at 02:53:26PM -0600, Eric Broch wrote: > On 4/2/2015 1:22 PM, Will Yardley wrote: > > I've been trying to upgrade Dovecot-ee package (on EL6/x86_64) from > > 2.2.15.8-1 to 2.2.16.2-1. It's complaining on these two dependencies: > > > > liblz4.so.1 > > libtextcat.so.0 > > > > These would both seem to be related to plugins, and don't seem to be > > required as package dependencies by the RPM from what I can see from the > > SRPM. > > > > Anyone know what packages I need to satisfy these dependencies? > lz4-r127-1.el6.i686 and libtextcat-2.2-10.el6.i686 >From what source? I don't see them in any of the normal RHEL channels or in EPEL. I also don't see them in the Dovecot repo (or, unless I'm missing something, in the specfile's install requires). (BTW, I'm on x86_64 arch, but should be same package names either way).
EL6 EE package dependencies
I've been trying to upgrade Dovecot-ee package (on EL6/x86_64) from 2.2.15.8-1 to 2.2.16.2-1. It's complaining on these two dependencies: liblz4.so.1 libtextcat.so.0 These would both seem to be related to plugins, and don't seem to be required as package dependencies by the RPM from what I can see from the SRPM. Anyone know what packages I need to satisfy these dependencies?
Re: Dovecot 2.1.7 still accepting SSLv3 though disabled?
On Sun, Mar 15, 2015 at 02:42:00PM +0100, A. Schulze wrote: > Thomas Preissler: > The logging is right, but SSLv3 isn't used. > Today it's not uncommon that application /log/ SSLv3, where they /mean/ TLS1.x > > Some days ago where TLSv1 became available there wasn't a great > difference between SSLv3 and TLSv1 > So Developers reused large portions of code. That's what you see here.. > > > But when I explicitely test for SSLv3 support I get > > > > $ openssl s_client -connect $SERVERIP:993 -ssl3 > > > > CONNECTED(0003) > > 140683835029160:error:14094410:SSL > > routines:SSL3_READ_BYTES:sslv3 alert handshake > > failure:s3_pkt.c:1260:SSL alert number 40 > > 140683835029160:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl > > handshake failure:s3_pkt.c:598: > > That is the ultimate prove your server have SSLv3 disabled. Another fun trick for testing is nmap -p 993 --script ssl-enum-ciphers foo.example.com You'll then see (if you've got a new enough version) something like: [...] 993/tcp open imaps | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_RC4_128_MD5 - strong | TLS_RSA_WITH_RC4_128_SHA - strong [...] w
Re: Dovecot-ee
On Fri, Oct 17, 2014 at 12:08:38PM -0700, Timo Sirainen wrote: > On 17 Oct 2014, at 07:24, Davide wrote: > > Hi to all, i found that dovecot-ee repository access is free 0,00 $ > > cost; i'm running dovecot community 2.2.13 can i migrate my system > > to dovecot-ee? What are difference between Dovecot-ee and > > Dovecot-community? > > It's the same, except somewhat more stable with latest important > bugfixes. Sorry to respond so late, but just to confirm, assuming one can get repo access without paying (I could), there are no licensing issues to using Dovecot EE in production (without any of the proprietary modules)? I tried contacting the sales address, but didn't hear back. w
Re: disabling certain ciphers
On Tue, Dec 02, 2014 at 10:12:22AM -0800, Darren Pilgrim wrote: > On 12/2/2014 10:05 AM, Will Yardley wrote: > > I had some problems the first few times I restarted with ssl-params > > seeming to hang, but it finally works. > > That would have been dovecot generating the 4096-bit DH parameters. It > can take a bit, but Dovecot is quite fast at it. If Dovecot supported > it, you could use OpenSSL to generate tested-safe DH parameters and > supply them by file the same way you do for Postfix, nginx, etc. In this case, it was consuming a lot of CPU for 5+ minutes, and the .dat.tmp file hadn't been updated since the process started, so I'm not sure if something went wrong. strace on the ssl-params process itself (without following child procs, anyway) didn't seem to show anything happening. This happened for a couple of restarts. I enabled verbose ssl logging, restarted, and it seemed to work, then disabled verbose logging again, and it still works. w
Re: disabling certain ciphers
I had some problems the first few times I restarted with ssl-params seeming to hang, but it finally works. I am able to get it to work with just: ssl = required ssl_dh_parameters_length = 4096 ssl_parameters_regenerate = 0 ssl_prefer_server_ciphers = yes ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = HIGH+kEECDH:HIGH+kEDH:!3DES:!aNULL:@STRENGTH Thanks for your help! w
Re: disabling certain ciphers
On Tue, Dec 02, 2014 at 08:34:50AM -0800, Darren Pilgrim wrote: > On 12/1/2014 9:44 PM, Will Yardley wrote: > > On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote: > >> On 12/1/2014 4:43 PM, Will Yardley wrote: > >>> Can you use both ssl_protocols *and* ssl_cipher_list in the same config > >>> (in a way that's sane)? > >> > >> Yes to both. If you need to support older clients: > > But why does ssl_protocols behave differently depending on if > > $ssl_cipher_list is defined? Shouldn't !SSLv2 and !SSLv3 be sufficient? > > > > It seems that if ssl_cipher_list is defined, > > ssl_protocols = !SSLv2 !SSLv3 > > > > results in TLS1.2 being the only one active, but if it is defined, 1.0, > > 1.1, and 1.2 are all active? > > Where are you see this behaviour? What tool is reporting this? I have mostly been testing with nmap, e.g., nmap -p 993 --script ssl-enum-ciphers [target] This then breaks down the ciphers by protocol suite. I'll test with your ssl_cipher_list example and see if it's reproducible. w
Re: disabling certain ciphers
On Mon, Dec 01, 2014 at 09:27:48PM -0800, Darren Pilgrim wrote: > On 12/1/2014 4:43 PM, Will Yardley wrote: > > Can you use both ssl_protocols *and* ssl_cipher_list in the same config > > (in a way that's sane)? > > > Is there a way to exclude these ciphers, while still keeping my config > > easy to parse and avoiding duplicative or deprecated configs? > > Yes to both. If you need to support older clients: > > ssl_cipher_list = HIGH:!RC4:!MD5:!SRP:!PSK:!aNULL:@STRENGTH > ssl_dh_parameters_length = 2048 > ssl_parameters_regenerate = 0 > ssl_protocols = !SSLv2 !SSLv3 TLSv1 TLSv1.1 TLSv1.2 But why does ssl_protocols behave differently depending on if $ssl_cipher_list is defined? Shouldn't !SSLv2 and !SSLv3 be sufficient? It seems that if ssl_cipher_list is defined, ssl_protocols = !SSLv2 !SSLv3 results in TLS1.2 being the only one active, but if it is defined, 1.0, 1.1, and 1.2 are all active? w
disabling certain ciphers
Can you use both ssl_protocols *and* ssl_cipher_list in the same config (in a way that's sane)? ssl_protocols (>= 2.1) and ssl_cipher_list co-exist, or are they mutually exclusive? I have a Dovecot 2.2.13 system, and I tried setting: I also tried things like ssl_cipher_list = HIGH or ssl_cipher_list = HIGH:!MEDIUM:!LOW however, doing this seems to make v3 still work unless I explicitly do !SSLv3 in ssl_cipher_list in addition to disabling it in $ssl_protocols. This is different from Apache, which has similar parameters, but where disabling the protocol takes precedence. If I just do: ssl_protocols = !SSLv2 !SSLv3 I still get some ciphers that show up as "weak", e.g., | SSLv3: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_DHE_RSA_WITH_DES_CBC_SHA - weak [] | TLS_RSA_WITH_DES_CBC_SHA - weak Is there a way to exclude these ciphers, while still keeping my config easy to parse and avoiding duplicative or deprecated configs? The behavior is also pretty strange; if I have something like one of the following, with or without $ssl_protocols set to exclude SSLv2 and SSLv3: ssl_cipher_list = HIGH:!MEDIUM:!LOW:!SSLv3 ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:+HIGH:!MEDIUM TLS v1.0 and v1.1 get disabled as well. I also can't seem to explicitly enable TLS 1.0 or 1.1 in $ssl_cipher_list. w
Re: Dbox and Exim
On Thu, Oct 09, 2014 at 06:03:57PM +0200, Philon wrote: > > I’m really curious as to if I really understand you correctly. Neither Exim > nor Postfix do need to support any mailbox format. They both should hand > incoming mail to either LDA or LMTP. Postfix has an LDA (local(8)). I believe Exim also has a builtin LDA. local(8) - Postfix local mail delivery Postfix's LDA can write to both Maildir and mbox mailboxes. Of course, both MTAs let you specify an external LDA, but both do have builtin ones. w
Re: Does dovecot work OK on *BSD?
On Thu, Sep 25, 2014 at 12:01:01PM -0500, Larry Rosenman wrote: > I run dovecot on FreeBSD and its in ports.. no issues at all and the > maintainer keeps it current. I don't use it very much (mostly read mail locally, and it's a single-user system), but I have no problems with Dovecot (2.2.x, built from ports) on my FreeBSD box. w
Re: doveadm with multiple instances on same machine(s)
On Fri, Sep 19, 2014 at 09:55:51AM +0300, Teemu Huovila wrote: > On 09/19/2014 03:04 AM, Will Yardley wrote: > > director_doveadm_port = 8889 [] > > doveadm_proxy_port = > In the 2.2 series you can write this as "doveadm_port", I think. Thanks for the heads up. FWIW, the system I have seems to make the translation, since I have doveadm_proxy_port configured but doveconf returns: # doveconf -i director doveadm_port doveadm_port = # doveconf -i director doveadm_proxy_port #
Re: negative auth cache?
On Thu, Sep 18, 2014 at 11:41:14PM -0700, Will Yardley wrote:
> (is it connecting to the wrong instance's auth socket? the path to the
> 'main' instance's auth socket is /var/run/dovecot-main/auth-master)
>
> and then I see
> # doveadm -i main auth cache flush
> 0 cache entries flushed
Seems that the problem was that I had a symlink (for convenience) of
/var/run/dovecot to /var/run/dovecot-director (so that I don't have to
specify the instance name for common operations, which mostly involve
the director).
If I remove that symlink, and run the command with '-i main'
# doveadm -i main auth cache flush
904 cache entries flushed
The relevant code is something like:
if (auth_socket_path == NULL) {
auth_socket_path = t_strconcat(doveadm_settings->base_dir,
"/auth-master", NULL);
I'm guessing that auth_socket_path isn't null for some reason, and thus
the auth_socket_path isn't constructed correctly in this case, even
though the instance is being specified?
# doveadm instance list
path name last used running
/var/run/dovecot-director director 2014-09-18 20:01:12 yes
/var/run/dovecot-main main 2014-09-18 20:01:12 yes
# doveconf -i main base_dir
base_dir = /var/run/dovecot-main
w
Re: negative auth cache?
On Fri, Sep 19, 2014 at 08:21:51AM +0200, Steffen Kaiser wrote:
> On Thu, 18 Sep 2014, Will Yardley wrote:
>
> > Also, how can I flush the cache for a non-default instance's cache using
> > doveadm -- "doveadm auth cache flush" doesn't seem to have an '-a'
> > option AFAICT.
>
> mhm: -a does not have no relationship to (Dovecot) "instance".
>
> doveadm auth cache flush
>
> flushes all the auth cache, no selection of an user possible, no need for
> - -a.
>
> doveadm -i instance_name auth cache flush
>
> should flush all the auth cache of the specified instance. Note the "-i"
> preceeds the command.
That doesn't give an error, but strace shows this:
[...]
connect(8, {sa_family=AF_FILE, path="/var/run/dovecot-director/auth-master"},
110) = 0
(is it connecting to the wrong instance's auth socket? the path to the
'main' instance's auth socket is /var/run/dovecot-main/auth-master)
and then I see
# doveadm -i main auth cache flush
0 cache entries flushed
(strace shows this, which is the same thing I see from the director
instance).
write(1, "0 cache entries flushed\n", 240 cache entries flushed
) = 24
The 'main' instance should definitely have plenty of auth cache entries
these are fairly busy systems, and the cache TTL is 5 minutes.
Also, while I'd seen the use of the '-i flag, I didn't realize it was
supported in this version, as '-i' doesn't seem to be listed in
doveadm(1) or in the usage for doveadm.
w
Re: negative auth cache?
On Fri, Sep 19, 2014 at 02:34:34AM +0200, Reindl Harald wrote: > Am 19.09.2014 um 02:09 schrieb Will Yardley: > > > > Also, how can I flush the cache for a non-default instance's cache using > > doveadm -- "doveadm auth cache flush" doesn't seem to have an '-a' > > option AFAICT. > > > > # doveadm auth > > usage: doveadm [-Dv] [-f ] auth [] > > cacheflush > > just hard restart dovecot > > the auth cache is not persistent Yes, that's how I've solved the problem so far. But since the problem doesn't affect all users, I'd obviously prefer not to do a hard restart of Dovecot just to fix it if there's a command that will clear the auth cache only. w
negative auth cache?
I am using Dovecot 2.2.13, which doesn't yet seem to have the $auth_cache_negative parameter. Should the negative cache value honor $auth_cache_ttl then? I had a problem where some of our ldap systems were reinitialized. Some users, presumably those who tried to login while their records were returning a failure, became unable to login after the records were once again returning normally. I currently have: auth_cache_size = 5 M auth_cache_ttl = 5 mins # Not yet implemented #auth_cache_negative = 2 mins yet the problem seemed to persist for more than an hour. Also, how can I flush the cache for a non-default instance's cache using doveadm -- "doveadm auth cache flush" doesn't seem to have an '-a' option AFAICT. # doveadm auth usage: doveadm [-Dv] [-f ] auth [] cacheflush w
doveadm with multiple instances on same machine(s)
Couple questions about running doveadm with multiple instances... I have
Dovecot 2.2.13 on RHEL6 running across 3 boxes, each with a director and
main instance running. When I try to lookup something on the main
instance (which is handling user auth) via its auth-userdb socket
directly, I get an error:
# doveadm auth lookup -a /var/run/dovecot-main/auth-userdb myuser
doveadm(root): Error: passdb lookup failed for myuser: Configured passdbs don't
support crentials lookups
When I use the default lookup map, I just get the proxy settings that
are configured in the director instance's authdb.
# doveadm auth lookup myuser
passdb: myuser
user : myuser
proxy : y
nopassword: y
In addition,
"doveadm director map"
can't map the username -I get the error:
doveadm(root): Error: User listing returned failure
doveadm(root): Error: user listing failed
[then I get the whole list, but with for each user]
The director itself doesn't have the LDAP passdb that the main dovecot
instance talks to, but I have, in the director config:
service doveadm {
inet_listener {
port = 8889
}
}
director_doveadm_port = 8889
local 192.168.x.x/24 {
doveadm_password = XX
}
doveadm_proxy_port =
And in the main config:
service doveadm {
inet_listener {
port =
}
}
local 192.168.x.x/24 {
doveadm_password = XXX ## same password as above
}
Re: Creating a backup of incoming mail
On Mon, Sep 01, 2014 at 09:33:52AM +0200, Patrick De Zordo wrote: > To backup all mail (incoming and outgoing), BCC all mails, you could > do the following.. > Add to your "/etc/postfix/main.cf" the following: > ---8<- > # Auto-Backup all mails > transport_maps = hash:/etc/postfix/transport > backuplmtp_destination_recipient_limit = 1 > lmtp_destination_recipient_limit = 1 > recipient_bcc_maps = pcre:/etc/postfix/backup_bcc.pcre > sender_bcc_maps = pcre:/etc/postfix/backup_bcc.pcre Why not just use $always_bcc? w
Re: Panic/backtrace in dovecot 2.2.13
I'm seeing some similar problems, sometimes, but not always, resulting in a backtrace -- recently migrated (where we had POP3 access via an old version of Courier, and IMAP via an older version of Dovecot; rebuilt the indices for POP3 users using the script). A few cases, where it looks like Dovecot doesn't like the size in the dovecot-uidlist written by the conversion script. Even though I could imagine that process not working properly We also had a problem with the auth process on the atrpms 2.2.10 RPM dying / respawning if a user didn't exist in LDAP (quickly built 2.2.13). Clearing the cache only doesn't seem to fix the problem; I can fix by removing dovecot-uidlist entirely and letting it rebuild, but all of the users with problems use both IMAP and POP3, so having the UIDLs reset is not ideal. Sep 6 16:29:30 hostname dovecot: imap(): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0() [0x3dd1a69b9a] -> /usr/lib64/dovecot/libdovecot.so.0() [0x3dd1a69c06] -> /usr/lib64/dovecot/libdovecot.so.0() [0x3dd1a22a8a] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH]() [0x418d69] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH](cmd_fetch+0x4a3) [0x40d863] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH](command_exec+0x3d) [0x41709d] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH]() [0x416150] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH]() [0x41624a] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH](client_handle_input+0x11d) [0x4164bd] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH](client_input+0x6f) [0x41682f] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x4e) [0x3dd1a7a2ee] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xa7) [0x3dd1a7b497] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x9) [0x3dd1a7a379] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x3dd1a7a3f8] -> /usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13) [0x3dd1a275d3] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH](main+0x2a8) [0x420088] -> /lib64/libc.so.6(__libc_start_main+0xfd) [0x33b8a1ed5d] -> dovecot-main/imap [ XX.XX.XX.XX UID FETCH UID FETCH UID FETCH UID FETCH]() [0x40ac69] Sep 6 16:31:28 hostname dovecot: imap(): Error: read(/var/spool/maildir/l//cur/1409757870.31894_0.hostname.example.com:2,S): FETCH BODY[] for mailbox INBOX UID 778 got too little data: 763 vs 764 Sep 6 16:31:28 hostname dovecot: imap(): Error: Corrupted index cache file /mnt/post/cache/l//.INBOX/dovecot.index.cache: Broken virtual size for mail UID 778 Sep 6 16:44:57 hostname dovecot: imap(): Error: read(/var/spool/maildir/l//cur/1407825903.29027_0.hostname.example.com:2,aeS): FETCH BODY[] for mailbox INBOX UID 770 got too little data: 1253 vs 1274 Sep 6 16:44:57 hostname dovecot: imap(): Error: Corrupted index cache file /mnt/post/cache/l//.INBOX/dovecot.index.cache: Broken virtual size for mail UID 770
Re: Defer email via LMTP when there is 'no space left on device' instead of rejecting it
On Sun, Aug 10, 2014 at 06:24:47PM +0200, Luuk wrote: > On 10-8-2014 06:18, Will Yardley wrote: > > Depends on the environment; in many cases, the admin could, or may even > > be expected to, raise the quota. > > !but should not! > > Quota should be set according to some rules, and never be raised because > of a 'quota reached'. A few things on this: 1) "Should" is a matter of opinion, and different environments have different business requirements. I've worked as a sysadmin for almost 15 years, in a variety of different settings (small startup, larger startup, later acquired by a corporation, academic), and I've found that there's always *some* squeaky wheel who is going to make a lot of noise and get their quota raised. In several roles, in fact, that person is often another technical person, who also happened to be my boss. In fact, I've been in plenty of situations where quotas can't be set at all, or are set so high that they're basically useless. I thought (at times) that changing to a different setting, for example, education, might change this, but I have not found this to be the case. In a pure ISP / hosting provider type situation, it is often necessary to have a strict policy about quotas; however, on the corporate side of that same organization, there are often different business requirements. So, if you enjoy the cozy situation of being able to tell your users what quota they can have, in all circumstances, more power to you, but I don't think this is typical in the "real world". And, in a sense, it needen't always be. If more disk space is what whoever the most important users in your organization "need" to get their work done in a way that's comfortable for them, it may well be the case that this is exactly what you'll need to provide for them -- especially if the organization is willing to fund the hardware necessary to support larger quotas for some, or all, users. 2) Again, even if the quota policy is strict, it's not always the case that users understand the error message they get, even if their MUA presents it in a friendly way. 3) In many cases, users aren't able to delete mail to get under their (hard) quota without having the quota raised temporarily. If their mail client deletes by copying messages into the trash, then purging, for example, I've seen cases where the only way for the user to trim down their usage is to temporarily increase the quota long enough for them to get their usage down. 4) Some environments (and some users) require a more "high touch" approach than others. > What is the use of 'quota' if the admin raises your quota when things > are full? One use is to prevent a mail loop or other problem affecting one or two users from filling up a storage volume. Another is so that usage requirements (and exceptions to default quotas) can be tracked. Regardless of how individual organizations handles quotas, I don't see how having Dovecot log an over quota event would be a bad thing. w
Re: Defer email via LMTP when there is 'no space left on device' instead of rejecting it
On Sun, Aug 10, 2014 at 01:31:47AM +0300, Timo Sirainen wrote: > Problems that admins can solve are temporary errors for users and > the'll need an error logged. Problems that are caused by users > themselves (like over quota) are usually not temporary errors and they > shouldn't have errors logged (since admin can't usually do anything > about them anyway). Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota. Also, you're assuming that users will be able to interpret an error message, even a clear one, correctly, and that the MUA will always convey the error to the user. I am not sure either of these assumptions are always true. Logging is important so when the user calls in with "I can't do X", the admin can see why quickly. w
Re: prefix behavior with Dovecot / Squirrelmail
On Mon, Aug 04, 2014 at 11:31:42PM -0700, Will Yardley wrote:
> namespace private {
> separator = .
> prefix = Mail.
> inbox = yes
> }
ps - Will simply making the Mail. namespace "hidden" fix the problem,
while keeping things backwards compatible for clients who have the
prefix set to Mail already?
w
prefix behavior with Dovecot / Squirrelmail
Old: Dovecot 1.1.18 + Squirrelmail 1.4.8 + Imapproxy
New: Dovecot 2.2.10 + Squirrelmail 1.4.22 (no Imapproxy)
In both, we have:
[dovecot config]
namespace private {
separator = .
prefix = Mail.
inbox = yes
}
(The 'Mail' prefix is set this way for compatibility reasons)
$imap_server_type = 'dovecot';
$default_folder_prefix = 'Mail.';
$trash_folder = 'Mail.Trash';
$sent_folder= 'Mail.Sent';
$draft_folder = 'Mail.Drafts';
$show_contain_subfolders_option = true;
$default_sub_of_inbox = false;
(I know some of these are redundant with $imap_server_type, but that's
how it's setup now). This works as we expect with the old setup -
folders are set in, e.g., $maildir/.Sent, and we only see one set of
each.
With the newer one, it auto-creates folders as Mail.{Trash,Sent,Drafts},
which translates into Mail.Mail.{Trash,Sent,Drafts}. If I set
$foo_folder to just 'Foo' (e.g., $trash_folder = 'Trash';), the
auto-creation works as expected, however, now I have two sets of folders
(one indented) in the folder list, and the set linking to
Mail.{Trash,Sent,Drafts} (the indented ones), don't work.
What's the easiest way to get the new setup working in a way that will
cause the least change (preferably no change) to end-users.
TIA
w
ulimit warning when restarting
When restarting Dovecot 2.2.10 (via atrpms) on RHEL 6, I get the error: Warning: fd limit (ulimit -n) is lower than required under max. load (1024 < 4096), because of default_client_limit # doveconf default_internal_user default_internal_user = dovecot Should dovecot print this warning based on $default_internal_user, or based on root? As root: # ulimit -n 1024 As user dovecot: $ ulimit -n 49152 $ whoami dovecot # grep dovecot /etc/security/limits.conf dovecot hard locks 49152 dovecot hard nofile49152 dovecot hard maxlogins 8192 dovecot soft locks 49152 dovecot soft nofile49152 dovecot soft maxlogins 8192
Re: ATrpms repo
On Tue, Jul 15, 2014 at 06:04:22PM +, Pascal Volk wrote: > On 07/15/2014 03:42 AM Will Yardley wrote: > > Not only is > > http://atrpms.net/name/dovecot/ > > empty, but: > > http://packages.atrpms.net/dist/el6/ > > seems to return a 404. Some of the mirrors still have the packages, but > > does anyone know if they're going to continue to build 2.2.x packages? > > There are some mirrors: http://atrpms.net/documentation/mirrors/ Yes, I can get to some of the mirrors, and they still have the latest version that atrpms packaged, but it's a little disconcerting that the main site has been broken for this long without an announcement. I thought it could be related to a security breach, but haven't heard anything so far. There are some pending bugs in their Bugzilla database, all assigned to the main guy (Axel), but don't see any status changes on them. w
Re: ATrpms repo
On Tue, Jul 15, 2014 at 10:43:32AM +0200, Reindl Harald wrote: > > > > Not only is > > http://atrpms.net/name/dovecot/ > > empty, but: > > http://packages.atrpms.net/dist/el6/ > > seems to return a 404. Some of the mirrors still have the packages, but > > does anyone know if they're going to continue to build 2.2.x packages? > > avoid ATrpms > > enable this repo unconditionally sooner or later will *** your > OS installation because he overrides base packages often in > incompatible ways and mixed with sane repos like rpmfusion > years ago already leaded in randomly crashing applications We don't have the repo enabled - we're just pulling in the package into our internal repo (after testing). That said, I'm happy to get recommendations for any RHEL6 repos that have Dovecot 2.2.x (or SRPMs that will build cleanly on EL6). While I'm comfortable with my ability to build my own packages, I'd rather not have to. Unfortunately, 2.1 didn't work properly with our setup (proxy / backend on the same machines), so despite some recent bugs, I need 2.2 train. w
director / main instance
I have directors and backend servers running on the same systems (x3).
To be able to run doveadm foo with a minimum of fuss (without having to
list socket paths explicitly), should it be the director that's the
"default"? If so, is it safe to symlink '/var/run/dovecot' to
'/var/run/dovecot-director', or should I just make the director's base
path /var/run/dovecot directly?
in dovecot-director.conf, I have:
service doveadm {
inet_listener {
port = 8889
}
}
local 192.168.x.0/24 {
doveadm_password = Foo
}
doveadm_proxy_port =
and in dovecot-main.conf, I have:
service doveadm {
inet_listener {
port =
}
}
local 192.168.x.0/24 {
doveadm_password = Foo
}
protocol doveadm {
auth_socket_path = director-userdb
}
Is this correct (and is there anything unneeded / redundant there)?
# dovecot instance list
path name last used running
/var/run/dovecot-director director 2014-07-14 20:36:49 yes
/var/run/dovecot-main main 2014-07-14 20:36:49 yes
# dovecot director status
mail server ip vhosts users
192.168.x.xx 100 2
192.168.x.xx 100 0
192.168.x.xx 100 0
ATrpms repo
Tried mailing the maintainer, but didn't get a response -- anyone know what's happened to the ATrpms repo? Not only is http://atrpms.net/name/dovecot/ empty, but: http://packages.atrpms.net/dist/el6/ seems to return a 404. Some of the mirrors still have the packages, but does anyone know if they're going to continue to build 2.2.x packages? w
Re: [Dovecot] director with multiple instances
So, going to latest 2.2 RPM from ATRPMs does seem to fix the problem
(that is, the same config works as expected).
So, my question then is, in terms of indices, dovecot-uidlist, etc., is
it safe to move from Dovecot 1.0.7 directly to 2.2.10?
Also, even if I put:
doveadm_socket_path = localhost:8889
in, or even if I add this to the main (non-director) instance's config
(to presumably disable the director-admin socket):
service director {
unix_listener director-admin {
group =
mode = 00
user =
}
}
I get:
[root@retr01 ~]# doveadm director status
doveadm(root): Fatal: net_connect_unix(/var/run/dovecot-main/director-admin)
failed: Connection refused
Specifying the socket explicitly does give the expected results:
[root@retr01 ~]# doveadm director status -a
/var/run/dovecot-director/director-admin
mail server ip vhosts users
192.168.1.71 100 1
[]
Default dovecot.conf (/etc/dovecot/dovecot.conf) is a symlink to the
*director* instance's config, and I tried even with doveadm_socket_path
set to localhost:8889 in both configs so I'm not sure why it's looking
for the main instance's socket. The comments in the config file seem to
indicate that host:port is acceptable rather than a local socket.
w
Re: [Dovecot] director with multiple instances
I'm guessing this is the most significant issue:
Jun 3 16:22:33 retr01 dovecot: director: Fatal: No inet_listeners defined for
director service (for standalone keep director_servers empty)
What confuses me, is that not only do I have this in my config:
service director {
fifo_listener login/proxy-notify {
mode = 0666
}
inet_listener {
port = 2888
}
[...]
but I can telnet to port 2888, and I can see that it's bound to the
correct instance of Dovecot (though the first time I telnet to that
port, I get the connection closed right away (this lines up with the
error about inet_listeners); the second time, it doesn't close):
[root@retr01 ~]# telnet localhost 2888
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[root@retr01 ~]# telnet localhost 2888
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
The default config (without any 'service director {}' section) for the
other (backend) instance gives me (in doveconf -c
/etc/dovecot-main.conf):
service director {
[...]
service_count = 0
type =
unix_listener director-admin {
group =
mode = 0600
user =
}
unix_listener login/director {
group =
mode = 00
user =
}
[...]
Do I need to set mode to 00 for director-admin (again, on the *non*
director instance) as well (I think I've seen something about this on
the list).
Does anyone have any suggestions, especially anyone who has a similar
setup working on 2.0.x?
w
Re: [Dovecot] director with multiple instances
And I realize that doveadm isn't setup properly yet, and that director_doveadm_port needs to be doveadm's inet_listener, not director's as it is now. Presumably this should just affect being able to run doveadm, though, and not cause the problems I mentioned? It would be really convenient if running the directors and backend services on the same set of machines was a lot easier out of the box. Especially being able to configure a static mapping of listener => backend port without having to do a fake SQL map would really simplify things. w
[Dovecot] director with multiple instances
I'm experiencing some problems similar to those described in
http://dovecot.org/list/dovecot/2012-July/137250.html
except with 2.0.9.
Adding http://dovecot.org/list/dovecot/2012-July/084906.html
to the main config didn't seem to help, nor did setting the list of
director and backend servers to just the system itself.
I get a banner connecting to port 143:
[root@retr01 log]# telnet localhost 143
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK Waiting for authentication process to respond..
Log messages are:
Jun 3 16:22:03 retr01 dovecot: pop3-login: Error: Timeout waiting for
handshake from auth server. my pid=32152, input bytes=0
Jun 3 16:22:33 retr01 dovecot: pop3-login: Error: Timeout waiting for
handshake from auth server. my pid=32152, input bytes=0
Jun 3 16:22:33 retr01 dovecot: director: Fatal: No inet_listeners defined for
director service (for standalone keep director_servers empty)
Jun 3 16:22:33 retr01 dovecot: master: Error: service(director): command
startup failed, throttling
Jun 3 16:23:08 retr01 dovecot: pop3-login: Error: Timeout waiting for
handshake from auth server. my pid=32152, input bytes=0
Jun 3 16:23:33 retr01 dovecot: pop3-login: Disconnected: Inactivity (no auth
attempts): rip=127.0.0.1, lip=127.0.0.1, secured
running dovecot procs are:
root 32137 1 0 16:20 ?00:00:00 /usr/sbin/dovecot -c
/etc/dovecot-main.conf
root 32145 1 0 16:20 ?00:00:00 /usr/sbin/dovecot -c
/etc/dovecot-director.conf
doveconf -n for the two configs (dovecot-main.conf,
dovecot-director.conf) are included below.
dovecot-sql.conf has:
driver = sqlite
connect = /etc/dovecot/empty.db
password_query = select 'y' as proxy, \
NULL as password, \
'y' as nopassword, \
case '%a' \
when '110' then '10110' \
when '995' then '10110' \
when '143' then '10143' \
when '993' then '10143' end \
as port;
(where empty.db is completely empty; this is just used since there's no
other way to handle the port mapping, as described elsewhere on the
list).
A static proxy setup does work, with the normal imap / pop3 listeners.
# 2.0.9: /etc/dovecot-main.conf
# OS: Linux 2.6.32-431.11.2.el6.x86_64 x86_64 Red Hat Enterprise Linux Server
release 6.5 (Santiago) ext4
auth_username_format = %Ln
auth_worker_max_count = 60
base_dir = /var/run/dovecot-main
default_client_limit = 4096
default_process_limit = 200
dotlock_use_excl = yes
mail_fsync = always
mail_location =
maildir:/var/spool/maildir/%1Ln/%Ln:INDEX=/mnt/post/cache/%1Ln/%Ln
mail_plugins = fts fts_squat quota
maildir_very_dirty_syncs = yes
mbox_write_locks = fcntl
mmap_disable = yes
namespace {
inbox = yes
location =
prefix = Mail.
separator = .
type = private
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
plugin {
quota = maildir:User Quota
quota_rule = *:storage=40960M:messages=300
}
service auth-worker {
user = $default_internal_user
}
service imap-login {
inet_listener imap {
port = 10143
}
inet_listener imaps {
port = 10993
}
service_count = 0
vsz_limit = 128 M
}
service pop3-login {
inet_listener pop3 {
port = 10110
}
inet_listener pop3s {
port = 10995
}
}
ssl = required
ssl_cert =
Re: [Dovecot] list all emails from command line?
This seems like a pretty complicated (and time / labor intensive) way to
solve the problem. That said, if this is the way you want to approach
the problem, Python's imaplib is pretty good at doing this kind of
thing.
This may not format it exactly the way you want, but it should give you
a starting point. Lots of examples online.
I haven't played with it much, but I think there are some things that
will let you do some extended logging of IMAP commands from within
Dovecot - that might be a better way to figure out why the user's client
doesn't seem to be noticing the message in a timely manner.
#!/usr/bin/env python
import email
import imaplib
IMAPHOST='somehost.example.com'
USER='username'
PASSWORD='mysecretgarden'
i = imaplib.IMAP4_SSL(IMAPHOST)
i.login(USER, PASSWORD)
for folder in i.list()[1]:
folder = folder.split(' "/" ')[1]
print " %s " % folder
i.select(folder)
typ, [msg_ids] = i.search(None, 'ALL')
for num in msg_ids.split():
typ, msg_data = i.fetch(num, '(BODY.PEEK[HEADER])')
for response_part in msg_data:
if isinstance(response_part, tuple):
email_message = email.message_from_string(response_part[1])
to = email.utils.parseaddr(email_message['to'])
subject = email_message['Subject']
msgid = email_message['Message-ID']
sender = email.utils.parseaddr(email_message['From'])
print "%-30s => %-30s %-30s (%s)" % (sender[1], to[1] + ':',
subject[0:30], msgid)
Re: [Dovecot] Copies of outgoing emails in the Sent folder
On Fri, May 23, 2014 at 02:26:37PM +0200, Steffen Kaiser wrote: > > > And how can you do it for the entire server? > > Well, as I said, "in postfix". It's your MTA all your users are going > through. How to do it with postfix, I don't know, because I do not run > no postfix. OT for this list, but didn't see the answer to this yet; the parameter in Postfix is called '$always_bcc'. w
[Dovecot] director with same director / backend servers
I know this has been covered somewhat, but I'm still not totally clear. I'm trying to setup a 3 node cluster with 3 directors and 3 backend systems. This post (from 2012) suggests that proxy_maybe should work with director: http://www.dovecot.org/list/dovecot/2012-December/069806.html However, these two posts (from 2013) seem to say that it will not: http://dovecot.org/pipermail/dovecot/2013-November/093776.html http://dovecot.org/pipermail/dovecot/2013-November/093809.html When I try to just set =proxy_maybe=y in my LDAP config's pass_attrs, and not have an explicit 'director' listener for pop3-login / imap-login, it complains about lack of a host. May 22 14:28:08 dovecot: pop3-login: Error: proxy: host not given: user=, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured Guessing the answer is "no", but is there any way (with v 2.x) to have one regular "listener" for imap / pop3, and one "director" listener for each as well, using the same instance of Dovecot? Has anyone gotten this to work successfully? I'm using LDAP, and do not want to explicitly specify a host for each username, I just want director to balance users across the 3 hosts. Obviously, I can just create two instances, but not only does this make the config more convoluted (especially following the convention of having the config files broken out into a bunch of files), but means I have to modify the default init script to really do it cleanly (something we were doing on the older iteration of this system that I had really been hoping to avoid). I'm assuming it's not possible to simply have the listeners for 'foo-login' execute something different depending on the port? I tried a couple different ways of configuring this, but it didn't seem to work. Dovecot is version 2.0.9 from RHEL 6. w
Re: [Dovecot] UIDL conversion courier -> dovecot
Sorry for the self-followup... Looks like I just needed to look at the Courier v0 instructions and set pop3_uidl_format = %f That seems to work as expected, and the bonus is, I'll have the UIDLs the clients expect without any conversion. /wby
[Dovecot] UIDL conversion courier -> dovecot
I've got a weird split setup where POP3 is currently handled by Courier (courier-imap-3.0.2 distribution), and IMAP is currently handled by the RHEL 5 version of Dovecot (1.0.7) I'm trying to figure out a way to convert the POP3 UIDLs (in cases where the courierpop3dsizelist is newer than dovecot-uidlist, at least) to something that Dovecot will read, or to configure Dovecot's pop3 to use a UIDL format that will work, as mentioned in the migration wiki. We have some "squeaky wheel" users who don't have their POP clients set to delete messages, and are likely to complain about re-downloading their several GB of mail. Thus far, the migration scripts haven't seemed to work properly, maybe because of the versions I'm using. I'm not sure whether the Courier versions there refer to Courier MTA version or Courier IMAP version, but adjusting the UIDL format to %v-%u (as suggested for early Courier 3 / Dovecot 1.0) hasn't worked (I saw %u-%v online, but that also didn't work). Since the Courier system doesn't seem to report validity, I also tried just '%u' - this works *if* I delete the header line as well as rename the courierpop3dsizelist to dovecot-uidlist, but I still don't get the exact same UIDLs as before. I'm willing to write my own migration tool, or to adapt the existing one, but I could use some assistance knowing how to do the translation. Dovecot -n for that instance is below, slightly sanitized, obviously I can change pop3_uidl_format; I also tried getting rid of pop3_reuse_xuidl: Basically, to give a concreate example, the Courier system seems to use the filename as the UIDL, with this courierpop3dsizelist: /2 45 1382654636 1199751891.13891_0.water-ox:2,Sa 2412 0:1382654636 1199927364.22870_0.fire-ox:2,S 2440 0:1382654636 1199936486.3332_0.wood-ox:2,Sa 2074 0:1382654636 1199985712.27745_0.water-ox:2,RS 4007 0:1382654636 113867.23139_0.fire-ox:2,S 1550 0:1382654636 producing this UIDL output: UIDL +OK 1 1199751891.13891_0.water-ox 2 1199927364.22870_0.fire-ox 3 1199936486.3332_0.wood-ox 4 1199985712.27745_0.water-ox 5 113867.23139_0.fire-ox [...] Dovecot's dovecot-uidlist: 3 V1199747645 N606 562 W2412 :1199751891.13891_0.water-ox:2,Sa 563 W2440 :1199927364.22870_0.fire-ox:2,S 564 W2074 :1199936486.3332_0.wood-ox:2,Sa 565 W4007 :1199985712.27745_0.water-ox:2,RS 566 W1550 :113867.23139_0.fire-ox:2,S producing: UIDL +OK 1 1199747645-562 2 1199747645-563 3 1199747645-564 4 1199747645-565 5 1199747645-566 (or, if I change the format to just %u): +OK 1 650 2 651 3 652 4 653 5 654 # dovecot --version 1.0.7 # 1.0.7: /etc/dovecot.d/XXX.cfg base_dir: /var/run/dovecot/pop-its syslog_facility: local4 protocols: pop3 pop3s listen: *:110 ssl_listen: *:995 ssl_ca_file: /etc/pki/dovecot/certs/XX.pem ssl_cert_file: /etc/pki/dovecot/certs/.pem ssl_key_file: /etc/pki/dovecot/private/.key disable_plaintext_auth: yes login_dir: /var/run/dovecot/pop-its/login login_executable: /usr/libexec/dovecot/pop3-login login_greeting_capability: yes login_processes_count: 4 login_max_processes_count: 512 verbose_proctitle: yes mail_location: maildir:/var/spool/maildir/%1Ln/%Ln:INDEX=/var/spool/dovecot/indexes/%1Ln/%Ln mail_debug: yes mmap_disable: yes maildir_copy_with_hardlinks: yes mail_executable: /usr/libexec/dovecot/pop3 mail_plugin_dir: /usr/lib/dovecot/pop3 pop3_reuse_xuidl: yes pop3_uidl_format: %v-%u pop3_client_workarounds: outlook-no-nuls oe-ns-eoh namespace: type: private separator: . prefix: Mail. inbox: yes auth default: mechanisms: plain login passdb: driver: ldap args: /etc/dovecot.conf-ldap userdb: driver: static args: uid=vmail gid=mail home=/var/spool/maildir/%1Ln/%Ln socket: type: listen master: path: /var/run/dovecot/pop-its/auth-master mode: 384 user: vmail group: mail TIA! /wby
