howto make catchall mailbox using kolab addressbook: bug or feature ?

[Bernhard Reiter]

Am Montag, 7. August 2006 11:24 schrieb Alain Spineux:
> I defined the following entries in my kolab address book
>
> mail: catchall+domain1 at mydomain.com
> alias: @domain1.com
>
> another entries
>
> mail: catchall+domain2 at mydomain.com
> alias: @domain2.com
>
> the first entry make every email for "@domain1.com"  going to subfolder
> domain1 in mailbox catchall at mydomain.com
> (dont forget to create mailbox catchall at mydomain.com, create subfolder
> domain1 and give access "p anyone" to the folder)
> The second one do the same for domain2
>
> FYI  '+'  is and email extended notation, that is used by cyrusimap to
> deliver email into a subfolder. This is called "plus addressing"
>
> I don't know if someone thought about that before me or if I am the first
> one  :-)
>
> I first setup a more standard catchall using
> /kolab/etc/kolab/templates/virtual.template
> entries:
> (dont forget the /kolab/sbin/kolabconf to regenerate config files after
> modifying templates)
>
> > @mydomain.com catchall at mydomain.com
> > foo at mydomain.com catchall+foo at mydomain.com
> > bar at mydomain.com catchall+bar at mydomain.com
>
> to redirect everything @ mydomain.com into mailbox catchall and some email
> directly into subfolder :-)
> I got the idea to try to move
>
> > foo at mydomain.com catchall+foo at mydomain.com
> > bar at mydomain.com catchall+bar at mydomain.com
>
> into the addressbook to make these entries easier to manage, and not always
> edit the virtual.template file.
> It was working
> Finally I moved  the "catchall" into the addressbook
>
> >@ mydomain.com catchall+unexistingfolder at mydomain.com
>
> The only drawback I saw, is because I cannot define another "mail" or
> "alias" catchall at mydomain.com inside the ldap database to keep unicity, I
> cannot redirect emails into catchall mailbox and must use the plus
> addressing and then make the delivery into a subfolder.
> BUT if the subfolder dont exist the mail will go to parent folder, this is
> why I use unexistingfolder
>
> Is-it a bug or a feature ?

It seems to be a bug to me.
Probably the search filter in ldapvirtual.cf
needs to be narrowed to exclude cn=external.

Can you file an issue with our tracker? That would be nice.


> I dont thing this is a good idea to put "system" mapping into the address
> book. This is useless for the end user.
> BUT I have this feature and want to keep it !!!

:)
We at least could add a feature request for catch-all addresses,
though I believe that going the regular way over virtual.template
should be sufficient as this is not a setting you need to change everyday.
The webinterface mainly is for regular common tasks,
for other it can easily more complicated then doing good.

> I good idea to separate system mapping entries from normal addressbook
> entries is to add a ldap field for normal address book entries and add this
> field as a selector inside ldapvirtual.cf file.

Addressbook entries should be seperated by haning below cn=external.

> Maybe this could be also a security hole ? 

Probably not as only people with higher rights can manipulate such entries.

> And modifying the ldap filter to 
> only use entries of class kolabInetOrgPerson resolve it.

The webinterface will create as
objectClass: kolabInetOrgPerson
as well.

> And how does kolabgui and kolabd react when they meet mail of the form "
> catchall+unexistingfolder at asxnet.loc" does it try create a cyrus mailbox
> for catchall+unexistingfolder ?
> Is-it smart and just try to create a 
> catchall mailbox ? Or does this case was not thought before ?

I think Cyrus will reject the email and not create a mailbox.

> Any comment ?

Thanks for spotting this, it is indeed an interesting use of the features.

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1310 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20060808/62173ac2/attachment.p7s>