Re: Temporary authentication failure ? Cant connect with ldap user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 25 Feb 2015, Mihai Badici wrote: On Wednesday 25 February 2015 10:31:22 David Scheele wrote: Is there a good, foolproof dovecot-openldap tutorial that walks you through the steps and works with the newest version of both softwares? I'm giving up and starting anew. 2015-02-24 11:33 GMT+01:00 Mihai Badici mi...@badici.ro: On Tuesday 24 February 2015 10:51:44 David Scheele wrote: Hmm... Well, I'm not sure. As I said, you can take a look on my templates. Openldap is maybe to flexible for us :) and the dovecot setup always depend on openldap setup.. which depend on your distribution if you install it with apt-get. If you download my packages you don't need to install them but there are some configuration templates you can see and modify. If you have anonymous access you don't need to bind with admin credentials. (Y) @David: You should know your LDAP setup and craft Dovecot for it. - From your question I guess that you have not changed the LDAP scheme, but use some default posixAccount objectclass. So tell us: 1) does ldapsearch -x -h server displays all users ? If yes: No admin access required. 2) How does your users are to login? Mail address, account name, user name? 3) Which information is storred in LDAP per account mandatory and in which LDAP attribute. *ldapsearch -x cn=admin* gives me: | # A bunch of information not really interesting | # search result | search: 2 | result: 32 No such object | | numResponses: 1 *ldapsearch -x cn=admin* gives the same. Did i configure the ldap wrong? Ldapsearch will search in the default container. But probably the admin user is in different container, like cn=admin,cn=config so you can't find it with this search - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBVO27x3z1H7kL/d9rAQJGhggAj/DEzn5pl9yGG2tgAo2OvMCAW9ag/saw D+vDNK2MKgDRYbWk3Rt9pdHGWmTBtXMZltIX/EFe/nFOMMBFpwS0qbEaJedCuNad ThEVtrYRkliwkXR6XMdLbPWbM47eJt+feftygD/NJ6V5rZ6QmX22aALJbZz8QbRJ 9nq7CsbGai1T99cjUxBny2u6jF96gjXI4DIr8iyva+GIWiehIGUl4n+9NGqgvvky SBLwefTrRZDQPfMj4+NjNxdjZ/RDKC+aFVSTrbybXQCTUv3LDm9BU5JJchO6q53x VzJWLmC08gmuv0bG+xc5rmoeV49GoFhkX1C8h5ovDbG5XYbPiP9pQA== =Z1Ak -END PGP SIGNATURE-
Re: btrfs for mail_attachment_dir
On Qua, 25 Fev 2015, Hardy Flor wrote: I don't find any indication, that no btrfs for then filesystem for the path in mail_attachment_dir is to be used. but btrfs has a big problem with hard links in the same directory. According to [0] (and the links in there), this problem has been long solved. [0]http://en.wikipedia.org/wiki/Btrfs#File_system_tree -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: btrfs for mail_attachment_dir
I have posted this in the German-debian forum: https://debianforum.de/forum/viewtopic.php?f=9t=154096 The result was that it still does not work. I have the kernel with version 3.13.33 According to [0] (and the links in there), this problem has been long solved. [0]http://en.wikipedia.org/wiki/Btrfs#File_system_tree
ACL Error
I'm trying to set up global ACLs. I have the following in the config file:
# acl
mail_plugins = acl
protocol imap {
mail_plugins = $mail_plugins imap_acl
}
plugin {
# Without global ACLs:
#acl = vfile
# With global ACL files in /etc/dovecot/dovecot-acls file (v2.2.11+):
#acl = vfile:/etc/dovecot/dovecot-acl
acl = vfile:/usr/local/etc/dovecot/dovecot-acl
}
And here is my dovecot-acl:
user=bobber lrwstipekxa
authenticated lr
But when I restart dovecot and try to access folders, I get the
following errors in the log file:
Error: Global ACL file /usr/local/etc/dovecot/dovecot-acl line 1:
Unknown ID 'lrwstipekxa'
Any ideas what's causing this?
--
*Bob Wooldridge*
Blog: http://kc0dxf.net/blog/
dsync backup touch source index files.
Hi everyone, Can someone explain me why dsync need read-write access to source box when pulling data (dsync -R backup)? I am working on migration from Dovecot 1.x with maildir to latest Dovecot 2.2.15 with mdbox and found that there is no way to do this from ro filesystem (got failed: Read-only file system on access to /dovecot.index.log). I am wondering is it bug or feature? I am not sure that this is save to allow dsync v2.2.15 to have write access to v1.x indexes. -- Anton Chevychalov
New maildir default permissions
hi,
i'm trying to configure dovecot to create maildir directories of new
users with specific permissions. i'm ending with this
dovecot: auth: Debug: sql(blabla,::1,HJ/.): query: SELECT
data_user.username, data_user.password, 500 AS userdb_uid, 500 AS
userdb_gid, 500 as mail_access_groups, 750 as mode, '/var/mail/' AS
userdb_home, concat('maildir:/var/mail/', data_ldap.maildir) AS
userdb_mail, concat('*:bytes=', data_ldap.quota) AS userdb_quota_rule
FROM data_user LEFT JOIN data_ldap ON data_user.ldap_id=data_ldap.id
WHERE lower(username) = 'blabla' AND active=true
dovecot: auth: Debug: client passdb out:
OK#0111#011user=blabla#011mail_access_groups=500#011mode=750
dovecot: auth: Debug: master in: REQUEST#0111075576833#0115939#0111#.
dovecot: auth: Debug: prefetch(blabla,::1,HJ/.): success
dovecot: auth: Debug: master userdb out:
USER#0111075576833#011blabla#011uid=500#011gid=500#011home=/var/mail/#011mail=maildir:/var/mail/b/blabla#011quota_rule=*:bytes=100M
dovecot: imap-login: Login: user=blabla, method=PLAIN, rip=::1,
lip=::1, mpid=5940, secured, session=HJ/.
dovecot: imap: Debug: Loading modules from directory: /usr/lib/dovecot/modules
dovecot: imap: Debug: Module loaded:
/usr/lib/dovecot/modules/lib10_quota_plugin.so
dovecot: imap: Debug: Module loaded:
/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so
dovecot: imap: Debug: Added userdb setting: mail=maildir:/var/mail/b/blabla
dovecot: imap: Debug: Added userdb setting: plugin/quota_rule=*:bytes=100M
dovecot: imap(blabla): Debug: Effective uid=500, gid=500, home=/var/mail/
dovecot: imap(blabla): Debug: Quota root: name=User quota backend=maildir args=
dovecot: imap(blabla): Debug: Quota rule: root=User quota mailbox=*
bytes=104857600 messages=0
dovecot: imap(blabla): Debug: Namespace inbox: type=private, prefix=,
sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes
location=maildir:/var/mail/b/blabla
dovecot: imap(blabla): Debug: maildir++: root=/var/mail/b/blabla,
index=, control=, inbox=/var/mail/b/blabla, alt=
dovecot: imap(blabla): Debug: Namespace : /var/mail/b/blabla doesn't
exist yet, using default permissions
dovecot: imap(blabla): Debug: Namespace : Using permissions from
/var/mail/b/blabla: mode=0700 gid=-1
could anyone tell me, how to set the default permissions? it uses
mode=700, and i need mode=750 instead
i'm using dovecot 2.1.17
thanks
fous
Proxying of non plain SASL mechnisms.
Hi, I understand from earlier discussions that the reason dovecot doesn't support proxying of other SASL mechanisms than those which supply the plaintext password is that in general it would be possible to proxy any SASL mechanism since it might protect against man-in-the-middle attacks (which would prevent proxying). However, that has led to choice between letting users use PLAIN (or equivalent), or to have the proxy access the target hosts by master password. Of course, having the plaintext password the proxy could in principle do other challenge/response SASL handshakes with the target backend, but right now only LOGIN and PLAIN is implemented. So I wondered about the rationale for not just forward the SASL handshake. - First, blindly forwardning will not do, since the mech data has to be decoded anyway to do any per/user passdb lookup (to, say, find the target host). But you don't need authentication to actually succeed to do that. You only need AuthZ-id or AuthN-id. - Secondly, the design of the interaction between imap-login processes and the auth-service in general prevent in general to forward multi-handshake SASL mechanisms, since the authentication must be done before the proxying can be started. But it doesn't prevent forwarding of single handshake SASL mechanisms which use SASL-IR. - Thirdly, while it's correct that some SASL mechanisms protect against man-in-the-middle attacks, that doesn't apply for most single-handshake SASL-IR mechanisms unless they do some kind of channel-binding. (like SASL EXTERNAL) For example, the GS2-KRB5 SASL mech would be perfectly forwarded if just the Kerberos ticket doesn't put restrictions on the client IP-address. So, why not just extend the support for proxy authentication forwarding to any single-handskake SASL-IR mechanism, which doesn't use channel-binding? (which includes PLAIN, but also GS2-KRB5, and possibly others). /Peter
Re: dsync backup touch source index files.
I don't know the answer to your question, but in case you don't get a suitable answer from someone better qualified than me, you might try having dovadm pull the data my making an imap connection to the older server like: doveadm -o imapc_features=fetch-headers -o mail_prefetch_count=20 -o imapc_port=993 -o imapc_ssl=imaps -o imapc_ssl_verify=no -o mail_fsync=never -o imapc_host=mail.example.com -o imapc_user=mailu...@exmple.com -o imapc_password=123456 backup -R imapc:
Re: Mail migration / dsync
I'm not an expert, but I just gave a similar answer to someone else in a similar situation (significantly older dovecot version on old server) and I suggest trying to use doveadm backup on the new server to pull the mail from the old server via IMAP like: doveadm -o imapc_features=fetch-headers -o mail_prefetch_count=20 -o imapc_port=993 -o imapc_ssl=imaps -o imapc_ssl_verify=no -o mail_fsync=never -o imapc_host=mail.example.com -o imapc_user=mailu...@exmple.com -o imapc_password=123456 backup -R imapc:
Re: btrfs for mail_attachment_dir
Am 25.02.2015 um 12:24 schrieb Hardy Flor: I don't find any indication, that no btrfs for then filesystem for the path in mail_attachment_dir is to be used. but btrfs has a big problem with hard links in the same directory. Nuisance is the only deal with a different file system? Btrfs is still nowhere near production ready in 2015. If you want to run a server, which should be reliable, use ext4 oder maybe XFS instead. Or ZFS, if you need a COW. If you are feeling adventurous, then use btrfs.
Metadata suport for public mailboxes
I'm using the latest version of dovecot (2.2.15) and I was trying to use a public namespace with metadata; I've found that it works for the users with enough permissions to set the metadata, but the values are set per user, that is, each user has its own metadata and does not see the values set by others. That sounds OK, as my mail_attribute_dict is configured as follows: mail_attribute_dict = file:/srv/vmail/%d/spool/%n/dovecot-metadata But for public mailboxes it would make sense to set the metadata in a user independent mode. Searching around I've found the following on the dovecot changelog: 2013-11-02 Timo Sirainen t...@iki.fi [...] TODO: - Metadata doesn't work for public namespaces. There should probably be a mail_attribute_public_dict setting for that. [...] So my guess that the mail_attribute_public_dict is not available. Is that the case or has it been implemented in a different way? Thanks in advance, Sergio -- Sergio Talens-Oliag s...@iti.es http://www.iti.es/ Key fingerprint = FF77 A16B 9D09 FC7B 6656 CFAD 261D E19A 578A 36F2
Re: Temporary authentication failure ? Cant connect with ldap user
Is there a good, foolproof dovecot-openldap tutorial that walks you through the steps and works with the newest version of both softwares? I'm giving up and starting anew. 2015-02-24 11:33 GMT+01:00 Mihai Badici mi...@badici.ro: On Tuesday 24 February 2015 10:51:44 David Scheele wrote: Hmm... *ldapsearch -x cn=admin* gives me: | # A bunch of information not really interesting | # search result | search: 2 | result: 32 No such object | | numResponses: 1 *ldapsearch -x cn=admin* gives the same. Did i configure the ldap wrong? Ldapsearch will search in the default container. But probably the admin user is in different container, like cn=admin,cn=config so you can't find it with this search
Re: Temporary authentication failure ? Cant connect with ldap user
On Wednesday 25 February 2015 10:31:22 David Scheele wrote: Is there a good, foolproof dovecot-openldap tutorial that walks you through the steps and works with the newest version of both softwares? I'm giving up and starting anew. 2015-02-24 11:33 GMT+01:00 Mihai Badici mi...@badici.ro: On Tuesday 24 February 2015 10:51:44 David Scheele wrote: Hmm... Well, I'm not sure. As I said, you can take a look on my templates. Openldap is maybe to flexible for us :) and the dovecot setup always depend on openldap setup.. which depend on your distribution if you install it with apt-get. If you download my packages you don't need to install them but there are some configuration templates you can see and modify. If you have anonymous access you don't need to bind with admin credentials. *ldapsearch -x cn=admin* gives me: | # A bunch of information not really interesting | # search result | search: 2 | result: 32 No such object | | numResponses: 1 *ldapsearch -x cn=admin* gives the same. Did i configure the ldap wrong? Ldapsearch will search in the default container. But probably the admin user is in different container, like cn=admin,cn=config so you can't find it with this search -- Mihai Bădici http://mihai.badici.ro
btrfs for mail_attachment_dir
Hello, I don't find any indication, that no btrfs for then filesystem for the path in mail_attachment_dir is to be used. but btrfs has a big problem with hard links in the same directory. Nuisance is the only deal with a different file system? Hardy
