On Sat, 13 Nov 1999, Bruce Guenter wrote:
> > 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?
Was looking for something optimized to low bandwidth settings. QMTP when
fully used it (well, once could add compression). The discussion was
multi-recipient messages, where qmail isn't optimal under these
conditions.
Yes, starting with a qmail queue would be one way. Maybe waiting for
qmail-2.0 is another ;-)
-Sincerely, Fred
Fred Lindberg, Inf. Dis., WashU, St. Louis, MO, USA
