On February 2, 2010 9:57:12 AM +0100 Steffen Kaiser <skdovecot@smail.inf.fh-brs.de> wrote:

IMHO: If you want to avoid backscatter, you must disable the user in the MTA, in order to reject the message during "rcpt to" command or at least in DATA.

I don't care about backscatter. There's no reason anyone should see significant backscatter these days; it's pretty much a solved problem.

(watermark all outgoing email and look for that watermark on DSN reports)

In any event, for this specific case I do already reject the user "at the gates". But I want to reject internal email for folks that don't know that user account has gone away. I prefer not to do it in the MTA so as to keep the MTA as free from this type of configuration that lingers for years and makes future migrations difficult.

-frank

On Tue, 2010-02-02 at 11:41 -0500, Frank Cusack wrote:

On February 2, 2010 1:29:24 PM +0200 Timo Sirainen <tss@iki.fi> wrote:

...

Logins would fail with "internal login failure". userdb lookup must succeed for imap/pop3 logins too. You could make the deny=yes happen only if %s != 'lda'.

A little more help? I've been looking at the docs and can't figure out how to do this. I do have one constraint: my userdb/passdb is a passwd-file.

You could do:

passdb passwd-file { args = /etc/deny.%s deny = yes }

Then symlink /etc/deny.imap, deny.pop3, etc. to your primary deny file.

Last question on deny userdb, I hope.

Comments in dovecot.conf:

# File contains a list of usernames, one per line

Does that mean the deny passdb has a different format than other passdb's?

-frank

On February 2, 2010 6:56:31 PM +0200 Timo Sirainen <tss@iki.fi> wrote:

passdb passwd-file { args = /etc/deny.%s deny = yes }

This didn't work for me as I expected. Not only did I have to put the user in the deny passdb, I ALSO had to remove them from the regular passdb. So it seems lda just ignores the deny passdb, that is it doesn't consult it at all, as opposed to imap which does consult it.

Is that expected behavior? It's fine by me, since I can still access the disabled user's mailbox from another account that it is shared to.

-frank

On February 2, 2010 10:54:10 PM +0200 Timo Sirainen <tss@iki.fi> wrote:

Oh, right. LDA only looks up userdb.

So when I access these disabled user's maildirs from another user's login, how is imap finding them? Simply by virtue of the acl_shared_dict and mail_location setting? Because moving them to my passwd.deny removes the user from the single userdb, my passwd file. imap still knows them through the passdb (passdb.deny), but not the userdb.

Yep, that seems to be the case. The target (disabled) user need not exist in the userdb at all and dovecot/imap can still find their shared maildir. That's interesting. It seems it could lead to confusion and perhaps this is not desirable? Because what if my userdb overrides the mail_location via proxy or load-balancing hash? imap wouldn't be able to find the correct maildir.

Also at first glance I would think that this means additional security is needed for a distributed (SQL or otherwise) acl_shared_dict but in addition to being in the acl_shared_dict, the dovecot-acl must grant permission to the sharing user, so I think it's ok. (And of course you need good controls on a distributed acl_shared_dict anyway.)

In summary I would suggest that access to shared namespaces need to include a userdb lookup to find the user's mail location, which doesn't seem to be happening now, or at least it seems to be defaulting to the global mail_location setting if the user is not found -- I suggest a failed (not found) userdb lookup should invalidate the shared mailbox.

-frank