[Dovecot] Why deliver+usercheck? deliver+MTA?
Hi, I successfully configured dovecot using virtual users (and LDAP/AD). deliver is the LDA and verifies if the user exists (as recommended in the WIKI). However, the howtos in the Wiki say *nothing* about the case that the recipients should be verified *before* receiving the messages (prevent backscatter, ...). All configurations in the dovecot-Wiki (postfix and exim) just accept the mails and pass them to deliver. Also, all howtos which I found on the web. If the user does not exist, the mail is bounced because the mail was already accepted by the MTA. Nowadays this is an unacceptable configuration! Is there a special reason why there is no discussion about this? However, as postfix seems to be really too unflexible I have set up exim to handle incoming mail and do the usercheck in the router (with an LDAP query). But now the user is doubled-checked: Once when receiving with exim and a second time in deliver. This is not necessary, so I guess I can disable the LDAP query for deliver and set up a static userdb. Why does the Wiki recommened to verfify with deliver when the user needs to be checked at the MTA anyway? Regards, Luke
Re: [Dovecot] Why deliver+usercheck? deliver+MTA?
Hi, Thanks your your reply. Am 13.10.2010 12:03, schrieb Jerry: On Wed, 13 Oct 2010 11:32:50 +0200 Lukas Haase articulated: Hi, I successfully configured dovecot using virtual users (and LDAP/AD). deliver is the LDA and verifies if the user exists (as recommended in the WIKI). However, the howtos in the Wiki say *nothing* about the case that the recipients should be verified *before* receiving the messages (prevent backscatter, ...). All configurations in the dovecot-Wiki (postfix and exim) just accept the mails and pass them to deliver. Also, all howtos which I found on the web. If the user does not exist, the mail is bounced because the mail was already accepted by the MTA. Nowadays this is an unacceptable configuration! Is there a special reason why there is no discussion about this? However, as postfix seems to be really too unflexible I have set up exim to handle incoming mail and do the usercheck in the router (with an LDAP query). But now the user is doubled-checked: Once when receiving with exim and a second time in deliver. This is not necessary, so I guess I can disable the LDAP query for deliver and set up a static userdb. Why does the Wiki recommened to verfify with deliver when the user needs to be checked at the MTA anyway? First of all, I totally disagree about your Postfix comments. I have personally found it to be rather easy to configure, and totally RTF compliant, unlike some other MTAs. Ok. Then please tell me how to: 1.) Connect Domain example.com to dovecot with virtual users (use deliver as LDA) 2.) Connect Domain example.com to mailman (e.g. li...@example.com) Either I am too dumb or this pretty easy setup is not possible with postfix (but with exim of course). (I think the reason is that mailman relies on the pipe "|" in the aliases database. But this only works with postfix's LDA. Also a different transport would work - but it is the same domain). In any case, only the MTA can bounce mail without causing back-scatter. You didn't catch what I mean. First the one way to prevent backscatter is to NOT accept any mail with invalid recipient. As soon as the MTA accepts mail and AFTERWARDS finds out that the user does not exist it may become a backscatter problem! To my question: First look at [1]. With this setup, ANY (!) mail is accepted by postfix without any checks! The check is only done by deliver, but this is too late. If the receipient does not exist, the mail gets bounced. So why there is not even a hint for virtual_mailbox_maps or similar. Then, search google for the same problem. You will find thousand of HOWTOs but not a single HOWTO has the hint that the MTA *must* check the validity of the user. Now look at [2]. It is the same. Also in this setup all mails for the domain are accepted Postfix has checks in place to check and reject or accept mail. Yes, that is what I said. But again, the first question : Why is there not even a hint that this (important) thing also needs to be configured? And question 2: It is not Dovecot's job to do so. By the time Dovecot receives the message the recipient should have all ready been verified. There are a few places (e.g. [3,4]) where it is recommended to check users existence with deliver. Why should this be necessary when the MTA checks existence? [4] even states: "Unless your MTA already verifies that the user exists before calling deliver, you'll most likely want deliver itself to verify the user's existence." But in general this must be the case anyway for the reasons mentioned above (maybe except for some contrived cases). Regards, Luke [1] http://wiki.dovecot.org/LDA/Postfix [2] http://wiki.dovecot.org/LDA/Exim [3] http://wiki.dovecot.org/UserDatabase/Prefetch [4] http://wiki.dovecot.org/UserDatabase/Static
Re: [Dovecot] Why deliver+usercheck? deliver+MTA?
Am 13.10.2010 13:08, schrieb Daniel Luttermann: Lukas Haase wrote on 10/13/2010: [...] By default, Postfix rejects mails for unknown local users.If Postfix accepts mails for unknown users than it's a configuration problem or you don't maintain a list of valid users. Yes, but I am talking about virtual users. Is there a special reason why there is no discussion about this? It's Postfix related - Dovecot does no checks about valid recipients for Postfix but you can use the same data sources as for Dovecot - no need to maintain user lists for Postfix and Dovecot. But *why* would you want to let dovecot (deliver) check this? In any reason the MTA *must* have validated the existance of the local part. I do not know any reason why deliver should do this. And again: Both http://wiki.dovecot.org/LDA/Postfix http://wiki.dovecot.org/LDA/Exim describe setups for virtual users. But none of these pages give a hint that the MTA needs to check the local part too. Because Postfix needs to check for valid recipients why should there a special hint in the Dovecot Wiki about that? Because if someone implements a system based on the WIKI above he builds up an insecure system (producing backscatter). You must first make sure that Postfix works as expected - no other IMAP Server checks vor valid recipients. Yes but no other IMAP server (but I only know Courier!) checks the validity of the user in the LDA. maildrop for example does not. However, as postfix seems to be really too unflexible I have set up exim to handle incoming mail and do the usercheck in the router (with an LDAP query). But now the user is doubled-checked: Once when receiving with exim and a second time in deliver. This is not necessary, so I guess I can disable the LDAP query for deliver and set up a static userdb. Why is Postfix unflexible? Use reject_unverified_recipient for dynamic verification of valid recipients and there's no need to maintain static files. You could also use a LDAP query to retreive a list of valid recipients before you accept the mail for non-existing users. Thank you! Does reject_unverified_recipient also work when the mail is passed to deliver as described in http://wiki.dovecot.org/LDA/Postfix "Virtual Users"? If this would be the case then this is exactly what I was looking for! Until now I tried to use an LDAP query. But also deliver uses an LDAP query to check the existance of the user. And this was my question if both of them are necessary. To the question why postfix is too unflexible: I found no way how to: * Hook up *fully* virtual users with dovecot (using deliver) for domain example.com * Hook up mailing lists for domain example.com using mailman The current setup uses system users and therefore this setup is no problem. But now there are virtual users ... Why does the Wiki recommened to verfify with deliver when the user needs to be checked at the MTA anyway? Checking of valid recipients is a Postfix job so you can use relay_recipient_maps, reject_unverified_sender or virtual_mailbox_maps (depending on your configuration). Btw: what does the Wiki recommend? Weblink? Yes of course, it is a postfix job. But also postfix jobs are described in the Wiki: http://wiki.dovecot.org/LDA/Postfix. And I think a small hint that the user must make sure that local parts are validated would be fine. Regards Luke
[Dovecot] Permissions in shared folders
Hi,
On my mail server I want to implement shared folders for each workgroup
where there are many workgroups.
One way would be to create a separate namespace for each workgroup.
However, this does not scale well so I decided to use a single Shared
mailbox and use ACLs:
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:CONTROL=~/Maildir/shared
}
Each workgroup should get a subfolder in "Shared". Until now, this
works, I create .Group1, .Group2 and assign correct group permissions
and ACL files.
However, now a user from group1 wants to create a subfolder in his IMAP
folder. Since the permissions for /var/mail/shared/.Group1 are correct
(writeable to group1 and the user is member of group1 and 'k' ACL
permissions are active) I would expect it to work.
However, for obvious reasons, the *sub*folder is created as
/var/mail/shared/.Group1.Subfolder
so it is actually not a subfolder in sense of the filesystem but rather
a folder inside /var/mail/shared
However, the user does (and should) not have write permissions to
/var/mail/shared (only to /var/mail/shared/.Group1).
Is there a way to overcome this problem? Why can't dovecot just use
/var/mail/shared/.Group1/.Subfolder? Is there an option to do so? It
would make everything a lot easier.
The one option is to make /var/mail/shared world-writeable - which is
not really a good option.
A second option might be to use ACLs and give each group write
permissions to /var/mail/shared. However, not even this seems very
"clean" to me.
What is the best way to handle this?
Best regards,
Luke
[Dovecot] ldap: LDAP attribute used multiple times. This is currently unsupported
Hi, I have a problem when migrating from dovecot 1.0 to dovecot 1.2 (Debian lenny to Debian squeeze). In my dovecot-ldap.conf I have: user_attrs = homeDirectory=home,uidNumber=uid,gidNumber=gid,uid=system_groups_user I use the last parameter for the groups which I need for shared folders. If I only use this, everything works. However, I also use LDAP as passdb with prefetch: pass_attrs = uid=user,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid,uid=userdb_system_groups_user In this configuration I get the error in the subject line that uid is used multiple times. I know, but the message is somehow "weird" since it says it is *currently* unsupported. However, it seems to me that it is not supported any more. Is this true? Is there a reason for this? How can I fix this problem? Until now my shared folders do not works anymore because the group memberships are not assigned any more because of the missing system_groups_user parameter. Best regards, Luke
[Dovecot] Effect of separators (was: Re: Permissions in shared folders)
Dear list,
A dumb question: What exactly is the effect of the separator?
Is it also used to separate in the underlying file system? I.e. when I
have the separator '/', the IMAP folder Sent/Jan is physically stored as
/home/lukas/Maildir/.Send/Jan/cur
? If this is true this would greatly solve my problem described at the
bottom.
I have tried it myself, however, dovecot 1.2 does not allow to create a
namespace with a separator different than my default namespace...
If this works, is there a convenient migration procedure possible to
migrate from . to /?
The Wiki just mentions the other way (/ --> .).
Best regards,
Luke
Am 08.02.2011 11:33, schrieb Lukas Haase:
Hi,
On my mail server I want to implement shared folders for each workgroup
where there are many workgroups.
One way would be to create a separate namespace for each workgroup.
However, this does not scale well so I decided to use a single Shared
mailbox and use ACLs:
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:CONTROL=~/Maildir/shared
}
Each workgroup should get a subfolder in "Shared". Until now, this
works, I create .Group1, .Group2 and assign correct group permissions
and ACL files.
However, now a user from group1 wants to create a subfolder in his IMAP
folder. Since the permissions for /var/mail/shared/.Group1 are correct
(writeable to group1 and the user is member of group1 and 'k' ACL
permissions are active) I would expect it to work.
However, for obvious reasons, the *sub*folder is created as
/var/mail/shared/.Group1.Subfolder
so it is actually not a subfolder in sense of the filesystem but rather
a folder inside /var/mail/shared
However, the user does (and should) not have write permissions to
/var/mail/shared (only to /var/mail/shared/.Group1).
Is there a way to overcome this problem? Why can't dovecot just use
/var/mail/shared/.Group1/.Subfolder? Is there an option to do so? It
would make everything a lot easier.
The one option is to make /var/mail/shared world-writeable - which is
not really a good option.
A second option might be to use ACLs and give each group write
permissions to /var/mail/shared. However, not even this seems very
"clean" to me.
What is the best way to handle this?
Best regards,
Luke
Re: [Dovecot] ldap: LDAP attribute used multiple times. This is currently unsupported
Dear Timo, Thank you for your advice! Am 08.02.2011 18:35, schrieb Timo Sirainen: On 8.2.2011, at 17.23, Lukas Haase wrote: [...] I know, but the message is somehow "weird" since it says it is *currently* unsupported. However, it seems to me that it is not supported any more. Is this true? Is there a reason for this? I'm pretty sure it never worked. I think in v1.0 it simply ignored the first uid=user. So you could probably just remove that. Unfortunately not. I am really sure it worked in v1.0. For example: # id luke uid=1000(luke) gid=100(users) groups=51683(family),25783(ssh_users),63315(projects),19580(multimedia),1019(data),51684(friends),100(users) So luke's *primary* group is "users" but he is also member of the other groups (like "family"). An IMAP folder in my shared namespace has permissions as follows: # ls -la /var/mail/shared [...] drwxrwx--- 5 root family 4096 Feb 8 22:53 .Family [...] So the folder "Family" in the shared namespace is *not* accessible in the *default* configuration since the directory is not accessible by the group "users" but only by the group "family". And in the default configuration the groups are ignored by dovecot (except the primary group). In Debian Lenny (dovecot 1.xx) I set "uid=system_user" in the "user_attrs" setting of my ldap config. According to the Wiki, this should read out the primary groups of the user contained in the LDAP field "uid". And this worked: I could access the folder. Now I upgraded to Debian sequeeze (dovecot 1.2) and I get the mentioned error message. So I am somehow sure that it actually worked and was not just ignored. Nevertheless, is there a way to overcome this issue? Can dovecot just read out the group membership from the "user" field of "pass_attrs"? Another obvious solution would be to define a manual scheme with a manual attribute "uid_dovecot" and copy the value of "uid". But this seems to me like a using a sledgehammer method since it provides unnecessary redundancy in the LDAP tree (where the increased complexity might cause problems and inconsistencies) and requires defined a manual LDAP scheme. Any solution would be greatly appreciated! Best regads, Luke
Re: [Dovecot] Effect of separators
Am 08.02.2011 18:14, schrieb Willie Gillespie: On 02/08/2011 08:54 AM, Lukas Haase wrote: Dear list, A dumb question: What exactly is the effect of the separator? Is it also used to separate in the underlying file system? I.e. when I have the separator '/', the IMAP folder Sent/Jan is physically stored as As far as I understand, the separator is used in the context of IMAP only, and not the file system. Dear Willie, So if I understand correctly, if I set '/' as separator, the Maildir layout will still be .Folder1.subfolder ? Thank you for this hint, I think this is clear now. [...] Somebody can correct me if I'm wrong, but I don't believe it has an effect on the backend (besides disallowing the use of that character in a folder name). Thank you for your reply! Regards, Luke
Re: [Dovecot] Permissions in shared folders
Dear Timo,
Thank you for your advice!
Am 08.02.2011 18:39, schrieb Timo Sirainen:
On 8.2.2011, at 12.33, Lukas Haase wrote:
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:CONTROL=~/Maildir/shared
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared
Why? According to the Wiki, CONTROL is used for example for the
subscriptions (I can not use "subscriptions=no" because my private
namespace is "INDEX." and not empty) and therefore I use it.
Furthermore, according to the Wiki, INDEX can be omitted if all users
have write permissions because this way the index file is shared among
all users.
However, I can also set CONTROL *and* INDEX. I think there is nothing
wrong about it, isn't it?
[...]
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
Wooow, great! Thank you very much!
I found very few documentation (although it is mentioned in the Wiki) on
it so I think that is the reason why I did not know it.
Thank you very much!
Regards,
Luke
[Dovecot] Questions about dovecot-shared in 1.2 and inherit group membership from parent mailbox
Hi,
I read the Wiki about dovecot-shared a few times but it is not 100%
clear to me (at least for 1.2).
First, if I want shared keywords I *must* have a dovecot-shared. In this
case, the permissions are not taken any longer from the parent folder
(what is exactly this parent folder?) but from the dovecot-shared file.
So in some sense dovecot-shared is always required (since everyone would
like to share keywords). True?
Second, is there only *one* dovecot-shared per namespace or per mailbox
*under* a specific namespace? Or an arbitrary number (where the "last"
is taken)? Where does dovecot-shared need to be placed?
For example, if the location of the namespace points to /var/mail/shared
and I have two mailboxes "group1" and "group2" inside.
Does the dovecot-shared need to reside in /var/mail/shared or
/var/mail/shared/group1 and /var/mail/shared/group2 (with LAYOUT=fs)? Is
it possible?
Third (and main) question: In /var/mail/shared I want to have a mailbox
for each group. Each user is member of his respective groups (in terms
of UNIX permissions *and* ACLs).
The mailboxes are owned by their respective groups and if a user creates
a subfolder inside it should surely have the same group assigned as the
parent mailbox (not the namespace!).
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
subscriptions = no
}
mail:~# ls -l -R /var/mail/shared/
/var/mail/shared/:
total 12
drwxrwx--- 5 root group1 4096 Feb 9 11:53 Group1
drwxrwx--- 5 root group2 4096 Feb 9 12:27 Group2
-rw-r--r-- 1 root root 23 Feb 9 11:52 dovecot-acl
-rw-rw-r-- 1 root root 0 Dec 15 2009 dovecot-shared
/var/mail/shared/Group1:
total 16
drwxrwx--- 2 root group1 4096 Feb 8 10:35 cur
-rw-r--r-- 1 root group1 28 Feb 9 11:52 dovecot-acl
-rw-rw-r-- 1 root group10 Dec 15 2009 dovecot-shared
drwxrwx--- 2 root group1 4096 Dec 15 2009 new
drwxrwx--- 2 root group1 4096 Feb 8 10:34 tmp
/var/mail/shared/Group1/cur:
total 0
/var/mail/shared/Group1/new:
total 0
/var/mail/shared/Group1/tmp:
total 0
/var/mail/shared/Group2:
total 16
drwxrwx--- 2 root group2 4096 Feb 8 10:35 cur
-rw-r--r-- 1 root group2 27 Feb 9 11:52 dovecot-acl
-rw-rwS--- 1 root group20 Dec 15 2009 dovecot-shared
drwxrwx--- 2 root group2 4096 Dec 15 2009 new
drwxrwx--- 2 root group2 4096 Feb 8 10:34 tmp
/var/mail/shared/Group2/cur:
total 0
/var/mail/shared/Group2/new:
total 0
/var/mail/shared/Group2/tmp:
total 0
Again: *Inside* /var/mail/shared I want to create mailboxes for each
group (Group1, Group2, ...). This is done only by the administrator.
Therefore /var/mail/shared is owned by root.
Each Group1, Group2, ... in turn is owned by group1, group2, ...
I tried all combinations using dovecot-shared which came into my mind
such that a subfolder of Group1 is owned by group1. However, either
1.) the subfolder is owned by the primary group of the creating user
(group "users")
or
2.) the group of /var/mail/shared/dovecot-shared
or
3.) creation of the subfolder fails with
dovecot: IMAP(user1): chown(/var/mail/shared/Group2/Test1, -1, 0(root))
failed: Operation not permitted (egid=100(users), group based on
/var/mail/shared/dovecot-shared)
dovecot: IMAP(user1): mkdir(/var/mail/shared/Group2/Test1/cur) failed:
Operation not permitted
Is this just not possible or do I get something wrong here?
Regards,
Luke
Re: [Dovecot] ldap: LDAP attribute used multiple times. This is currently unsupported
Am 08.02.2011 23:52, schrieb Timo Sirainen: On 9.2.2011, at 0.12, Lukas Haase wrote: I'm pretty sure it never worked. I think in v1.0 it simply ignored the first uid=user. So you could probably just remove that. Unfortunately not. I am really sure it worked in v1.0. For example: I mean in v1.0 it set system_groups_user=uid, but it didn't set user=uid. I doubt you need the user=uid, since they're probably same to begin with (you didn't show pass_filter so I don't know how you look up the user). So just remove the "uid=user" from pass_attrs and it'll probably work fine. Great, yes, this is/was the case. I just remove it and use "auth_username_format = %Lu" which works. Thank you! Regards, Luke
Re: [Dovecot] Permissions in shared folders
Dear Timo,
Am 08.02.2011 23:48, schrieb Timo Sirainen:
On 9.2.2011, at 0.20, Lukas Haase wrote:
namespace public { separator = . prefix = Shared. location =
maildir:/var/mail/shared:CONTROL=~/Maildir/shared
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared
Why? According to the Wiki, CONTROL is used for example for the
subscriptions (I can not use "subscriptions=no" because my private
namespace is "INDEX." and not empty) and therefore I use it.
[...]
You can create a prefix="" namespace with list=no hidden=yes where
the subscriptions will be saved.
Great hint! This works!
For the archive:
namespace private {
separator = .
prefix =.
inbox = no
list = no
hidden = yes
location = maildir:~/Maildir-root
subscriptions = yes
}
The subscriptions file for the public namespaces are not saved in
~/Maildir-root.
[...]
Yes, but then if any keywords (= custom flags = labels = ..) are
used, they're not shared between users. Other users instead will see
keywords like "Unknown-1".
I re-read the Wiki again and now I understand it.
The usual option will be using dovecot-shared and INDEX=~/Maildir/...
for private Seen flags and index, no CONTROL for shared keywords and
subscriptions = no for private subscriptions in the private parent
namespace.
Thank you very much for these tipps!
Regards,
Luke
Re: [Dovecot] Questions about dovecot-shared in 1.2 and inherit group membership from parent mailbox
Dear Timo, Thank you for the reply! Am 09.02.2011 23:55, schrieb Timo Sirainen: [...] Second, is there only *one* dovecot-shared per namespace or per mailbox *under* a specific namespace? Or an arbitrary number (where the "last" is taken)? Where does dovecot-shared need to be placed? For each mailbox. (Definition) In my example: /var/mail/shared is the *namespace* and /var/mail/shared/.Group1/... /var/mail/shared/.Group2/... the mailboxes; is this true? For example, if the location of the namespace points to /var/mail/shared and I have two mailboxes "group1" and "group2" inside. Does the dovecot-shared need to reside in /var/mail/shared or /var/mail/shared/group1 and /var/mail/shared/group2 (with LAYOUT=fs)? Is it possible? group1& group2 Thank you. This means *no* dovecot-acl in /var/mail/shared. Third (and main) question: In /var/mail/shared I want to have a mailbox for each group. Each user is member of his respective groups (in terms of UNIX permissions *and* ACLs). The mailboxes are owned by their respective groups and if a user creates a subfolder inside it should surely have the same group assigned as the parent mailbox (not the namespace!). Well, now you're going into something that's a new feature :) But you can probably do: /var/mail/shared = root:root, 02770 /var/mail/shared/group1 = root:group1, 02770 Now filesystem should preserve group1 and Dovecot should preserve 02770 permissions. Woow, indeed, this seems to work, also in the presence of the "dovecot-acl" files in /var/mail/shared/group1 and /var/mail/shared/group2. What I have forgotten is 02770 for /var/mail/shared. I somehow do not understand why this matters... In fact, this structure seems to work now as expected: D /var/mail/shared = root:root, 02770 F /var/mail/shared/dovecot-acl = root:root, 0644 anyone authenticated l D /var/mail/shared/Group1 = root:group1, 02770 D /var/mail/shared/Group1/new = root:group1, 0770 D /var/mail/shared/Group1/cur = root:group1, 0770 D /var/mail/shared/Group1/tmp = root:group1, 0770 F /var/mail/shared/Group1/dovecot-shared = root:group1, 02660 F /var/mail/shared/Group1/dovecot-acl = root:group1, 0664 anyone group=group1 lrwstiek D /var/mail/shared/Group2 = root:group2, 02770 D /var/mail/shared/Group2/new = root:group2, 0770 D /var/mail/shared/Group2/cur = root:group2, 0770 D /var/mail/shared/Group2/tmp = root:group2, 0770 F /var/mail/shared/Group2/dovecot-shared = root:group2, 02660 F /var/mail/shared/Group2/dovecot-acl = root:group2, 0664 anyone group=group2 lrwstiek Thanks again! Best regards, Luke
Re: [Dovecot] Questions about dovecot-shared in 1.2 and inherit group membership from parent mailbox
Am 10.02.2011 13:49, schrieb Lukas Haase: [...] Third (and main) question: In /var/mail/shared I want to have a mailbox for each group. Each user is member of his respective groups (in terms of UNIX permissions *and* ACLs). The mailboxes are owned by their respective groups and if a user creates a subfolder inside it should surely have the same group assigned as the parent mailbox (not the namespace!). Well, now you're going into something that's a new feature :) But you can probably do: /var/mail/shared = root:root, 02770 /var/mail/shared/group1 = root:group1, 02770 As already mentioned, thank you very much, this works! However, I wonder if I am the one who needs different group-based mailboxes in a shared namespace ... I think it can't be that complicated?! Maybe the common way to go instead is to create a "virtual mail" mail group where all users belong to (and assign with mail_access_groups=sharedmail) and do all group-permissions solely with the ACL plugin? Best regards, Luke
[Dovecot] Cannot subscribe to shared folders
Hi,
I am unable to subscribe to shared folders with Thunderbird although
everything seems to be correct (dovecot 1.2).
What does not work? I click "Subscribe..." in Thunderbird. The shared
mailboxes are listed, all with [ ] (no checkbox). Therefore I mark them
[x], click "subscribe" and "OK". However, the folders do not appear in
the folder tree. Furthermore, when I again click "Subscribe..." the
folders do NOT have the mark [x] any more. This happens on different
computers with *new* profiles.
My configuration is the following (maybe that is the problem?!):
namespace private {
separator = .
prefix =.
inbox = no
list = no
hidden = yes
location = maildir:~/Maildir-root
subscriptions = yes
}
namespace private {
separator = .
prefix = INBOX.
inbox = yes
subscriptions = yes
}
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
subscriptions = no
}
The folder /var/mail/shared has appropriate permissions/form:
* Owner: $user:mailuser (all users are member of "mailuser")
* All files 0660, all folders 0770
* There exists a dovecot-shared in every folder
* There exists a dovecot-acl in each folder where each user has the
permissions "lrwstie"
I switched on "mail_debug = yes" but no messages.
However, the file ~/Maildir-root/subscriptions contains the subscribed
folders:
Shared.Group1
Shared.Group2
Shared.Group1/Test
Furthermore, I switched on rawlog. Everything seems to be OK as well:
.in-file:
2 subscribe "Shared.Group1"
3 lsub "" "INBOX.*"
5 lsub "" "Shared.*"
6 list "" "INBOX"
.out-file:
2 OK Subscribe completed.
[...]
I am pretty sure it already worked. But it stopped working. Does anybody
have a hint what could be the problem?
Regards,
Luke
Re: [Dovecot] Cannot subscribe to shared folders
Am 14.02.2011 14:54, schrieb Lukas Haase:
Hi,
I am unable to subscribe to shared folders with Thunderbird although
everything seems to be correct (dovecot 1.2).
What does not work? I click "Subscribe..." in Thunderbird. The shared
mailboxes are listed, all with [ ] (no checkbox). Therefore I mark them
[x], click "subscribe" and "OK". However, the folders do not appear in
the folder tree. Furthermore, when I again click "Subscribe..." the
folders do NOT have the mark [x] any more. This happens on different
computers with *new* profiles.
My configuration is the following (maybe that is the problem?!):
namespace private {
separator = .
prefix =.
inbox = no
list = no
hidden = yes
location = maildir:~/Maildir-root
subscriptions = yes
}
namespace private {
separator = .
prefix = INBOX.
inbox = yes
subscriptions = yes
}
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
subscriptions = no
}
[...]
In this case the subscriptions for Shared. are saved in
~/Maildir-root/subscriptions.
However, may be that this does NOT work in practice?
It works as soon as I set "subscriptions = yes" in the public namespace :-(
However, then the subscriptions are saved in the shared folder and the
users overwrite them themselves :-/
Regards,
Luke
[Dovecot] Bug(?): LSUB returns empty string although subscribed (was: Re: Cannot subscribe to shared folders)
Hi,
I did further investigation on this issue (using raw IMAP commands) and
I think that this is a bug...
Am 15.02.2011 18:53, schrieb Lukas Haase:
Am 14.02.2011 14:54, schrieb Lukas Haase:
Hi,
I am unable to subscribe to shared folders (...)
everything seems to be correct (dovecot 1.2).
My configuration is the following (maybe that is the problem?!):
namespace private {
separator = .
prefix =
inbox = no
list = no
hidden = yes
location = maildir:~/Maildir-root
subscriptions = yes
}
namespace private {
separator = .
prefix = INBOX.
inbox = yes
subscriptions = yes
}
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
subscriptions = YES / NO <--
}
[...]
In each case I make sure that all folders are subscribed, that is, the
subscribe command returns OK and the subscribed folders are written into
/var/mail/shared/subscriptions and ~/Maildir-root/subscriptions,
respectively. Just to make sure:
# cat /var/mail/shared/subscriptions
NoSpamDrop
Public
SpamDrop
# cat /home/lukas/Maildir-root/subscriptions
Shared.NoSpamDrop
Shared.Public
Shared.SpamDrop
#
It turns out that if I set
1.) subscriptions = yes (in the public namespace above)
the lsub command behaves correct:
. list "" "Shared.*"
* LIST (\HasNoChildren) "." "Shared.NoSpamDrop"
* LIST (\HasNoChildren) "." "Shared.Public"
* LIST (\HasNoChildren) "." "Shared.SpamDrop"
. OK List completed.
. lsub "" "Shared.*"
* LSUB () "." "Shared.NoSpamDrop"
* LSUB () "." "Shared.Public"
* LSUB () "." "Shared.SpamDrop"
. OK Lsub completed.
. logout
* BYE Logging out
. OK Logout completed.
closed
2.) ...but with subscriptions = no
the lsub command returns an empty list ALTHOUGH the folders are
subscribed:
. list "" "Shared.*"
* LIST (\HasNoChildren) "." "Shared.NoSpamDrop"
* LIST (\HasNoChildren) "." "Shared.Public"
* LIST (\HasNoChildren) "." "Shared.SpamDrop"
. OK List completed.
. lsub "" "Shared.*"
. OK Lsub completed.
. logout
* BYE Logging out
. OK Logout completed.
Now I am pretty sure that this is a bug. Maybe it is better to file a
bug report?
Best regards,
Luke
Re: [Dovecot] Bug(?): LSUB returns empty string although subscribed
Hi,
Thank you for your reply (and the bad news ;-) )
So the one solution for v1.2 is to use CONTROL=~/... in the public
namespace and relinquish the shared keywords feature?
Regards,
Luke
Am 17.02.2011 09:02, schrieb Timo Sirainen:
It's a bug, yes. It's also already fixed in v2.1 code tree as a result
of large cleanups and fixes to mailbox/subscriptions listing.
Backporting the fixes to v2.0 (or even worse: v1.x) would probably be a
lot of trouble..
On Wed, 2011-02-16 at 20:31 +0100, Lukas Haase wrote:
Hi,
I did further investigation on this issue (using raw IMAP commands) and
I think that this is a bug...
Am 15.02.2011 18:53, schrieb Lukas Haase:
Am 14.02.2011 14:54, schrieb Lukas Haase:
Hi,
I am unable to subscribe to shared folders (...)
everything seems to be correct (dovecot 1.2).
My configuration is the following (maybe that is the problem?!):
namespace private {
separator = .
prefix =
inbox = no
list = no
hidden = yes
location = maildir:~/Maildir-root
subscriptions = yes
}
namespace private {
separator = .
prefix = INBOX.
inbox = yes
subscriptions = yes
}
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
subscriptions = YES / NO<--
}
[...]
In each case I make sure that all folders are subscribed, that is, the
subscribe command returns OK and the subscribed folders are written into
/var/mail/shared/subscriptions and ~/Maildir-root/subscriptions,
respectively. Just to make sure:
# cat /var/mail/shared/subscriptions
NoSpamDrop
Public
SpamDrop
# cat /home/lukas/Maildir-root/subscriptions
Shared.NoSpamDrop
Shared.Public
Shared.SpamDrop
#
It turns out that if I set
1.) subscriptions = yes (in the public namespace above)
the lsub command behaves correct:
. list "" "Shared.*"
* LIST (\HasNoChildren) "." "Shared.NoSpamDrop"
* LIST (\HasNoChildren) "." "Shared.Public"
* LIST (\HasNoChildren) "." "Shared.SpamDrop"
. OK List completed.
. lsub "" "Shared.*"
* LSUB () "." "Shared.NoSpamDrop"
* LSUB () "." "Shared.Public"
* LSUB () "." "Shared.SpamDrop"
. OK Lsub completed.
. logout
* BYE Logging out
. OK Logout completed.
closed
2.) ...but with subscriptions = no
the lsub command returns an empty list ALTHOUGH the folders are
subscribed:
. list "" "Shared.*"
* LIST (\HasNoChildren) "." "Shared.NoSpamDrop"
* LIST (\HasNoChildren) "." "Shared.Public"
* LIST (\HasNoChildren) "." "Shared.SpamDrop"
. OK List completed.
. lsub "" "Shared.*"
. OK Lsub completed.
. logout
* BYE Logging out
. OK Logout completed.
Now I am pretty sure that this is a bug. Maybe it is better to file a
bug report?
Best regards,
Luke
[Dovecot] dovecot lost mail! Cause?
Hi, After using dovecot for several years now, today happend something which makes me really feel unconfortable: An email received was just not delivered properly, or, is lost! The mail (from an external server) was sent to two local mailboxes, user1 and user2. user1 received the message but for user2, it *magically* disappeared. MTA is exim4 which definitely processed the messages and handed over to dovecot deliver: 2012-11-12 07:28:21 1TXnVG-00053I-GD SA: [...] id=8644593.887351352701 685934.JavaMail 2012-11-12 07:28:21 1TXnVG-00053I-GD => user1 R=dovecot T=dovecot_pipe 2012-11-12 07:28:21 1TXnVG-00053I-GD => user2 R=dovecot T=dovecot_pipe 2012-11-12 07:28:21 1TXnVG-00053I-GD Completed Also, the log of dovecot tells that the mail should have been stored: Nov 12 07:28:21 mail dovecot: deliver(user1): sieve: msgid=<8644593.887351352701685934.JavaMail>: stored mail into mailbox 'INBOX' Nov 12 07:28:21 mail dovecot: deliver(user2): sieve: msgid=<8644593.887351352701685934.JavaMail.orbitz>: stored mail into mailbox 'INBOX' user1 received the mail but user2 not. Since user2 is myself, I *know* that I did not accidently delete any mail or something like that. It was just never received! Disk space is 3GB left, so enough. So I grepped the whole Maildir of user2 for the message ID. There is only one match in the dovecot.index.cache and within that, the most important data of the mail (Message ID, Date, Sender, Receiver, Subject) appears. But apart from that, not a single file! Is there hope to ever find out why what was going wrong here? It feels me very unconfortable because from now on I can never be sure any more that all my mails are really received :( :( However, as I said, my mail system processed maybe millions of messages the past 8 years. Although, I can not be sure if that was the case ... :( And help greatly appreciated! Luke PS: Dovecot version 1.2.15 (Debian 6.0.6) with Maildir backend on local harddrive. No NFS, nothing which can go wrong ... PPS: Original log files, just named replaced for privacy.
Re: [Dovecot] dovecot lost mail! Cause?
Hi, On 11/12/2012 1:19 AM, Steffen Kaiser wrote: > On Mon, 12 Nov 2012, Lukas Haase wrote: > >> Nov 12 07:28:21 mail dovecot: deliver(user2): sieve: >> msgid=<8644593.887351352701685934.JavaMail.orbitz>: stored mail into >> mailbox 'INBOX' > > are there any other log lines of user2? Anfortunately not :-( Grepped everything, and I would have posted otherwise. My hope is that the dovecot.index.cache may provide some insights (I made a backup copy of it). Luke
Re: [Dovecot] dovecot lost mail! Cause?
On 11/13/2012 1:18 AM, Michael Firnau wrote: > On Mon, Nov 12, 2012 at 01:44:37AM -0800, Lukas Haase wrote: >> Hi, >> >> On 11/12/2012 1:19 AM, Steffen Kaiser wrote: >>> On Mon, 12 Nov 2012, Lukas Haase wrote: >>> >>>> Nov 12 07:28:21 mail dovecot: deliver(user2): sieve: >>>> msgid=<8644593.887351352701685934.JavaMail.orbitz>: stored mail into >>>> mailbox 'INBOX' >>> >>> are there any other log lines of user2? >> >> Anfortunately not :-( Grepped everything, and I would have posted otherwise. >> >> My hope is that the dovecot.index.cache may provide some insights (I >> made a backup copy of it). > > Hi, > > yesterday i had a user missing mail and he had the junk-filter > in thunderbird activated. The mail was automagically moved from > the inbox to the spam folder. From the header i see you use thunderbird, > so it's a shot in the dark ... Hmm, yes, but even in that case, the mail would have been moved to the Spam folder in the account (i.e., on the IMAP server) and I would have found it when grepping over anything. Thanks, Luke
[Dovecot] Sieve force SSL
Hi, I have activated only imaps and managesieve. As sieve is running on a different port/protocol: Can I make sure that sieve can ONLY be used with SSL/TLS? As the credentials are transmitted I only offer services with SSL (IMAPS, SMTP over SSL, ...). For sieve I am not sure about this. If there is the possibility that user's credentials are transmitted in plain text I would block the port from the firewall, else I would offer my users the feature to change their rules with their own client (e.g. Thunderbird sieve). Regards, Luke
Re: [Dovecot] Sieve force SSL
Hi, Am 23.09.2010 14:58, schrieb Timo Sirainen: On Thu, 2010-09-23 at 12:16 +0200, Lukas Haase wrote: I have activated only imaps and managesieve. As sieve is running on a different port/protocol: Can I make sure that sieve can ONLY be used with SSL/TLS? http://wiki.dovecot.org/SSL Thank you. First, IMAP and SMTP ports are completely blocked by the corporate firewall (it is corporate policy to not allow IMAP and SMTP - I can not do anything about this). Second: [...] This could be because it makes it easier to ensure that no information is leaked, because SSL/TLS handshake happens immediately. Some clients unfortunately try to do plaintext authentication without STARTTLS, even when IMAP server has told the client that it won't work [...] This is my personal reason for preferring only IMAPS (and do not even offer IMAP). So back to sieve: If I set disable_plaintext_auth=yes and ssl=required then nothing should change for my IMAPS port because it is TLS per definition. And for managesieve it means that it should be protected the same way IMAP with STARTTLS would be. So a client would connect to port 2000 and LOGIN would not be advertised as long as STARTTLS is not issed. Correct? Regards, Luke
[Dovecot] Why dovecot does not want to read my acl file?
Hi,
Simple Scenario: Shared namespace and a specific UNIX group should have
access to it. System is Debian lenny (stable).
# cat /etc/dovecot/dovecot.conf
[...]
namespace public {
separator = .
prefix = Shared.
location = maildir:/var/mail/shared
}
mail_executable = /usr/local/sbin/dovecot-imap-fix.sh
mail_drop_priv_before_exec = no #just to make sure
[...]
# dpkg -l | grep dovecot
ii dovecot-common 1:1.0.15-2.3+lenny1 secure mail server that
ii dovecot-imapd 1:1.0.15-2.3+lenny1 secure IMAP server that
# cat /usr/local/sbin/dovecot-imap-fix.sh
#!/bin/sh
cat /var/mail/shared/.Office/dovecot-acl > /tmp/dovecot-$USER
env >> /tmp/dovecot-$USER
ACL_GROUPS=`groups $USER | tr ' ' ','`
export ACL_GROUPS
exec /usr/lib/dovecot/imap $*
# ls -la -R /var/mail/shared/ # (cut the .,.. in output)
/var/mail/shared/:
total 28
drwxrwx--- 5 root office 4096 Dec 15 15:53 .Office
drwxr-xr-x 2 root root 4096 Dec 14 16:55 cur
-rw-r--r-- 1 root root 23 Dec 15 07:46 dovecot-acl
-rw-r--r-- 1 root root 0 Dec 15 07:42 dovecot-shared
drwxr-xr-x 2 root root 4096 Dec 14 16:55 new
drwxr-xr-x 2 root root 4096 Dec 14 16:55 tmp
/var/mail/shared/.Office:
total 24
drwxrwx--- 2 root office 4096 Dec 15 09:53 cur
-rw-r--r-- 1 root root 52 Dec 15 15:53 dovecot-acl
-rw-rw 1 root office0 Dec 15 07:42 dovecot-shared
drwxrwx--- 2 root office 4096 Dec 15 09:53 new
drwxrwx--- 2 root office 4096 Dec 15 09:53 tmp
# id peter
uid=1000(peter) gid=100(users)
groups=51683(office),25783(ssh_users),100(users)
#
Now I log in as peter but I my client (latest TB 2) does not display the
office folder. In the log it claimes that it is not able to open the acl
file what really can NOT be true:
Dec 15 15:56:05 mail dovecot: IMAP(peter): acl vfile: no access to file
/var/mail/shared/.Office/dovecot-acl
I tried:
* su peter: Access no problem!
* ps aux: The process is running as peter
* As you can see I have debugging code in my dovecot-imap-fix.sh which
successfully prints out the content of the ACL file to /tmp/user-peter
I can't image that, it seems as if it is not true.
By the way: As soon as I change the mail_executable to
/usr/local/sbin/dovecot-imap-fix.sh I get this message and have
absolutely no clue why:
# /etc/init.d/dovecot restart
Restarting IMAP/POP3 mail server: dovecotid: dump-capability: No such user
.
#
Which dump-capability? Which user?
Does anybody have an idea what could be wrong here?
Thank you very much,
Luke
Re: [Dovecot] Why dovecot does not want to read my acl file?
Hi Timo, Thank zou for your reply! Timo Sirainen schrieb: On Wed, 2009-12-16 at 00:24 +0900, Lukas Haase wrote: mail_drop_priv_before_exec = no #just to make sure "no" means it starts the process as root as root. I guess you meant to use "yes". I know but I tried both in order to see if it is maybe because of this entry. Anyway, the ACL could not be read in either way... [...] ACL_GROUPS=`groups $USER | tr ' ' ','` export ACL_GROUPS I don't think ACL_GROUPS is supported by Dovecot v1.0. :( :( But nevertheless, let us just forget about the ACL_GROUPS, I would be interested why the ACL file could not be read. Further things I forgot: * In the homedirs the scenario is the same. The one user that has access to the files is the user peter itself and there I got no errors about reading the ACL files * Reading succeeds when I set the directory (.Office) to 755 * For testing I wrote authenticated lrwstiek into the dovecot-acl which means that the problem can not depend on the ACL itself. I just do not understand. The process runs as user peter and complains that it is unable to open the ACL file. But the file is definitively readable for user peter, as I checked with su. Also the error is gone when I set the directory to 755 ... that sounds really strange for me... By the way: As soon as I change the mail_executable to /usr/local/sbin/dovecot-imap-fix.sh I get this message and have absolutely no clue why: # /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecotid: dump-capability: No such user . # Which dump-capability? Which user? It's because at startup Dovecot executes imap mail_executable as "dump-capability" user to find out what IMAP capabilities enabled plugins add. In your script you should probably check that if $USER=dump-capability, don't do anything special. Hmm, I do not fully understand. You can see my whole script in the OP ... there is not done anything special, isnt it? Best regards, Luke
Re: [Dovecot] Why dovecot does not want to read my acl file?
Hi again, I have some additional notes. Lukas Haase wrote: Timo Sirainen schrieb: [...] ACL_GROUPS=`groups $USER | tr ' ' ','` export ACL_GROUPS I don't think ACL_GROUPS is supported by Dovecot v1.0. I removed that part again and instead of using group=office I just enumerate all possible users in the ACL file: anyone user=peter lrwstiek user=user1 lrwstiek user=user2 lrwstiek user=user3 lrwstiek user=user4 lrwstiek Further things I forgot: * In the homedirs the scenario is the same. The one user that has access to the files is the user peter itself and there I got no errors about reading the ACL files * Reading succeeds when I set the directory (.Office) to 755 * For testing I wrote authenticated lrwstiek into the dovecot-acl which means that the problem can not depend on the ACL itself. In the meantime I also tried something else: I added the user "dovecot" to the "office" group: # id dovecot uid=107(dovecot) gid=106(dovecot) groups=51683(office),106(dovecot) Now I can read the file too as user dovecot (su dovecot). But I still get the message: Dec 16 07:53:51 mail dovecot: IMAP(peter): acl vfile: no access to file /var/mail/shared/.Office/dovecot-acl I just do not understand. The process runs as user peter and complains that it is unable to open the ACL file. But the file is definitively readable for user peter, as I checked with su. Also the error is gone when I set the directory to 755 ... that sounds really strange for me... [...] It's because at startup Dovecot executes imap mail_executable as "dump-capability" user to find out what IMAP capabilities enabled plugins add. In your script you should probably check that if $USER=dump-capability, don't do anything special. Hmm, I do not fully understand. You can see my whole script in the OP ... there is not done anything special, isnt it? Thank you, non I understand! The message is because that user does not exist. When I add an if-clause it works. Regards, Luke
Re: [Dovecot] Why dovecot does not want to read my acl file?
Hello, Timo Sirainen wrote: On Wed, 2009-12-16 at 14:36 -0500, Timo Sirainen wrote: drwxrwx--- 5 root office 4096 Dec 15 15:53 .Office Why are your files and directories owned by root, instead of peter? Oh right, kind of stupid question. I already forgot we were talking about shared mailboxes. :) But anyway, the problem has to do with userdb not returning those UNIX groups that you expect. Oh, ok I think there is a point which I do not understand. What has the userdb to do with UNIX rights? As far as I understood from the wiki there are two levels: * UNIX rights. The mailboxes need to just have the correct *UNIX* permission in order to access the files in the needed way (read or write). So IMO this could also be achieved with, say, POSIX ACLs (setfacl) * Internal access system based on the ACLs plugin. I disabled this part temporarily. I am working with UNIX systems for over 10 years now and until now I always debugged permission errors that way. It is the first time that "a user belongs to a group but does not belong to the group" ... what I want to day with that: A user belongs to a group or not, that is part of the operating systems and must not be different through different application, mustn't it? That must be the same over the whole operating system and until now, this was always the case. So far I also do not understand what the userdb has to do with that. The userdb is just for *internal* users of the application (dovecot) and has nothing to do with the access system from the operating system or the system users/groups. > Perhaps you should just set: > > mail_access_groups = office In fact I do not want to do this because the plan is to have an arbitrary amount of groups on the system with different members, permissions and folders. Regards, Luke
Re: [Dovecot] Why dovecot does not want to read my acl file?
Hello Timo, once again thanks for your reply! Timo Sirainen wrote: On Thu, 2009-12-17 at 10:55 +0900, Lukas Haase wrote: [...] * UNIX rights. The mailboxes need to just have the correct *UNIX* permission in order to access the files in the needed way (read or write). So IMO this could also be achieved with, say, POSIX ACLs (setfacl) Right. The issue has to do with what UNIX rights Dovecot sets for the process. In a previous mail you said you used: userdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf Exactly. The question is what fields does LDAP return? Euhm, I use LDAP as passdb and prefetch as user db. Authentication is done with bind. The attributes I get from the LDAP server are (as far as I understand): pass_attrs = uid=user,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid When you're using ldap, Dovecot doesn't directly use /etc/group or NSS equivalent to figure out what groups a users belong to. If you want Dovecot to do that, you need to return system_user= field from userdb. Hmm, ok, I see. I just tried it: # when using authentication via LDAP + prefetch pass_attrs = uid=user,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid,uid=userdb_system_user # when using optional authentication via file + LDAP # I do this that each user can define an optional password # only valid for E-Mail in /etc/dovecot/passwd which is # different from the "important" system password user_attrs = homeDirectory=home,uidNumber=uid,gidNumber=gid,uid=system_user And indeed! It seems to work now :) [...] and has nothing to do with the access system from the operating system or the system users/groups. But you want Dovecot to interact with operating system's users/groups, so you need to tell Dovecot how to do that. But still, IMHO this can not be the scope of an application but the operating system. Each process is a user and a group assigned. And this information is directly in the process structure, i.e. in the *kernel*. And AFAIK the secondary groups are also in this process structure. That means: If I execute a program the *kernel* sets the UID and the GID of the process as well as groups the user belongs to. I still do not understand that a userspace program modifies this kernel structure. This would be the same as starting the process as specified user and ignoring/changing the GID. Regards, Luke
Re: [Dovecot] Why dovecot does not want to read my acl file?
Hi again, Timo Sirainen wrote: On Dec 16, 2009, at 11:40 PM, Lukas Haase wrote: [...] Really? Having uid field used multiple times doesn't work in v1.1+. Maybe v1.0 code worked differently. But at least you should be aware of that if you upgrade Dovecot the above settings will break.. Unfortunately there's currently no easy way to do that. Auh, does not sound good. I think in this case it is not an option. What about the "not easy" ways? I guess it includes at least self compiling? [...] So what happens is that dovecot master process forks a new imap process that starts up as root, then the imap process figures out what permissions it should be running as and executes the appropriate syscalls to get itself to that state. Ah, thank you very much now, I understand. Regards, Luke
BUG: Authentication client sent unknown handshake command
Hi, Some time ago my dovecot started to become BUGgy: Evertime I restart the system, dovecot is started but I cannot login. I see the following information in the logs: Jul 4 04:04:36 mail dovecot: auth: passwd-file(user,127.11.91.218,): no passwd file: /etc/dovecot/imap.passwd Jul 4 04:04:36 mail dovecot: auth: Error: BUG: Authentication client sent unknown handshake command: REQUEST?1183186945?20438?1?a8c7241e7b0778f9f0125da760cd16fa Jul 4 04:04:36 mail dovecot: imap: Error: Authentication server didn't send valid SPID as expected: MECH#011PLAIN#011plaintext Jul 4 04:04:36 mail dovecot: imap: Error: Disconnected from auth server, aborting (client-pid=20438 client-id=1) Jul 4 04:04:36 mail dovecot: imap-login: Internal login failure (pid=20438 id=1) (internal failure, 1 succesful auths): user=, method=PLAIN, rip=127.11.91.218, lip=73.82.101.172, mpid=20439, TLS, session= It does not help to restart the client. But when I then restart the server service dovecot restart it works again. But this is very dangerous because the server might reboot and I might not immideately have the chance to restart dovecot manually. What's going on here? mail:/# uname -a Linux mail 2.6.32-openvz-042stab090.2-amd64 #1 SMP Sat Jun 21 00:22:42 MSK 2014 i686 GNU/Linux mail:/# dovecot --version 2.1.7 Thanks, Luke
Re: BUG: Authentication client sent unknown handshake command
May I gently "push" this? The string "BUG: Authentication client sent unknown handshake command" comes from dovecot (presumably it's in the source code) so I think it shouldn't be too mysterious what's happening here. Thank you, Luke On 2014-07-03 19:10, Lukas Haase wrote: > Hi, > > Some time ago my dovecot started to become BUGgy: Evertime I restart the > system, dovecot is started but I cannot login. I see the following > information in the logs: > > Jul 4 04:04:36 mail dovecot: auth: > passwd-file(user,127.11.91.218,): no passwd file: > /etc/dovecot/imap.passwd > Jul 4 04:04:36 mail dovecot: auth: Error: BUG: Authentication client > sent unknown handshake command: > REQUEST?1183186945?20438?1?a8c7241e7b0778f9f0125da760cd16fa > Jul 4 04:04:36 mail dovecot: imap: Error: Authentication server didn't > send valid SPID as expected: MECH#011PLAIN#011plaintext > Jul 4 04:04:36 mail dovecot: imap: Error: Disconnected from auth > server, aborting (client-pid=20438 client-id=1) > Jul 4 04:04:36 mail dovecot: imap-login: Internal login failure > (pid=20438 id=1) (internal failure, 1 succesful auths): user=, > method=PLAIN, rip=127.11.91.218, lip=73.82.101.172, mpid=20439, TLS, > session= > > It does not help to restart the client. But when I then restart the server > service dovecot restart > it works again. > > But this is very dangerous because the server might reboot and I might > not immideately have the chance to restart dovecot manually. > > What's going on here? > > mail:/# uname -a > Linux mail 2.6.32-openvz-042stab090.2-amd64 #1 SMP Sat Jun 21 00:22:42 > MSK 2014 i686 GNU/Linux > mail:/# dovecot --version > 2.1.7 > > Thanks, > Luke >
Re: BUG: Authentication client sent unknown handshake command
Hi Timo,
Thank you very much. I really appreciate your response!
I have indeed a non-default socket config because I also let exim4
authenticate against it. So I I am not really able to remove the config.
What makes me wonder is that the problem just appeared recently. I think
I have the config running for 2 years now or so.
I provide "doveconf -n" in any case, maybe you can spot an issue?
Thanks, Luke
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-openvz-042stab090.2-amd64 i686 Debian 7.5
auth_mechanisms = plain login
auth_verbose = yes
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:~/Maildir
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave imapflags
namespace {
hidden = yes
inbox = no
list = no
location = maildir:~/Maildir-root
prefix =
separator = .
subscriptions = yes
type = private
}
namespace {
inbox = yes
location = maildir:~/Maildir
prefix = INBOX.
separator = .
subscriptions = yes
type = private
}
namespace {
hidden = no
inbox = no
list = yes
location = maildir:/var/mail/public:INDEX=~/Maildir/public
prefix = Public.
separator = .
subscriptions = no
type = public
}
namespace {
hidden = no
inbox = no
list = yes
location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
prefix = Shared.
separator = .
subscriptions = no
type = public
}
passdb {
args = /etc/dovecot/%Ls.passwd
driver = passwd-file
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf
driver = ldap
}
passdb {
args = failure_show_msg=yes dovecotp
driver = pam
}
plugin {
acl = vfile
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
sieve_extensions = +imapflags
sieve_global_path = /etc/dovecot/default.sieve
}
protocols = sieve imap
service auth {
unix_listener auth-client {
mode = 0666
}
user = root
}
service imap-login {
inet_listener imap {
port = 0
}
}
service imap {
executable = /usr/local/sbin/dovecot-imap-fix
}
ssl_ca = You have misconfigured Dovecot's auth sockets. Providing doveconf -n
> output would help figuring out the problem. Or just delete all the
> auth-related socket settings from config files and it should work.
>
> On 9.7.2014, at 0.03, Lukas Haase wrote:
>
>> May I gently "push" this? The string "BUG: Authentication client
>> sent unknown handshake command" comes from dovecot (presumably it's
>> in the source code) so I think it shouldn't be too mysterious
>> what's happening here.
>>
>> Thank you, Luke
>>
>> On 2014-07-03 19:10, Lukas Haase wrote:
>>> Hi,
>>>
>>> Some time ago my dovecot started to become BUGgy: Evertime I
>>> restart the system, dovecot is started but I cannot login. I see
>>> the following information in the logs:
>>>
>>> Jul 4 04:04:36 mail dovecot: auth:
>>> passwd-file(user,127.11.91.218,): no passwd
>>> file: /etc/dovecot/imap.passwd Jul 4 04:04:36 mail dovecot:
>>> auth: Error: BUG: Authentication client sent unknown handshake
>>> command:
>>> REQUEST?1183186945?20438?1?a8c7241e7b0778f9f0125da760cd16fa Jul
>>> 4 04:04:36 mail dovecot: imap: Error: Authentication server
>>> didn't send valid SPID as expected: MECH#011PLAIN#011plaintext
>>> Jul 4 04:04:36 mail dovecot: imap: Error: Disconnected from
>>> auth server, aborting (client-pid=20438 client-id=1) Jul 4
>>> 04:04:36 mail dovecot: imap-login: Internal login failure
>>> (pid=20438 id=1) (internal failure, 1 succesful auths):
>>> user=, method=PLAIN, rip=127.11.91.218, lip=73.82.101.172,
>>> mpid=20439, TLS, session=
>>>
>>> It does not help to restart the client. But when I then restart
>>> the server service dovecot restart it works again.
>>>
>>> But this is very dangerous because the server might reboot and I
>>> might not immideately have the chance to restart dovecot
>>> manually.
>>>
>>> What's going on here?
>>>
>>> mail:/# uname -a Linux mail 2.6.32-openvz-042stab090.2-amd64 #1
>>> SMP Sat Jun 21 00:22:42 MSK 2014 i686 GNU/Linux mail:/# dovecot
>>> --version 2.1.7
>>>
>>> Thanks, Luke
>>>
>
Re: BUG: Authentication client sent unknown handshake command
Hi,
Just a very gentle reminder :)
I don't see anything I am doing "wrong" in my config ...
Thanks
Luke
On 2014-07-11 17:45, Lukas Haase wrote:
> Hi Timo,
>
> Thank you very much. I really appreciate your response!
>
> I have indeed a non-default socket config because I also let exim4
> authenticate against it. So I I am not really able to remove the config.
>
> What makes me wonder is that the problem just appeared recently. I think
> I have the config running for 2 years now or so.
>
> I provide "doveconf -n" in any case, maybe you can spot an issue?
>
> Thanks, Luke
>
> # 2.1.7: /etc/dovecot/dovecot.conf
> # OS: Linux 2.6.32-openvz-042stab090.2-amd64 i686 Debian 7.5
> auth_mechanisms = plain login
> auth_verbose = yes
> log_timestamp = "%Y-%m-%d %H:%M:%S "
> mail_location = maildir:~/Maildir
> mail_privileged_group = mail
> managesieve_notify_capability = mailto
> managesieve_sieve_capability = fileinto reject envelope
> encoded-character vacation subaddress comparator-i;ascii-numeric
> relational regex imap4flags copy include variables body enotify
> environment mailbox date ihave imapflags
> namespace {
> hidden = yes
> inbox = no
> list = no
> location = maildir:~/Maildir-root
> prefix =
> separator = .
> subscriptions = yes
> type = private
> }
> namespace {
> inbox = yes
> location = maildir:~/Maildir
> prefix = INBOX.
> separator = .
> subscriptions = yes
> type = private
> }
> namespace {
> hidden = no
> inbox = no
> list = yes
> location = maildir:/var/mail/public:INDEX=~/Maildir/public
> prefix = Public.
> separator = .
> subscriptions = no
> type = public
> }
> namespace {
> hidden = no
> inbox = no
> list = yes
> location = maildir:/var/mail/shared:INDEX=~/Maildir/shared:LAYOUT=fs
> prefix = Shared.
> separator = .
> subscriptions = no
> type = public
> }
> passdb {
> args = /etc/dovecot/%Ls.passwd
> driver = passwd-file
> }
> passdb {
> args = /etc/dovecot/dovecot-ldap.conf
> driver = ldap
> }
> passdb {
> args = failure_show_msg=yes dovecotp
> driver = pam
> }
> plugin {
> acl = vfile
> sieve = ~/.dovecot.sieve
> sieve_dir = ~/sieve
> sieve_extensions = +imapflags
> sieve_global_path = /etc/dovecot/default.sieve
> }
> protocols = sieve imap
> service auth {
> unix_listener auth-client {
> mode = 0666
> }
> user = root
> }
> service imap-login {
> inet_listener imap {
> port = 0
> }
> }
> service imap {
> executable = /usr/local/sbin/dovecot-imap-fix
> }
> ssl_ca = ssl_cert = ssl_key = userdb {
> driver = prefetch
> }
> userdb {
> args = /etc/dovecot/dovecot-ldap.conf
> driver = ldap
> }
> protocol imap {
> imap_client_workarounds = tb-extra-mailbox-sep
> mail_max_userip_connections = 15
> mail_plugins = acl
> }
> protocol pop3 {
> pop3_uidl_format = %08Xu%08Xv
> }
> protocol lda {
> hostname = mail.intra.local
> mail_plugins = sieve
> postmaster_address = postmaster@intra.local
> }
>
>
>
> On 2014-07-10 8:23, Timo Sirainen wrote:
>> You have misconfigured Dovecot's auth sockets. Providing doveconf -n
>> output would help figuring out the problem. Or just delete all the
>> auth-related socket settings from config files and it should work.
>>
>> On 9.7.2014, at 0.03, Lukas Haase wrote:
>>
>>> May I gently "push" this? The string "BUG: Authentication client
>>> sent unknown handshake command" comes from dovecot (presumably it's
>>> in the source code) so I think it shouldn't be too mysterious
>>> what's happening here.
>>>
>>> Thank you, Luke
>>>
>>> On 2014-07-03 19:10, Lukas Haase wrote:
>>>> Hi,
>>>>
>>>> Some time ago my dovecot started to become BUGgy: Evertime I
>>>> restart the system, dovecot is started but I cannot login. I see
>>>> the following information in the logs:
>>>>
>>>> Jul 4 04:04:36 mail dovecot: auth:
>>>> passwd-file(user,127.11.91.218,): no passwd
>>>> file: /etc/dovecot/imap.passwd Jul 4 04:04:36 mail dovecot:
>>>> auth: Error: BUG: Authentication client sent unknown handshake
>>>> command:
>>>> REQUEST?1183186945?20438?1?a8c7241e7b0778f9f0125da760cd16fa Jul
>>>> 4 04:04:36 mail dovecot: imap: Error: Authentication server
>>>> didn't send valid SPID as expected: MECH#011PLAIN#011plaintext
>>>> Jul 4 04:04
