Mail Forwarding broken

[Christian Hügel]

Am 15-01-2014 21:48, schrieb Daniel Hoffend:
> I'll try to summarize the mail forwarding setup. It's important to pay
> attenation to the little details and even more on the order of the
> configuration.
> 
> 1) Correct User Type
> 
> Check that your user_type "Mail Forwarding" or whatever is called only
> contains the following object classes
> * inetOrgPerson
> * mailRecipient
> * organizationalPerson
> * person
> * top
> 
> It's important that kolabInetOrgPerson is not enabled!
> The following 2 attributes are important
> * mail
> * mailForwardingAddress
> 
> The mail attribute "can" be of the field-type: "list" to allow
> multiple mail addresses forwarded to the mailForwardingAddress
> 
> 
> 2) Check the filter for (not) creating new users (aka imap folders)
> 
> root at kolab:~# grep kolab_user_filter /etc/kolab/kolab.conf
> kolab_user_filter = (objectclass=kolabinetorgperson)
> This filter makes sure that kolabd only creates imap folders for users
> that match the given filter. When we now create mail forwarding
> entries they don't contain the kolabInetOrgPerson objectclass
> therefore there's no imap folder created (which is the intention).
> 
> 
> 3) Check the order of postfix:virtual_alias_maps
> 
> Pay attention to the order (cause the first match will be the
> destination). I only list the most important ones.
> 
> * /etc/postfix/ldap/virtual_alias_maps.cf
> * /etc/postfix/ldap/virtual_alias_maps_mailforwarding.cf
> * /etc/postfix/ldap/virtual_alias_maps_catchall.cf
> 
> My personal list is a bit longer (mostly not used, but good for
> explanation and to be complete).
> virtual_alias_maps > mailforwarding > sharedfolders > distgroups >
> dynamic_distgroups > catchall
> 
> Let's take a closer look at the ldap filter and result attribute in
> the virtual alias maps
> 
> # virtual_alias_maps.cf
> 
> query_filter = 
> (&(|(mail=%s)(alias=%s))(objectclass=kolabinetorgperson))
> result_attribute = mail
> This will find all kolab mail users (those with folders) that matches
> mail or alias address. If it founds a match it will return the mail
> address. (then local_recipient table and transport are coming into
> affect). If **no match** could be found, postfix will proceed with the
> next given configuration virtual_alias_maps which in our case is
> mailforwarding.
> 
> # virtual_alias_maps_mailforwarding.cf
> 
> query_filter = (&(mail=%s)(objectclass=inetorgperson))
> result_attribute = mailForwardingAddress
> 
> Now postfix is searching for mail address that have the objectclass
> inetorgperson. It's important that this config comes after the one
> with kolabinetperson, cause all kolab users have inetorgperson as
> well! Postfix will then return the mailForwardingAddress attribute to
> the main process. If it's a local address it will still try to deliver
> it, but when it's an external address postfix will directly push it
> out again.
> 
> # virtual_alias_maps_catchall.cf
> 
> query_filter = (&(alias=catchall@%d)(objectclass=kolabinetorgperson))
> result_attribute = mail
> 
> If one of the previous filter rules hasn't matched yet the filter will
> search for any use that have the alias "catchall@<domain>" and returns
> the mail attribute for local delivery.
> 
> --
> 
> that's it. I hope this explains the postfix+ldap process pretty much.
> 
> 
> 4) Appendix (to be complete):
> 
> But what if you want to have a real kolab account to take benefit of
> the kolab services or the webmail but still forward all incoming
> mails?
> 
> Well then you just have to create a real kolab user account, log into
> the webmail interface go to options, then filter an create a rule the
> will either forward all mails or send a copy to your remote address.
> 
> 
> --
> Kind Regards
> Daniel Hoffend
> 

Hi Daniel,

thank you so much for your detailed explanation, it helped me a lot.

Kind regards,

Christian