From: (no name) (no email)
Date: Thu Feb 26 2004 - 10:39:47 EST
On Thu, 26 Feb 2004, Magnus Bäck wrote:
> Given this LDAP example for virtual mailboxes,
>
> mail:
> mailMessageStore: /home/vmail/jdoe
> mailAlternateAddress:
>
> is there a reason to setup virtual_alias_maps to translate from
> to instead of just using a single
> LDAP filter such as (|(mail=%s)(mailAlternateAddress=%s)) (with
> mailMessageStore as result_attribute) for virtual_mailbox_maps?
>
> As I see it, the only difference will be that the VDA (which probably
> will be maildrop) without virtual_alias_maps will be fed with any of a
> user's aliases as the recipient address, and not just the canonical
> recipient address found in the mail attribute.
>
> So, although it will *work* without virtual_alias_maps, would it be
> stupid for some reason?
>
Unless you care to normalize the "<queue_id>: to=<rcpt>" lines in the log,
there is no reason to rewrite the recipient if the delivery agent can deal
with equivalent database keys. In fact a more complete schema would be:
mail: Single valued
mailAlternateAddress: Optional multi-valued
mailAlternateAddress:
mailForwardingAddress: Optional multi-valued
mailMessageStore: /some/path Optional single-valued
The virtual table is {mail|mailAlternateAddress} -> mailForwardingAddress.
The vmbox table is {m|mAA} -> mFA.
This allows for redirection to a forwarding address for selected users,
and delivery to virtual mailboxes for others.
I duplicate the "mail" value into the mailAlternateAddress (mAA
multi-value) list, and only query on mailAlternateAddress. The "mail"
attribute is used for canonical mapping (mAA -> mail) (arguably this is
masquerading) and by LDAP enabled User Agents for mapping "cn" or "uid" ->
"mail".
-- Viktor.
|
|
|