On Mon, 8 Nov 1999 10:36:38 +1300, Jason Haar wrote:
>We have a 64Kb Frame Relay link with burst to 128Kb. We have users here
>sending their current favourite 3 Mb MP3 file to 30 friends - effectively
[...]
>Fact: Sendmail would have used less bandwidth in this _specific_ situation.
>In general - in our situation - sendmail and qmail are identical in
>performance.
Probably, but in reality the difference would be small, unless the
friends are very clustered.
>Fact: I don't care. Even with this issue - I still prefer qmail. This is a
>issue I (and therefore those I work for) am willing to live with...
You could purchase QMTP/QMQP service for a well-connected ISP. We do
some mailing lists that way: The customer uses QMQP for the mailing
list traffic, SMTP for everything else. Fast local delivery, while the
central server shoves out list messages to 100,000 subscribers.
It shoudn't be too hard to set up qmail to at the qmail-send level (or
even qmail-queue) choose between delivery models, e.g. messages > x
bytes and/or > y recipients are handled by a separate queue or by
QMQP/QMTP to an external server. This way, your 3Mb file would be sent
exactly once with a massive saving in [local] bandwidth over sendmail,
whereas for small messages with few recipients you get qmail
performance. I'm hoping for 2.0 to do this to be more friendly to
narrow links ;-)
You could also look into QMQP over your link. I found that the
qmail-qmqpd write timeout of 60 s is too short in this situation. Any
problem at that stage, and the server will have received the message,
by the client won't know, so send it again. I know one setup where QMQP
is used from Brasil to St. Louis, AFAIK still successfully. Local
queuing would be nice. AFAIK, Bruce Guenter's nullmailer does this and
can use QMTP to the smarthosts.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
