Re: Virtual delivery agent

(no email)
Date: Thu Aug 01 2002 - 16:47:01 EDT


On Thu, 1 Aug 2002, Wietse Venema wrote:

> What is making it hard to use the virtual delivery agent, apart
> from the inability to execute commands, which is unlikely to ever
> happen?
>

Now that catchall mailboxes are working, the main missing feature is:

- Support for "aliases" expanded in the VDA rather than by "cleanup" via
  "virtual_maps". The virtual expansion in "cleanup" has weaker loop
  detection and is compile-time limited to 1000 recipients, so it is not
  possible to support large lists.

  This can be faked by using "virtual_maps" to rewrite map to an aliased
  "local" address, with the expansion of the alias containing the required
  virtual mailboxes.

There are additional features needed when the access method is Courier
IMAP, but in this case "maildrop" is the better bet for now. Should
Postfix have a better than "maildrop" VDA, or should "maildrop" be
enhanced to be a better VDA for Postfix?

- Support for SIEVE or similar for auto-filing into subfolders on delivery.

- Support for user+extension when auto-filing (currently extension is
  ignored).

- Support for "userdb" for interoperability with Courier IMAP.

I don't use "maildrop" but it appears that it has a richer but
still reasonable feature set. The main complaints appear to be poor
logging and some issues with exit codes (I have not seen a good
explanation of this). If Postfix bundled a VDA that had a
feature matrix similar to "maildrop", and was more robust, that should be
enough I think.

> The virtual delivery agent was added several years after the initial
> design, and it does not fit perfectly. I would like to make it a
> realistic option to do this:
>
> local_transport = virtual
> mydestination = $virtual_mailbox_maps
>
> or something morally equivalent.
>

Making the virtual_mailbox_domains literally both "local" and "virtual" is
a little strange. They become subject to both Postfix-style
recipient validation via virtual_mailbox_maps and local recipient
validation via local_recipient_maps. This would perhaps be confusing.

You did of course say "morally equivalent", so perhaps you are considering
my proposal of:

        virtual_transport = virtual
        virtual_mailbox_maps = ...

with domains that are keys in virtual_mailbox_maps resolving to
$virtual_transport barring any specific transport table overrides.

-- 
	Viktor.
-
To unsubscribe, send mail to  with content
(not subject): unsubscribe postfix-users







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD