On Thu, Jan 28, 1999 at 08:20:32PM -0600, Mate Wierdl wrote:
> On Thu, Jan 28, 1999 at 05:42:03PM -0500, Chris Johnson wrote:
> > Now that I think of it, QMQP won't give your users the instant gratification
> > they're looking for (i.e. not having to wait for the entire message to be
> > transferred over the phone line). Since with mini-qmail there's no local queue,
> > they're still going to have to wait until the message is queued at the remote
> > end of the phone line before their MUA cuts them loose. If you want mail queued
> > locally, you're back to where you started.
>
> Admittedly, I do not understand this well, but I thought that the following
> happens: when the connection with the ISP is established, the mail gets sent
> by the MUA. The messages are given to qmqp which then connects to the ISPs
> qmqpd, and then they get queued at the ISP's box.
>
> So a message with multiple recipients does not get split on the local
> machine, and as a single message goes through the serial line.
But since the queue is at the remote end of the phone line, the user's MUA will
have to wait until the message has been completely transferred before it
reports success. Furthermore, if the phone line is disconnected for the moment,
the user's MUA will report a (temporary) failure, and he'll have to try again
later.
What would be nice is a mini-qmail setup with local queueing--mail would be
transferred quickly from the user's MUA to the local SMTP server, queued there
for the moment, and then transferred to the remote, well connected, host via
QMQP. I haven't thought this all the way through, and there are probably things
wrong with this model, but a setup that involved local queueing and a smart
host that understands QMQP (and VERPifying) would be well suited for
hosts/networks connected to the Internet by slow and/or non-permanent links.
Chris
