On Mon, Nov 08, 1999 at 04:50:32AM +0000, Frederik Lindberg wrote:
> > Hard, but not impossible. How would you envision such hooks?
>
> How about a simplified scheme: All mail with recipient host matching the
> local host is passed to an external program for delivery. The external
> program takes arguments as qmail-local (which is what I'd use).
>
> Default should still be to forward everything.
>
> Thus:
>
> 1. message queued.
> 2a. if -l: compare host name of envelope recipients. If same as local host
> name, deliver locally with qmail-local.
> 2b. deliver multi-recipient message remotely (concurrent with 2a). If -l:
> remove all recipients with host part matching the local host (me).
> 3. Generate one bounce message per local recipient. Generate pre-VERP
> bounce if one of more remote recipients are not accepted.
>
> -l controls local delivery.
Good idea, but basically doubles the complexity of the nullmailer
system. It requires concurrent deliveries, bounce generation, local vs
remote host determination. One of the real big problems (in my mind) is
that it requires that to local/remote protocol agents be able to handle
a subset of the recipient addresses, presumably through a pipe, while
one of the existing agents requires that the message be a file to allow
it to rewind (either that or suck the whole message into core which
could be deadly). I guess one could do this by splitting up the message
queue into a message body queue, and one queue for each destination
class (local, remote-1, remote-2, etc.) but if you need this, why not
use qmail?
--
Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/
