Correct “everything else” or specifically List-Id: as that would cover all the lists I am member off
Posts made by MrManor
Rule acting on List-Id:
Migrating from a dovecot/Roundcube mail system I have been using Sieve filters a lot. Now I would like to recreate my filter rules in Kopano
I may be a bit old fashioned but I use a lot af maillist. My experience is that the most reliable way to sort these to folders, is to use some of the hidden headers inserted by the list software like Mailman. In most cases I would use something like
If Mailheader includes .. "List-Id: General KDE discussion"
But using the rule editor I find no way to create filters based on mail header fields other that To:, From: and Subject:. Did I oversee something or is there another way to create filters detecting on header fields?
RE: Clean out one account
Thanks @fbartels, I am just trying to understand the inner working of the LDAP - kopano connection. I makes perfect sense to me, that a unhook should not create a new store for the user. But I was sort of guessing that, kopano-admin --sync would see the account as new, now that there is no longer a Kopano account associated with the LDAP account.
So there must be some information left after the removal, preventing createuser.d to create a new user store (- at next login attempt?)?
Clean out one account
So I was playing around with my FreeIPA connected Kopano, - and messed up content in my test mailstore. So I decíded to zap the content:
sudo kopano-admin --unhook-store klaus sudo kopano-admin --list-orphans sudo kopano-admin --remove-store BLABLA
After the next kopano-admin --sync I thought that I would be able to login to a fresh empty account. But no such luck, i got the MAPI_E_NOT_FOUND error. I first had to do a
kopano-admin --create-store klaus
What pussels me is that when I create en new user in FreeIPA I dont have to manually create a store. So I am wondering. Did I use the wrong procedure to clean out the postbox. And is there possible leftovers from the previus account.
RE: [solved] LDAP authentication method password - encryption?
Just for the record: From a security standpoint you should only allow as few services/daemons as possible access to the password stored in LDAP - encrypted or not. Kopano works perfectly well using LDAP bind - so imho there is no reason to allow Kopano access to the stored password.
Groups from FreeIPA
Playing around to get to know kopano I’v reached quite far in using FreeIPA as LDAP source for user management.
Now I have a small problem regarding group membership. In the example in the manual group membership is based on memberUid, but on in FreeIPA group membership is defined by the attribute member which contains a full dn
dn: cn=somegroup,cn=groups,cn=accounts,dc=int,dc=vink-slott,dc=dk objectClass: ipausergroup objectClass: nestedgroup objectClass: nestedGroup objectClass: posixgroup objectClass: groupofnames objectClass: ipantgroupattrs objectClass: kopano-group objectClass: groupOfNames objectClass: ipaobject objectClass: top cn: somegroup description:: Bla bla bla gidNumber: * ipaNTSecurityIdentifier: * ipaUniqueID: * member: uid=klaus,cn=users,cn=accounts,dc=int,dc=vink-slott,dc=dk memberUid: klaus
The last line (memberUid ) is added manually as a workaround - I cant figure out how to configure ldap.cfg to make kopano read members based on the member attribute.