Re: How to use dovecot only as POP3 server / prevent it from creating .imap directories?
On 19.06.2020 00:27, Joseph Tam wrote: > On Wed, 17 Jun 2020, Josef 'Jeff' Sipek wrote: > >> On Tue, Jun 09, 2020 at 12:32:18 +0200, Binarus wrote: >> ... >>> ./mail/inbox >>> ./mail/.imap >>> ./mail/.imap/dovecot-uidvalidity >>> ./mail/.imap/dovecot.list.index.log >>> ./mail/.imap/dovecot-uidvalidity.5edce848 >>> ./mail/.imap/INBOX >>> ./mail/.imap/INBOX/dovecot.index.log >>> ./mail/.imap/INBOX/dovecot.index >>> ./mail/.imap/INBOX/dovecot.index.log.2 >>> ./mail/.imap/INBOX/dovecot.index.cache >> >> The .imap directory isn't really about IMAP. It is sort of a generic >> directory that just happens to have "imap" in the name. The index >> files you >> see are required for various features inside dovecot to work >> properly. Many >> of them are related to performance rather than a specific protocol. > > Spot on. > >> If you don't want the index files to live inside the users' home >> directories, take a look at the INDEX and CONTROL keys in the >> mail_location >> docs: >> >> https://doc.dovecot.org/configuration_manual/mail_location/#format >> >> While that still creates the files, you can move them off to a >> location that >> the users do not see. > > Or you can create in-memory indices, but that is a solution to the wrong > problem. > > By specifically stating in mail_location that ~user holds mailboxes, > you are telling Dovecot an untruth. It's better to tell Dovecot user > mailboxes (other than INBOX) don't exist, rather than to push all the > indices under the carpet. > I just noticed that I haven't said thank you yet. However, the solution I have implemented works very nice since several months now, so I currently don't plan to change or improve anything. Thanks again, and best regards, Binarus
Re: How to use dovecot only as POP3 server / prevent it from creating .imap directories?
On 17.06.2020 17:41, Josef 'Jeff' Sipek wrote: > On Tue, Jun 09, 2020 at 12:32:18 +0200, Binarus wrote: > ... >> ./mail/inbox >> ./mail/.imap >> ./mail/.imap/dovecot-uidvalidity >> ./mail/.imap/dovecot.list.index.log >> ./mail/.imap/dovecot-uidvalidity.5edce848 >> ./mail/.imap/INBOX >> ./mail/.imap/INBOX/dovecot.index.log >> ./mail/.imap/INBOX/dovecot.index >> ./mail/.imap/INBOX/dovecot.index.log.2 >> ./mail/.imap/INBOX/dovecot.index.cache >> >> While there are no .imap subdirectories in other parts of the home >> directories any more (which was the main goal), there are still at least >> three unnecessary files plus one unnecessary directory with four >> unnecessary files left. This is an ugly waste of resources, but it won't >> keep me from going that way. >> >> Obviously, dovecot is not meant to serve only POP3 any more > > The .imap directory isn't really about IMAP. It is sort of a generic > directory that just happens to have "imap" in the name. The index files you > see are required for various features inside dovecot to work properly. Many > of them are related to performance rather than a specific protocol. > Granted, POP3 is such a simple protocol that most of the features don't > apply to a POP3-only server. > > If you don't want the index files to live inside the users' home > directories, take a look at the INDEX and CONTROL keys in the mail_location > docs: > > https://doc.dovecot.org/configuration_manual/mail_location/#format > > While that still creates the files, you can move them off to a location that > the users do not see. > > Jeff. > A little bit late, but just wanted to thank you for your explanation. By the way, that solution is playing very well in practice - no reason to change or improve something. Thanks again, and best regards, Binarus
Re: How to use dovecot only as POP3 server / prevent it from creating .imap directories?
On 08.06.2020 07:41, Joseph Tam wrote: > On Sun, 7 Jun 2020, Binarus wrote: > >> So how exactly do I have to alter the configuration to implement your >> suggestion, i.e. to make dovecot look only at the mbox file and to >> prevent the creation of unnecessary directories? > > Maybe try > > mail_location = mbox:/empty/dir:INBOX=~/inbox > > Not sure whether owner=rootZ:root, mode=555 will work, but those > permissions would be the safest. > Thank you very much for your suggestion. Actually, I already had tried that, but that was only for testing, and I was hoping to avoid it. Having said this: That suggestion does not solve the problem completely, but reduces the negative impact so much that I can live with it. I had tried mail_location = mbox:~/mail:INBOX=~/mail/inbox With that, dovecot still created an .imap subdirectory, but only within the mail subdirectory in every user's home directory. The layout was the following (starting in an arbitrary user's home directory, showing only the contents of the mail subdirectory): ./mail/inbox ./mail/.imap ./mail/.imap/dovecot-uidvalidity ./mail/.imap/dovecot.list.index.log ./mail/.imap/dovecot-uidvalidity.5edce848 ./mail/.imap/INBOX ./mail/.imap/INBOX/dovecot.index.log ./mail/.imap/INBOX/dovecot.index ./mail/.imap/INBOX/dovecot.index.log.2 ./mail/.imap/INBOX/dovecot.index.cache While there are no .imap subdirectories in other parts of the home directories any more (which was the main goal), there are still at least three unnecessary files plus one unnecessary directory with four unnecessary files left. This is an ugly waste of resources, but it won't keep me from going that way. Obviously, dovecot is not meant to serve only POP3 any more (it used to work in previous versions, where it didn't create .imap directories if IMAP was disabled, if I remember correctly), but I don't know an alternative. All other POP3 servers which are currently maintained which I am aware of also have included an IMAP part, so I can probably expect the same problems as with dovecot. Since I currently have no motivation to learn another server software's configuration just to see that this got me nowhere, I'll just stick with the solution outlined above and hope that the POP3 part of dovecot will not be given up in the next versions, and that dovecot does not go wild and start to create more and more directories or files in unforeseeable manner. The disadvantage of the solution above was that I had to reconfigure the MTA (in this case, sendmail) to deliver inbound messages to ~/mail/inbox instead of ~/inbox, which is another why I didn't implement this solution immediately. At least, this was quite easy. Thank you very much again! Regards, Binarus
Re: How to use dovecot only as POP3 server / prevent it from creating .imap directories?
On 07.06.2020 17:56, Hendrik Boom wrote: > On Sun, Jun 07, 2020 at 08:44:51AM +0200, Binarus wrote: >> Dear all, >> >> on our mail server, I let sendmail deliver incoming messages to a file in >> mbox format called "inbox" in each user's home directory. Now I would like >> to use dovecot as POP3 server so that users can let their MUA download their >> messages via POP3. I do not want to use any IMAP functionality. >> >> The POP3 part works with the configuration shown below, but nevertheless >> there is a problem which is a show stopper: >> >> Although I think I have turned off IMAP (e.g. no IMAP listener), dovecot >> still creates .imap directories and does so in a very weird way. It creates >> one .imap subdirectory in every subdirectory of each user's home directory, >> and for every file in each user's home directory creates an additional >> subdirectory with the same name in its .imap directories. It does this >> recursively, and 1000 files in a user's home directory would mean 1000 >> additional subdirectories. >> >> Of course, I can't live with that. I know that the dovecot documentation >> discourages using the home directory as mail location, but in my case this >> should not be a problem at all if IMAP is not used. I have played around >> with dovecot for several days, but could not solve that problem. >> >> So how can I turn off IMAP completely and prevent dovecot from creating any >> .imap directories or IMAP related files? > > I suppose you'd be OK with having IMAP but having it look *only* at the > designated mbox file. > > That would be something I could use. Thank you very much for your comment. You are completely right - I could very well live with that solution. However, I have researched for many hours before posting here, but I could not find out how to achieve this. As I have described in my first post, dovecot created an .imap subdirectory in each directory which existed, and created one subdirectory (within the .imap directory) for each file which existed, and it did so recursively. Whatever portions in the configuration files I commented out, and whatever service I disabled by other means (e.g. by giving Port = 0), I could not prevent dovecot from messing up users' home directories completely, i.e. I could not make it use only the mbox file and leave the directories as-is otherwise (possibly adding a file or two for management and housekeeping). This is extremely weird and not acceptable; imagine 10,000 directories being created for nothing solely because there are 10,000 files. Plus, it is a behaviour which previous versions did not show (I have pulled over the configuration from another system running Debian jessie, where the problem did not arise). I still can't understand why it does IMAP things at all, given that I have protocols = " pop3". So how exactly do I have to alter the configuration to implement your suggestion, i.e. to make dovecot look only at the mbox file and to prevent the creation of unnecessary directories? Thank you very much again, Binarus
How to use dovecot only as POP3 server / prevent it from creating .imap directories?
Dear all,
on our mail server, I let sendmail deliver incoming messages to a file in mbox
format called "inbox" in each user's home directory. Now I would like to use
dovecot as POP3 server so that users can let their MUA download their messages
via POP3. I do not want to use any IMAP functionality.
The POP3 part works with the configuration shown below, but nevertheless there
is a problem which is a show stopper:
Although I think I have turned off IMAP (e.g. no IMAP listener), dovecot still
creates .imap directories and does so in a very weird way. It creates one .imap
subdirectory in every subdirectory of each user's home directory, and for every
file in each user's home directory creates an additional subdirectory with the
same name in its .imap directories. It does this recursively, and 1000 files in
a user's home directory would mean 1000 additional subdirectories.
Of course, I can't live with that. I know that the dovecot documentation
discourages using the home directory as mail location, but in my case this
should not be a problem at all if IMAP is not used. I have played around with
dovecot for several days, but could not solve that problem.
So how can I turn off IMAP completely and prevent dovecot from creating any
.imap directories or IMAP related files?
This happens with dovecot 2.3.4.1 (f79e8e7e4) on Debian buster (with all
updates applied).
My configuration (doveconf -n) is (the configuration is complete - I don't use
SQL or LDAP):
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-9-amd64 x86_64 Debian 10.4
# Hostname: host.example.com
listen = aaa.bbb.ccc.ddd
mail_location = mbox:~:INBOX=~/inbox
mail_privileged_group = mail
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
pop3_lock_session = yes
protocols = " pop3"
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
port = 0
}
}
service pop3-login {
inet_listener pop3 {
port = 0
}
inet_listener pop3s {
port = 995
ssl = yes
}
}
ssl = required
ssl_cert =
Re: [Dovecot] 2.0.12 (fa2e92526716): Deleting mails and folders from public namespaces
On 26.05.2011 08:38, Willie Gillespie wrote: > On 5/25/2011 5:12 AM, Binarus wrote: >> It seems that the problems come from the fact that deletion is done by >> renaming. I am not in IMAP but suppose that there is some rename command >> which is used by email clients in such cases. Maybe there is also a >> delete command which dovecot is "emulating" by doing a rename - I really >> don't know... > > Just a little correction here: Deletion is NOT done by renaming. > Deletion of folders is done with a DELETE command which gets rid of it > entirely. What your mail clients are doing is renaming the folder, > which is done with a RENAME command. > > For example, if "SomeFolder" is deleted then your mail client is doing: > RENAME "SomeFolder" "Trash.SomeFolder" > which effectively just moves the folder as a subfolder of Trash. > I suspected something like that, and you can see it from the fact that some IMAP clients indeed are able to do the moving (obviously by internally emulating it by the copy-move-delete method). That was the reason why I was proposing the server-side copy-move-delete implementation for such cases. I think it is the correct behaviour for clients to use renaming instead of more inefficient operations, but I also think that the server should try to obey the user and should emulate renaming by the copy-move-delete method if a "pure" renaming is not possible for some reason. Obviously, Dovecot incorporates code for creating new folders in any namespace, for moving messages regardless of namespaces and for deleting (empty?) folders in any namespace (we can do all these actions manually provided the ACLs allow). Therefore, emulating renaming by copy-move-delete in problematic cases might be possible without pain. I know that it is not a completely "clean" solution; on the other hand, it would be reasonable and immediately understandable by users. The purists among us might be happy if there was a configuration directive to enable or disable such behaviour. What do you think about that? > > Timo, you said >> Talking only about ACLs I guess it would be ok to allow renaming from >> public namespace to a private namespace. Renaming one of your own >> private mailboxes to public namespace is a bit trickier, because the >> default ACL is "no permissions". So when renaming, a new explicit ACL >> should be added to the user who did the renaming, because otherwise >> user could no longer access that mailbox at all. Still doable I guess. > > I don't think any ACL should be added automatically in this case. If > they set their trash folder to be in a public/shared namespace for which > they have only CREATE permissions, then I think that's their fault and > the admins problem... not Dovecot's. > I agree with Willie. Once again, look at the analogy: what does a user expect to happen when he tries to move a folder from his private space to public space? He expects - a new folder (with subfolder structure) to be created in public, every folder having the same name as it's counterpart in private - all messages to be moved from the folder structure in private to the folder structure in public - the folder structure in private to be deleted These steps could be done by hand, and thus, the behaviour, ACL handling and error messages should exactly be the same as when doing the steps by hand. For example, when a user creates a folder in public by hand, he eventually will not be able to access that folder, depending of the ACLs of the parent folder. This is normal and expected, so there is no reason to handle it in special way when moving (renaming?) folders. By the way, if I got it right, the same problem might appear if the user was copying folders within the same public namespace. What if a user copies a folder (in public) to another parent folder (also in public) where the user only has create rights? I don't know for sure, but I think the ACL won't be copied in this case, so the user might not have access to the new folder. But I may be wrong here, and I am unsure what would happen if the folder would be moved instead of copied; I think if moving is done by renaming, the ACL would be moved as well, so there should not be any problem. We also could look at it the other way: Logically, from my (naive) point of view, any folder in a user's private namespace is connected with a standard ACL; however, this ACL can't be altered by users (or the admin), has only one entry (respective user has full access) and is created / kept automatically by the server. In this model, renaming from private to public would be the same as renaming from public to public and thus would solve the problems. I don't know how difficult it would be to make Dovecot look at th
Re: [Dovecot] problems with debian 5.0 and thunderbird
On 25.05.2011 03:29, Steven Jones wrote: > Hi, > > Does anyone have a setup guide for Thunderbird and Dovecot on Debian please? > > Dovecot is 1.0.15 > > I have Dovecot running listening on 143 and I can telnet from the XP guest > but Thunderbird cant or wont talk to it. Did I get this right: You can telnet to port 143 of the server? > I have taken the # off listen and I get a telnet reply, no firewall is > configured > > Ive set thunderbird up lots so I suspect its not Thunderbird but a dovecot > config I have wrong. > > > regards > Perhaps Thunderbird wants to talk via SSL (Port 993)? If that is not the case, the common recommendation is to look into the logs at the server side (/var/log/syslog, /var/log/mail and so on). For further details and how to increase the debug level, look here: http://wiki1.dovecot.org/Logging If that doesn't help, install Thunderbird's addon accountex, export your account settings to a file (don't forget to clear your logins and passwords before doing so) and provide them to the community so that somebody could take a look. Regards, Peter
Re: [Dovecot] 2.0.12 (fa2e92526716): Deleting mails and folders from public namespaces
On 26.04.2011 23:25, Timo Sirainen wrote: > On 26.4.2011, at 23.48, Binarus wrote: > >> But whenever a user tries to delete a folder from the public namespace, >> dovecot gives the following error: "Renaming not supported across >> non-private namespaces". > .. >> Furthermore, I haven't completely understood the reason for the >> different behaviour of folders in the public namespace and a single >> message therein. > > > Talking only about ACLs I guess it would be ok to allow renaming from public > namespace to a private namespace. Renaming one of your own private mailboxes > to public namespace is a bit trickier, because the default ACL is "no > permissions". So when renaming, a new explicit ACL should be added to the > user who did the renaming, because otherwise user could no longer access that > mailbox at all. Still doable I guess. > > Although it is possible to give user permission to delete foo/bar but not > give permission to create children to foo. Then if user renames foo/bar to > Trash/foo/bar, it's not possible to rename it back. Probably not a real > problem. > > Renaming from/to shared namespace needs to update the shared users acl dict. > > Quota also needs to be updated. I'm not sure if lazy-expunge has any trouble > with this. Multi-dbox backend can't do a fast rename at all, because it would > have to physically copy all of the messages from one mdbox storage to another > mdbox storage. Maybe there are other problems I can't remember now. > > So looks like it should be possible to do all this, with the exception of > adding an inefficiency to mdbox, but it's some work.. Thank you very much for your answer which shows that -as always- problems are more complicated than they seem first. Nevertheless, I don't want to give up, have a few thoughts and just would like to know I am right and what others are thinking: - I have used Cyrus 2.2 for a long time before I switched to Dovecot; in Cyrus 2.2, I did not have the problem. So I am wondering how the problem has been solved there. - Obviously, users can create new folders in public namespace (if the ACL allows) and their private mailboxes; furthermore, they can delete folders from public namespace and private mailboxes (if the ACL allows) (I am talking of a pure delete here, not of moving the folder to Trash). Thus, we could emulate moving folders between any namespaces (for example, from public namespace to private Trash) by first copying them to the new location and then deleting them from the original location. Let's assume we have a folder in a public namespace and are allowed to do everything with it. Then, we could delete this folder (this time, I am meaning moving it to private Trash) by doing the following steps manually: a) Create a new folder with the same name in Trash (which may be in the private mailbox); recursively repeat this with all subfolders. b) Move all messages from the folder in the public namespace to the folder in Trash; recursively repeat this with all subfolders (remark: moving messages does not seem to cause problems, as opposed to moving folders). c) Recursively delete the folder with all subfolders (which are completely empty now) from the public namespace (of course, this again is a "real" delete). I have tested this procedure with multiple IMAP clients against Dovecot, and there were no problems. Automation of the procedure would not be expected to lead to problems, would it?. - From a user's point of view, it is not important how messages get deleted or moved behind the scenes. A users which wants his stuff moved doesn't care if moving is accomplished by a rename or by another mechanism. In fact, he doesn't even know about renaming. He just wants the stuff which was in some folder to show up in some other folder. It seems that the problems come from the fact that deletion is done by renaming. I am not in IMAP but suppose that there is some rename command which is used by email clients in such cases. Maybe there is also a delete command which dovecot is "emulating" by doing a rename - I really don't know... So why not implement the rename / delete command in the way that I have described above? I know that a rename probably (for example on a file system or Dovecot's backends) is by far much more efficient than the copy-move-delete mechanism, but we could do the following: If the renaming is problematic due to reasons Timo has mentioned in his first reply, then emulate the renaming by the copy-move-delete mechanism; if renaming would be no problem, then use the normal method (the method which is already implemented). The inefficiency of the copy-move-delete mechanism would be no argument against using it: the alternative would be having the user to do thes
[Dovecot] 2.0.12 (fa2e92526716): Deleting mails and folders from public namespaces
Hello,
we basically run a dovecot imap setup where users' mailboxes are in
private namespaces (as usual), but there is a public namespace with
several thousand deeply nested folders also.
The client we use is Thunderbird 3. The public namespace shows up in
each user's account at the top level (i.e. same level as Inbox, Sent and
so on), and users can make new subfolders in the public namespace, copy
mails to it and so on. So, our setup basically works.
But whenever a user tries to delete a folder from the public namespace,
dovecot gives the following error: "Renaming not supported across
non-private namespaces".
I think I have a grasp why this happens (Thunderbird tries to move the
folder from the public namespace into the trash folder (private
namespace) of the user who does the deletion), and I also have read
Timo's statement that he does not plan to support such renaming due to
big problems he is seeing with it.
Nevertheless, since deleting a folder from a public archive is not a too
uncommon thing, I wanted to ask how other people have solved that.
It came to my mind to configure Thunderbird to immediately delete
folders and messages (instead of moving them to trash folder). I have
tested that, and it worked, but is somehow dangerous and unsatisfying.
Furthermore, I haven't completely understood the reason for the
different behaviour of folders in the public namespace and a single
message therein.
If I configure Thunderbird to use the trash folder, users can delete
messages from the public namespace, i.e. Thunderbird can move messages
from the public namespace to the private trash folder of the respective
account.
This is obviously not true for folders (even if they are empty). What's
the difference between an empty folder and a single message in this
respect? Is it really the ACL thing which makes folders so difficult to
handle opposed to single messages?
Thank you very much for any ideas!
Regards,
Peter
dovecot -n:
# 2.0.12 (fa2e92526716): /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.1
auth_verbose = yes
auth_verbose_passwords = sha1
first_valid_uid = 103
maildir_copy_with_hardlinks = no
namespace {
hidden = no
inbox = yes
list = yes
location =
maildir:/home/vmail/content/users/%u:INDEX=/home/vmail/index/users/%u
prefix =
separator = /
subscriptions = yes
type = private
}
namespace {
hidden = no
inbox = no
list = yes
location =
maildir:/home/vmail/content/archive:INDEX=/home/vmail/index/archive
prefix = Archive/
separator = /
subscriptions = yes
type = public
}
passdb {
args = scheme=SSHA username_format=%u /etc/dovecot/users
driver = passwd-file
}
plugin {
acl = vfile
}
protocols = " imap"
service auth {
user = root
}
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
address = 192.168.20.140
port = 993
ssl = yes
}
}
ssl_cert =
