[Dovecot] dovecot-ldap : can't find user in OU subtree
Hi all,
Well, I've compiled and installed dovecot 2.2.6 with following options:
./configure --prefix=/usr/ --sysconfdir=/etc/ --with-mysql
--libexecdir=/usr/lib/ --localstatedir=/var
--with-moduledir=/usr/lib/dovecot/modules --disable-rpath
--disable-static --with-zlib --with-bzlib --with-solr --with-ldap
--with-gssapi --with-nss
doveconf -n:
# 2.2.6: /etc/dovecot/dovecot.conf
# OS: Linux 3.8.0-32-generic x86_64 Ubuntu 12.04.3 LTS ext4
auth_debug = yes
auth_mechanisms = plain login
auth_verbose = yes
first_valid_gid = 20001
first_valid_uid = 20001
log_timestamp = %Y-%m-%d %H:%M:%S
mail_debug = yes
mail_gid = 20001
mail_home = /media/data/email/%n
mail_location = maildir:/media/data/email/%n/mail
mail_plugins = fts fts_solr acl zlib mail_log notify
mail_uid = 20001
managesieve_notify_capability = mailto
managesieve_sieve_capability = comparator-i;octet
comparator-i;ascii-casemap fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex
imap4flags copy include variables body enotify environment mailbox
date spamtest spamtestplus virustest
namespace {
list = no
location =
maildir:/media/data/email/%%n/mail:INDEX=/media/data/email/%n/mail/shared/%%n
prefix = shared/%%n/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location = maildir:/media/data/email/%n/mail
mailbox Sent {
auto = subscribe
}
mailbox Spam {
auto = subscribe
}
mailbox SpamFalse {
auto = subscribe
}
mailbox SpamToLearn {
auto = subscribe
}
prefix =
separator = /
type = private
}
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
plugin {
acl = vfile
mail_log_events = delete undelete expunge copy mailbox_delete
mailbox_rename save mailbox_create
mail_log_fields = uid box msgid size
sieve = /media/data/email/%n/dovecot.sieve
sieve_after = /media/data/email/sieve/global.sieve
sieve_dir = /media/data/email/%n/sieve
zlib_save = bz2
zlib_save_level = 9
}
protocols = imap pop3 sieve lmtp
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-master {
group = vmail
mode = 0660
user = vmail
}
unix_listener auth-userdb {
group = vmail
mode = 0640
user = vmail
}
}
service imap-login {
inet_listener imap {
address = *
port = 143
}
inet_listener imaps {
address = *
port = 993
ssl = yes
}
process_limit = 256
}
service lmtp {
inet_listener lmtp {
address = *
port = 24
}
user = vmail
}
service managesieve-login {
inet_listener sieve {
address = *
port = 4190
}
process_limit = 256
vsz_limit = 64 M
}
service pop3-login {
inet_listener pop3 {
address = *
port = 110
}
inet_listener pop3s {
address = *
port = 995
ssl = yes
}
}
ssl = required
ssl_ca =
/etc/dovecot/dovecot-ldap-passdb.conf.ext:
hosts = localhost
auth_bind = yes
auth_bind_userdn = cn=%u,OU=users,dc=domain,dc=lan
ldap_version = 3
base = ou=users,dc=domain,dc=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
/etc/dovecot/dovecot-ldap-userdb.conf.ext:
hosts = localhost
dn = cn=ldap,cn=Users,DC=domain,DC=lan
dnpass = My_secret_pass
ldap_version = 3
base = OU=users,DC=domain,DC=lan
scope = subtree
user_attrs = uid=20001, gid=20001, home=/media/data/email/%n,
mail=/media/data/email/%n/mail
user_filter = (&(objectClass=person)(cn=%n)(mail=*))
iterate_attrs = cn=user
iterate_filter = (objectClass=person)
All seems to work as expected up-to-now, but :
If I move a user from OU 'users' to a sub-OU 'administrative' on Active
Directory :
-> The user can't login anymore to Dovecot
I have added the "scope = subtree" to the userdb and passdb files but it
doesn't change anything.
Here is the debug part when user test3 (located in ou=users,
ou=administrative) tries to login:
Oct 30 18:49:12 serveur dovecot: auth: Debug: auth client connected
(pid=4292)
Oct 30 18:49:12 serveur dovecot: auth: Debug: client in:
AUTH#0111#011PLAIN#011service=imap#011secured#011session=L6uskfDpKwAKChTQ#011lip=10.10.20.1#011rip=10.10.20.208#011lport=993#011rport=54827
Oct 30 18:49:12 serveur dovecot: auth: Debug: client passdb out:
CONT#0111#011
Oct 30 18:49:12 serveur dovecot: auth: Debug: client in: CONT
Oct 30 18:49:12 serveur dovecot: auth:
ldap(test3,10.10.20.208,): invalid credentials
Oct 30 18:49:14 serveur dovecot: auth: Debug: client passdb out:
FAIL#0111#011user=test3
As soon as I move user 'test3' back to ou=users, it can login ...
Oct 30 18:53:57 serveur dovecot: auth: Debug: Loading modules from
directory: /usr/lib/dovecot/modules/auth
Oct 30 18:53:57 serveur dovecot: auth: Debug: Read auth token secret
from /var/run/dovecot/auth-token-secret.dat
Oct 30 18:53:57 serveur dovecot: auth: Debug: auth client connected
(pid=4303)
Oct 30 18:53:57 serveur dovecot: auth: Debug: client in:
AU
Re: [Dovecot] dovecot-ldap : can't find user in OU subtree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 30 Oct 2013, m...@electronico.nc wrote:
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
/etc/dovecot/dovecot-ldap-passdb.conf.ext:
hosts = localhost
auth_bind = yes
auth_bind_userdn = cn=%u,OU=users,dc=domain,dc=lan
You define your bind DN as cn=%u,OU=users,dc=domain,dc=lan
ldap_version = 3
base = ou=users,dc=domain,dc=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
user_attrs = uid=20001, gid=20001, home=/media/data/email/%n,
mail=/media/data/email/%n/mail
user_filter = (&(objectClass=person)(cn=%n)(mail=*))
pass_filter and user_filter differ in %u vs. %n.
Here is the debug part when user test3 (located in ou=users,
ou=administrative) tries to login:
The auth_bind_userdn does not match the ou=administrative location. Drop
the auth_bind_userdn, IMHO, so Dovecot actually uses pass_filter to
search for the DN of the user.
Oct 30 18:49:12 serveur dovecot: auth:
ldap(test3,10.10.20.208,): invalid credentials
Oct 30 18:49:14 serveur dovecot: auth: Debug: client passdb out:
FAIL#0111#011user=test3
As soon as I move user 'test3' back to ou=users, it can login ...
Oct 30 18:53:57 serveur dovecot: auth: Debug: client passdb out:
OK#0111#011user=test3
- --
Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUnDECl3r2wJMiz2NAQLEJQgAp/fECmujABG7xDI4nSkyn7ZcDp5xOqLm
qa+t2O+DPmEqC9EI+MIBaM8XOzKBG7iAVHpVtJJ06WA/Sn0aupyWxq6mAFEIYTtM
2byKy4eSWexZU3XbhvggqMVaRJTBGHV31f2d05ZXjLzFeU4nzczN7xZ4DKVRqzhz
ii72NyMDf1bUhEx+1O7irMLnitOtpBlxsI5Xws6qrc1T4xlv0jjEkaqXEQAnPLWH
9F4x+t1mKks+UcMMl6wOUQ/Siozg4GBVjnyNd8F7bLVRznntkhxzOY0apCC8Df9+
kC2OhOF9ItHXKR2QI9w/emdqeKjbGQHEdrqC3Von2T/ntUA3yYHrCw==
=mGae
-END PGP SIGNATURE-
Re: [Dovecot] separate mail_location for system and normal users
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 30 Oct 2013, Andrzej A. Filip wrote:
On 10/28/2013 09:29 AM, Steffen Kaiser wrote:
On Fri, 25 Oct 2013, Andrzej A. Filip wrote:
How to configure dovecot to use different default mail_location for
system (uid<1_000) and normal users (uid>=1_000)?
I want to to use by default
* classic mailbox in standard location for system users
* maildir in $HOME subdirectory for normal users
That depends :-)
If you have just one userdb, configure the default mail_location for
most users and return a mail extra field for the other ones.
You use passwd? This probably will not work, see
http://wiki2.dovecot.org/UserDatabase/ExtraFields about the syntax
You could probably copy the set of users, that requires extra fields,
from your /etc/passwd to somewhere else, adding the extra field. Then
configure the copy as userdb { driver passwd-file } _before_ the userdb
{ passwd }. That way, the entries in the passwd-file override the ones
in /etc/passwd, because they are found first.
I have used userdb/passwd fix for a system with a few "real user
mailboxes". I wanted something better fit for larger systems.
Hmm? You need to return a different mail field for one set of users.
/etc/passwd cannot do this. So you need some other userdb for the set of
users, for whom you want to override the default mail_location, be it
passwd-file, SQL, LDAP, ... .
You wrote "normal users (uid>=1_000)", so they are system users in
/etc/passwd as well, I assumed. If those system already use another user
database, try using it and extend it with the Dovecot settings.
- --
Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUnDFZF3r2wJMiz2NAQLjjAf9EvyLhylwZbyVuFyl59PVEdgrLdXo/9Y/
KrQhoV9c3stxJPjyz2RG1C7AL4it66NTFbKBtilV/qOILcfBtmF4pA+quMsAmQzW
ezu/yhFJyTfyqjgomrPbaBieORCY77ya1gL4OLhhhkPy4spFW4sUZWlOebRL7+sj
eHfjSHzmVVj/zA7hQNh8fsv/kx7JMqfHATkfPcMFF3lebM0SYr+N4Sc17TUDoEqG
BhHnUlDYnx08TELuAtdMipBckaFeUd2GTIH3tlSvKq9IkygnvjKDUhuz/+Bfpp6k
/Left6uzuWErcp+PaQaIgvUqJt9I2rfKzHNbVJXk8qS7TQ42Tvmztg==
=9ZZj
-END PGP SIGNATURE-
Re: [Dovecot] Encryption solution for messages at rest
So I suppose you're not a fan of the email hosting systems on the planet that bundle many services onto 1 box. Thanks for the feedback. - Doug Mortensen Network Consultant Impala Networks P: 505.327.7300 -Original Message- From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On Behalf Of Alan Brown Sent: Tuesday, October 29, 2013 10:05 AM To: dovecot Subject: [Dovecot] Encryption solution for messages at rest > Date: Tue, 29 Oct 2013 08:54:04 +0100 > From: Robert Schetterer > To: dovecot@dovecot.org > Subject: Re: [Dovecot] Encryption solution for messages at rest > Message-ID: <526f699c.9080...@sys4.de> > Content-Type: text/plain; charset=ISO-8859-1 > > > you shouldnt host mail/imap services on the same servers with massive > http hosting, You shouldn't host anything else on a webserver FULLSTOP. Webservers are best treated as "disposable" and should be heavily sandboxed. Any resources they can use should be vetted and ideally set as "read only" Inbound external access should be firewalled down to the webserver ports and OUTBOUND traffic should be firewalled too (If it has no business initiating external connections then block all SYNs), in order to stop it becoming a DDoS zombie. It's foolish (at best) to have mail servers running on a webserver, because if it's compromised it can immediately be used as a spam engine without much further effort. At least if it has to hand mail off to another mailserver you have a chance to run outbound filtering on the emitted mail without worrying about that being compromised too.
Re: [Dovecot] Mbox corruption - Inbox beginning with 'FFrom' or 'FrFrom'
I'm afraid it doesn't seem to be working. I've compiled a patched 2.2.6 dovecot with the patch you sent and installed it in a production server (had to be 2.2.6 cause we've upgraded all the rest since I begun this thread months ago) and although we still have mbox corruptions (rarely as before) the server isn't crashing : Oct 30 11:15:19 pop04 dovecot: pop3-login: Login: user=, method=PLAIN, rip=85.72.232.35, lip=83.235.66.43, mpid=24419, secured, session=<+0ywxfHpIQBVSOgj> Oct 30 11:15:20 pop04 dovecot: pop3(arto...@otenet.gr): Disconnected: Logged out top=0/0, retr=0/0, del=0/1336, size=471029518 Oct 30 11:19:12 pop04 dovecot: lmtp(2863, arto...@otenet.gr): r7U3KnyhcFIvCwAAckDtvw: msgid=: size=17823 saved mail to INBOX Oct 30 11:33:12 pop04 dovecot: pop3-login: Login: user=, method=PLAIN, rip=85.72.224.94, lip=83.235.66.43, mpid=600, secured, session= Oct 30 11:33:12 pop04 dovecot: pop3(arto...@otenet.gr): Error: Syncing INBOX failed: Mailbox isn't a valid mbox file Oct 30 11:33:12 pop04 dovecot: pop3(arto...@otenet.gr): Error: Couldn't init INBOX: Mailbox isn't a valid mbox file Oct 30 11:33:12 pop04 dovecot: pop3(arto...@otenet.gr): Mailbox init failed top=0/0, retr=0/0, del=0/0, size=0 Oct 30 11:33:33 pop04 dovecot: lmtp(16314, arto...@otenet.gr): Au4vIMqucFK6PwAAckDtvw: msgid=<004401ced552$bb5ecd70$321c6850$@planet.nl>: size=7975817 save failed to INBOX: Mailbox isn't a valid mbox file Perhaps the patch is only valid for 2.1.16 and needs to be modified for 2.2.6 ? Thank you for your time Dimos Alevizos Original Message Subject: Re: [Dovecot] Mbox corruption - Inbox beginning with 'FFrom' or 'FrFrom' From: Timo Sirainen To: Dimos Alevizos CC: dovecot@dovecot.org, Dimitris Paouris Date: 26/06/2013 06:59 μμ It crashes one specific IMAP/POP3 session, so others are unaffected. The potential problems: * It might cause the user's mbox to become crashing constantly. so first crash -> client reconnects -> client attempts the same operation -> crash again. Then again, this might not happen, it depends. * The mbox file would probably become slightly more corrupted than normally, because it doesn't finish moving data around. No data should get actually lost, but some parts could become duplicated (e.g. some headers or even mails, possibly causing UID renumbering = redownloading). So not ideal in production, but shouldn't be too bad either, especially if you just wait for the first crash and then immediately switch to the old unpatched version. On 26.6.2013, at 10.21, Dimos Alevizos wrote: Hi, I haven't had the time to compile it yet, but a question just occurred. Given that it's so rare and we can't reproduce it on a dev server, how safe is this to use on a production server ? When you say "crash" you mean the whole dovecot server or that specific client's child ? D. Original Message Subject: Re: [Dovecot] Mbox corruption - Inbox beginning with 'FFrom' or 'FrFrom' From: dalevizo To: Timo Sirainen CC: dovecot@dovecot.org, Dimitris Paouris Date: 24/06/2013 01:41 μμ Thanx I'll try the patch as soon as possible and I'll let you know. It is indeed very rare. We're only seeing 4-5 corruptions in about 13 million logins per day. I've been trying to convince our design team that we should move to maildir, but the truth is that it's quite a change, and we're way too busy to deal with everything else AND a migration from mbox to maildir. D. On Mon 24/06/2013 13:16, Timo Sirainen wrote: On 19.6.2013, at 16.00, Dimos Alevizos wrote: we're having some problems with our dovecot setup. I've seen similar problems in the mailing list some years ago but alas wasn't able to find a solution. Our setup is as follows : An MX farm (postfix) sends mails via LMTP to a director farm (dovecot 2.1.12) which proxies pop3/imap/lmtp traffic to a dovecot farm (dovecot 2.1.16). All mailboxes and indexes are on NFS and all servers are Centos. The problem is that at times we see mailboxes (all of them are in mbox format) beginning with FFrom or FrFrom and of course dovecot says it's not a valid mbox file. This is quite an old bug, but it happens rarely enough that I haven't been able to reproduce and fix it. Actually people hadn't complained about it for a long time now, so I had assumed it had somehow gotten fixed already. With the attached debug patch it should crash instead of (completely) corrupting the mbox file. Debugging the resulting core file with gdb could be useful in figuring this out. Although I wouldn't recommend mbox format for any big installation anyway..
Re: [Dovecot] Encryption solution for messages at rest
I think your problem can be more generically restated as: - Untrusted users have access to the mailstore, eg employees who maintain the server, attackers who break into the system as untrusted user accounts - There is some trusted process to get access to decryption keys and largely this process is secure (obviously except attacks which succeed to escalate to root, or if employees typically get root access) - How to extend this secure key access process to dovecot So Exchange offers this feature where you can encrypt the mail and grant specific users access to decrypt subsets of the mail. This means that employees managing the mail server may not have access to decrypt the messages for their boss, etc (without at least using trickery to bypass and escalate their privileges - of course this is always possible, especially with physical access, but it reduces the attack surface) Off the top of my head it seems like any attempts to do this using block disk encryption layers substantially boil down to equivalent to standard file permissions. eg adding ecryptfs on the mail store means you need to prevent access to the mounted decrypted files, which given the mail store is a long running process, is largely equivalent to just using file permissions, MAC, grsec, etc to protect the dir? Timo's suggestion to incorporate in Dovecot opens up possible solutions. ie now files can be decrypted *as* they are required by the mail server. decryption key can probably be stored in userdb without loss of privacy (since if you can get the password for the account you can just pickup the emails via imap?). Bonus marks if you design some encrypted key store, but is seems challenging to add value here, possibly against more specific attacks, eg you don't want your database DBA to be able to get access to the decryption keys, hence a separate (simple) database just for decryption keys moves the problem sideways. Using Timo's filter this all seems very do-able, but performance will obviously be impacted. Modern processers are very fast at certain types of encryption opts though..? I'm interested to see what you produce. Seems interesting, but as many have already commented, it really only defends against a limited attack surface and not at all if the dovecot process or root/dovecot user is compromised. I think corporates would quite like this feature though Ed W On 28/10/2013 19:14, Douglas Mortensen wrote: Currently our dovecot servers are on our webhosting linux boxes. We are using the LAMP stack to host websites, and also doing email with postfix & dovecot on these systems. We provide this as a hosting setup for 100+ accounts/websites on a single server (a multi-tenant setup). Each customer has anywhere between 1-100 email accounts which Dovecot services. If a customer has vulnerable PHP code on a website, some of these will allow a remote file upload. I have seen cases where they upload a PHP script that is a sort of web-based console/shell to the server (file-system, etc.). It provides several tools which all run through the uploaded PHP script to try to brute force and do other attacks. I've seen attempts at a root exploit. We've never had a root exploit and any such case of a customer's site being hacked has been easily contained by simple filesystem permissions being correct (and the fact that we have apache setup to run all scripts as the user who is the owner of the script files, which confines the script to that users' permissions). Still nobody loves the idea of bad guys trying to hack on your box. So given that type of scenario, if filesystem permissions weren't correct, or some new exploit surfaced that allowed someone bypass or elevate to root, then they could theoretically have access to the entire fileystem including where emails are stored. I hope to never have this sort of thing happen. We patch our systems regularly and have other security measures we follow to prevent this. We also are managing most of the PHP scripts customers use ourselves now and are updating those for the CMS' and other systems proactively. However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it. - Doug Mortensen Network Consultant Impala Networks P: 505.327.7300 -Original Message- From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org] On Behalf Of Michael Orlitzky Sent: Monday, October 28, 2013 11:52 AM To: dovecot Subject: Re: [Dovecot] Encryption solution for messages at rest On 10/28/2013 12:02 PM, Douglas Mortensen wrote: Hi, We have clients with various security & compliance requirements. Although not required, it would be ideal to have messages encrypted at rest. You can rule out a lot of the crazier options by answering the questions, (a) What at
[Dovecot] Replication on v2.2.6 - I'm stuck (again)
Hi,
I'm trying to get Dovecot replication working between two servers. I
didn't have much luck on v2.1.3, so after receiving advice from the list I
have upgraded to v2.2.6.
I now get the error:
Oct 30 11:50:16 server1 dovecot: doveadm(mark): Error: user mark: Auth PASS
lookup failed
Oct 30 11:50:16 server2 dovecot: doveadm(mark): Error: sync:
/var/run/dovecot/auth-userdb: passdb lookup failed (to see if user is
proxied, because doveadm_port is set)
Here is my config:
# 2.2.6: /usr/pkg/etc/dovecot/dovecot.conf
# OS: NetBSD 5.2 cobalt
auth_mechanisms = plain login
doveadm_password = mylittlesecret
doveadm_port = 12345
dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u
listen = 192.168.1.1
login_greeting = Go on then, let's have it...
mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_plugins = " notify replication"
passdb {
driver = passwd
}
plugin {
mail_replica = remote:vm...@server2.mydomain.com
replication_full_sync_interval = 1 hours
}
protocols = imap
service aggregator {
fifo_listener replication-notify-fifo {
mode = 0600
user = vmail
}
unix_listener replication-notify {
mode = 0600
user = vmail
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
user = root
}
service doveadm {
inet_listener {
port = 12345
}
}
service imap-login {
inet_listener imap {
port = 0
}
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0600
}
}
ssl_cert =
Re: [Dovecot] Encryption solution for messages at rest
Michael Orlitzky skrev den 2013-10-28 20:49: php_admin_value open_basedir /var/www/$domain/$host/ php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp php_admin_value session.save_path /var/www/$domain/$host/tmp php_admin_value sys_temp_dir /var/www/$domain/$host/tmp so dont create tmp upload dirs in webroot, this is classic way of showing no care
Re: [Dovecot] IMAP Dovecot unknown namespace creating root folders
Hi all,
I believe I have worked this out, there is an entry in dovecot.conf for the
private namespace which sets the prefix required to access the namespace as
follows
prefix = INBOX.
I commented this out and restarted dovecot.
I know that I need to make this change in the template for dovecot as the
direct edit of dovecot.conf will be overwritten when dovecot is updated.
I am also checking if there are any implications in doing this, If anyone
knows any please drop me a reply.
Many thanks
Marcus
> -Original Message-
> From: dovecot-boun...@dovecot.org [mailto:dovecot-boun...@dovecot.org]
> On Behalf Of marcus lively
> Sent: 30 October 2013 03:08
> To: dovecot@dovecot.org
> Subject: [Dovecot] IMAP Dovecot unknown namespace creating root folders
>
> Hi, I hope someone can point me in the right direction here. I am
> migrating a mailbox from a non cPanel server, and the mailboxes have
> folders which seem to be at the same level as the Inbox. The users
> access these mailboxes using IMAP.
>
> The new server configuration is Exim > Dovecot 1.2.17 > Maildir with
> the standard cPanel install settings. dovecot -n output below
>
> I have created the new mailbox within cPanel however when I try to
> create a 'top level' folder in Outlook I receive the error 'Cannot
> create the folder: Unknown namespace' (Note I also tried this with the
> windows mail client to ensure it was not client side)
>
> I know that I can get round this by setting the root folder path on the
> client to 'Inbox' and therefore the folders would be created as sub-
> folders of Inbox, and this would not be visible to the user, but I was
> hoping to migrate without touching the clients.
>
> Should dovecot report the default root folder path automatically, or
> create a default top level namespace for each user so this can be done,
> or could I have just gone wrong and missed something.
>
> Any advice on getting this working appreciated, thanks for any help
>
> Maspry
>
> # 1.2.17: /etc/dovecot.conf
> # OS: Linux 2.6.32-71.el6.x86_64 x86_64 CentOS release 6.4 (Final)
> protocols: imap imaps pop3 pop3s
> ssl_cert_file: /etc/dovecot/ssl/dovecot.crt
> ssl_key_file: /etc/dovecot/ssl/dovecot.key
> ssl_cipher_list: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
> disable_plaintext_auth: no
> login_dir: /var/run/dovecot/login
> login_executable(default): /usr/libexec/dovecot/imap-login
> login_executable(imap): /usr/libexec/dovecot/imap-login
> login_executable(pop3): /usr/libexec/dovecot/pop3-login
> login_process_per_connection: no
> login_processes_count: 2
> login_max_processes_count: 50
> login_max_connections: 500
> mail_max_userip_connections(default): 20
> mail_max_userip_connections(imap): 20
> mail_max_userip_connections(pop3): 3
> maildir_copy_preserve_filename: yes
> mail_executable(default): /usr/libexec/dovecot/imap
> mail_executable(imap): /usr/libexec/dovecot/imap
> mail_executable(pop3): /usr/libexec/dovecot/pop3
> mail_plugins(default): acl quota imap_quota
> mail_plugins(imap): acl quota imap_quota
> mail_plugins(pop3): quota
> mail_plugin_dir(default): /usr/lib64/dovecot/imap
> mail_plugin_dir(imap): /usr/lib64/dovecot/imap
> mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3
> pop3_uidl_format(default): %08Xu%08Xv
> pop3_uidl_format(imap): %08Xu%08Xv
> pop3_uidl_format(pop3): UID%u-%v
> pop3_logout_format(default): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
> pop3_logout_format(imap): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s
> pop3_logout_format(pop3): top=%t/%p, retr=%r/%b, del=%d/%m, size=%s,
> bytes=%i/%o
> namespace:
> type: private
> prefix: INBOX.
> inbox: yes
> list: yes
> subscriptions: yes
> lda:
> postmaster_address: postmas...@example.com auth default:
> mechanisms: plain login
> cache_size: 1024
> username_chars:
> abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$-
> =?^_{}~./@+%
> passdb:
> driver: checkpassword
> args: /usr/local/cpanel/bin/dovecot-auth
> userdb:
> driver: prefetch
> socket:
> type: listen
> client:
> path: /var/run/dovecot/auth-client
> mode: 438
> plugin:
> quota: maildir
> quota_rule: Trash:ignore
> acl: vfile
[Dovecot] Right values for Antispam plugin
Hi!
I'm currently configuring the Dovecot Antispam plugin for the use with
Dspam. In general it works, but I'm not sure about one special config
parameter:
antispam_dspam_args
At the moment I set it to:
antispam_dspam_args = --source=error;--signature=%%s;--user;%u
Is that the appropriate value for retraining? I'm not sure if "%%s" is
correct to get the signature value. I was not able to find any
documentation that describes that value.
So I just want to know if my plugin config is correct for retraining.
plugin {
antispam_backend = dspam
antispam_spam = Spam
antispam_trash = trash;Trash;Deleted Items;Deleted Messages
antispam_signature = X-DSPAM-Signature
antispam_signature_missing = move
antispam_dspam_binary = /usr/bin/dspam
antispam_dspam_args = --source=error;--signature=%%s;--user;%u
}
Thanks,
Michael
Re: [Dovecot] Encryption solution for messages at rest
On 10/30/2013 09:01 AM, Benny Pedersen wrote: > Michael Orlitzky skrev den 2013-10-28 20:49: > >> php_admin_value open_basedir /var/www/$domain/$host/ >> php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp >> php_admin_value session.save_path /var/www/$domain/$host/tmp >> php_admin_value sys_temp_dir /var/www/$domain/$host/tmp > > so dont create tmp upload dirs in webroot, this is classic way of > showing no care > DocumentRoot is /var/www/$domain/$host/public.
Re: [Dovecot] Encryption solution for messages at rest
On 28/10/13 23:22, Frerich Raabe wrote: On 2013-10-28 20:23, Reindl Harald wrote: Am 28.10.2013 20:14, schrieb Douglas Mortensen: However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it impossible and useless if someone comes that far he can also read whatever configuration containing the keys In principle, this can be addressed by employing asymmetric key encryption. You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail. In practice, it's probably not that easy: 1. I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore. 2. Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar. There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server. Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server. Incoming mail would be automatically encrypted with the public key, then stored. When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly. Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection. Mike.
Re: [Dovecot] Encryption solution for messages at rest
On 2013-10-30 16:03, Miquel van Smoorenburg wrote: On 28/10/13 23:22, Frerich Raabe wrote: You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail. [..] Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server. Incoming mail would be automatically encrypted with the public key, then stored. When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly. Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection. The whole idea of using asymmetric encryption was that the server *does not* have the private key. It only has the public key, so it can store incoming mail encrypted using the users public key (which requires no password). Dovecot would then just serve the encrypted mail, all encryption would happen on the client side using the private key which only the client has. In the case of Maildir, I suspect (but I don't know) that Dovecot doesn't treat the individual files as plain data: it does look into them when serving (not only when indexing) to parse some headers or so. So I guess you cannot just encrypt the raw file on disk but you rather have to "rewrite" the mail so that only the body is encrypted but the headers are left untouched. This means that a hostile root user could see the headers, but at least not the body of the message. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Encryption solution for messages at rest
Am 30.10.2013 15:54, schrieb Michael Orlitzky: > On 10/30/2013 09:01 AM, Benny Pedersen wrote: >> Michael Orlitzky skrev den 2013-10-28 20:49: >> >>> php_admin_value open_basedir /var/www/$domain/$host/ >>> php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp >>> php_admin_value session.save_path /var/www/$domain/$host/tmp >>> php_admin_value sys_temp_dir /var/www/$domain/$host/tmp >> >> so dont create tmp upload dirs in webroot, this is classic way of >> showing no care > > DocumentRoot is /var/www/$domain/$host/public and so open_basedir should be the same and *not* include "upload_tmp_dir" and "session.save_path", otherwise this all is nonsense from security point of view and to come back to topic: do *not* install a public webserver on your mailserver - period signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Encryption solution for messages at rest
Quoting Miquel van Smoorenburg : On 28/10/13 23:22, Frerich Raabe wrote: On 2013-10-28 20:23, Reindl Harald wrote: Am 28.10.2013 20:14, schrieb Douglas Mortensen: However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it impossible and useless if someone comes that far he can also read whatever configuration containing the keys In principle, this can be addressed by employing asymmetric key encryption. You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail. In practice, it's probably not that easy: 1. I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore. 2. Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar. There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server. Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server. Incoming mail would be automatically encrypted with the public key, then stored. When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly. Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection. Mike. Or someone that has your email password. Basically, it's no different than unencrypted mail on an encrypted filesystem. Doing more work != more secure - that's why Lavamail was nothing more than a marketing ploy. Imagine going to your bank to put things in your lockbox, and giving your personal items to the teller who then runs an obstacle course before getting to the vault. Are your things more secure than you putting the items in the lockbox you have the key for? Use GPG, and make sure the user understands that full text search is not available. For the client, either they run it locally, use the gpg Chrome plug-in, or the site implements opengpg.js. Then all decryption occurs client-side. http://openpgpjs.org/ You could come up with some custom public/private key exchange, but why? If you're going to encrypt and decrypt it locally anyways, what does it matter? The equivalent to the Lavabit hack, without the pointless runaround, would be to use the Dovecot zip module to encrypt the data so only the Dovecot process can read it - though you could still trivially log the user's password for direct data access. IMHO, logging a password you receive in plain text is far from a hack. To me a hack requires a little complexity or inginuity. Rick
Re: [Dovecot] dovecot-ldap : can't find user in OU subtree
Hello and thanks for your answer.
Le 30/10/2013 19:32, Steffen Kaiser a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 30 Oct 2013, m...@electronico.nc wrote:
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
/etc/dovecot/dovecot-ldap-passdb.conf.ext:
hosts = localhost
auth_bind = yes
auth_bind_userdn = cn=%u,OU=users,dc=domain,dc=lan
You define your bind DN as cn=%u,OU=users,dc=domain,dc=lan
ldap_version = 3
base = ou=users,dc=domain,dc=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
user_attrs = uid=20001, gid=20001, home=/media/data/email/%n,
mail=/media/data/email/%n/mail
user_filter = (&(objectClass=person)(cn=%n)(mail=*))
pass_filter and user_filter differ in %u vs. %n.
I doesn't really matters in this situation as users are connected to an
unique AD domain and their credentials are setup with user/password, so
in this case %u and %n are identical.
Here is the debug part when user test3 (located in ou=users,
ou=administrative) tries to login:
The auth_bind_userdn does not match the ou=administrative location.
Drop the auth_bind_userdn, IMHO, so Dovecot actually uses pass_filter
to search for the DN of the user.
I have tried a lot of ways to use DN or OU in pass_filter, like :
pass_filter = (&(objectClass=person)(cn=%u)(ou=users)(mail=*))
pass_filter = (&(objectClass=person)(cn=%u)(ou:dn:=rdk_users)(mail=*))
but it seems Active Directory doesn't support OU or DN in filters :-(
Thanks anyway for your help, this is definitively not a Dovecot issue.
Nicolas
Oct 30 18:49:12 serveur dovecot: auth:
ldap(test3,10.10.20.208,): invalid credentials
Oct 30 18:49:14 serveur dovecot: auth: Debug: client passdb out:
FAIL#0111#011user=test3
As soon as I move user 'test3' back to ou=users, it can login ...
Oct 30 18:53:57 serveur dovecot: auth: Debug: client passdb out:
OK#0111#011user=test3
- -- Steffen Kaiser
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUnDECl3r2wJMiz2NAQLEJQgAp/fECmujABG7xDI4nSkyn7ZcDp5xOqLm
qa+t2O+DPmEqC9EI+MIBaM8XOzKBG7iAVHpVtJJ06WA/Sn0aupyWxq6mAFEIYTtM
2byKy4eSWexZU3XbhvggqMVaRJTBGHV31f2d05ZXjLzFeU4nzczN7xZ4DKVRqzhz
ii72NyMDf1bUhEx+1O7irMLnitOtpBlxsI5Xws6qrc1T4xlv0jjEkaqXEQAnPLWH
9F4x+t1mKks+UcMMl6wOUQ/Siozg4GBVjnyNd8F7bLVRznntkhxzOY0apCC8Df9+
kC2OhOF9ItHXKR2QI9w/emdqeKjbGQHEdrqC3Von2T/ntUA3yYHrCw==
=mGae
-END PGP SIGNATURE-
Re: [Dovecot] dovecot-ldap : can't find user in OU subtree
Am 30.10.2013 21:17, schrieb m...@electronico.nc:
Hello and thanks for your answer.
Le 30/10/2013 19:32, Steffen Kaiser a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 30 Oct 2013, m...@electronico.nc wrote:
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
/etc/dovecot/dovecot-ldap-passdb.conf.ext:
hosts = localhost
auth_bind = yes
auth_bind_userdn = cn=%u,OU=users,dc=domain,dc=lan
You define your bind DN as cn=%u,OU=users,dc=domain,dc=lan
ldap_version = 3
base = ou=users,dc=domain,dc=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
You should use
/etc/dovecot/dovecot-ldap-passdb.conf.ext
hosts = localhost
dn = cn=ldap,cn=Users,DC=domain,DC=lan
dnpass = My_secret_pass
auth_bind = yes
ldap_version = 3
base = OU=users,DC=domain,DC=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
That way pass_filter should match
cn=%u,OU=administrative,OU=Users,DC=domain,DC=lan as well. Take an look
at http://wiki2.dovecot.org/AuthDatabase/LDAP/AuthBinds DN lookup vs. DN
template.
Re: [Dovecot] dovecot-ldap : can't find user in OU subtree // solved
Le 31/10/2013 10:42, Achim Gottinger a écrit :
Am 30.10.2013 21:17, schrieb m...@electronico.nc:
Hello and thanks for your answer.
Le 30/10/2013 19:32, Steffen Kaiser a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 30 Oct 2013, m...@electronico.nc wrote:
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
/etc/dovecot/dovecot-ldap-passdb.conf.ext:
hosts = localhost
auth_bind = yes
auth_bind_userdn = cn=%u,OU=users,dc=domain,dc=lan
You define your bind DN as cn=%u,OU=users,dc=domain,dc=lan
ldap_version = 3
base = ou=users,dc=domain,dc=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
You should use
/etc/dovecot/dovecot-ldap-passdb.conf.ext
hosts = localhost
dn = cn=ldap,cn=Users,DC=domain,DC=lan
dnpass = My_secret_pass
auth_bind = yes
ldap_version = 3
base = OU=users,DC=domain,DC=lan
scope = subtree
pass_filter = (&(objectClass=person)(cn=%u)(mail=*))
That way pass_filter should match
cn=%u,OU=administrative,OU=Users,DC=domain,DC=lan as well. Take an
look at http://wiki2.dovecot.org/AuthDatabase/LDAP/AuthBinds DN lookup
vs. DN template.
Hello Achim,
Thanks for your answer :-)
Sure it works OK, as soon as I specify dn & dnpass (that I omitted in
passdb... :-[ )
Many thanks again !
Nicolas
Re: [Dovecot] IMAP Dovecot unknown namespace creating root folders
Hi All, For info I now believe that this is a cPanel issue not a Dovecot issue. cPanel re-writes dovecot.conf from a template, and what it calls the datastore. From what I have learnt so far it looks like cPanel seems to have lost the mechanism to permit you to change the 'prefix' value in the datastore which I believe should be located at /var/cpanel/conf/dovecot/main, as it no longer exists. The template /var/cpanel/templates/dovecot1.2/main.default exists and modifies the default dovecot.conf and sets it with 'prefix = INBOX.' which I believe is not a default dovecot.conf value. I was able to get around this by creating a copy of the main.deafult file which needs to be called main.local in the same directory and commenting out line 362 as such '#prefix = [% namespace_private.prefix %]' I am still investigating this and will post further info should I find it. Kind regards Marcus > -Original Message- > there is an entry in dovecot.conf for > the private namespace which sets the prefix required to access the > namespace as follows > > prefix = INBOX. > > I commented this out and restarted dovecot. > > > > Hi, I hope someone can point me in the right direction here. I am > > migrating a mailbox from a non cPanel server, and the mailboxes have > > folders which seem to be at the same level as the Inbox. > > when I try to > > create a 'top level' folder in Outlook I receive the error 'Cannot > > create the folder: Unknown namespace'
