[solved] Identifying disabled users and send-only accounts

[irreleph4nt]

Hi,

I am currently setting up postfix, following this tutorial (https://thomas-leister.de/en/mailserver-debian-stretch/), substituting Dovecot with the relevant dagent config as described in Kopano’s admin manual.

What I am looking for is a way to identify two sorts of users in the kopano database, so that I do not have to entertain a seperate postfix db for it:

1. Users that have been deactivated
2. Users that are send-only

Regarding 1)
Kopano’s objectproperty table has a propname “ishidden”. Does that denote a user that has been “deleted” / deactivated (I am not sure how kopano actually handles this)?

Regarding 2)
The idea in the tutorial that I linked above is to have accounts that can send emails, like “no-reply” or “status updates”, but can not receive emails and hence get bounced by postfix. Does kopano hold a set of properties by which such accounts can be identified / constructed? I’d be happy to build SQL queries myself, just need a kick-start on where to look, please.

Thank you as always and keep up the good work! :)

[fbartels]

Hi @irreleph4nt,

@irreleph4nt said in Identifying disabled users and send-only accounts:

Does that denote a user that has been “deleted” / deactivated

no this hidden flag has another purpose (which is also in its name). Its purpose is to hide a user from the gab, for example if a ceo has a mailbox private and not everyone in the company should be able to see this mailbox.

@irreleph4nt said in Identifying disabled users and send-only accounts:

Does kopano hold a set of properties by which such accounts can be identified / constructed?

If you have an account that is supposed to be used by external services for sending, but should not be able to receive mails I would rather recommend to manage this account outside of Kopano (as you pointed out it does not need a mailbox in Kopano and is therefore not required to be a Kopano user).

In general that sounds like you’re using the db backend in Kopano. The general recommendation is to rather use the ldap backend. here you also have more possibilities on filtering since you’re free to add additional information to your ldap tree without the need to rely in properties that exist within the Kopano database.

[irreleph4nt]

@fbartels

Hi Felix,

thank you for the quick turnaround on this and your recommendations in light of what I want to achieve. I’ll definitely check out the LDAP route! :)

Kind regards.