dovecot - Jun 2020 - 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

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.

Joseph Tam <jtam.home at gmail.com>

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