On Mon, 9 Aug 1999, Cris Daniluk wrote:
> I found out the problem and its interesting at best. The messages are
> being deferred by outgoing mail servers because we're sending mail *too*
> fast :) For testing we're only using a select number of servers. Is there
> a way to moderate qmail so it only opens X connections to any one server
> at any given time? This would alleviate this problem.
It's possible that the remote SMTP daemons are being serviced by
inetd. Many inetd implementations have an annoying rate limiting
"feature". If they see the rate of incoming connections is too high,
they'll stop servicing that port for 10 minutes or so.
I've actually swamped an upstream SMTP server from a 14k4 modem. The
upstream server was running qmail-smtpd from inetd. He quickly
switched to tcpserver.
tcpserver doesn't have a rate limit. Rather it has a limit on the
number of simultaneous connections (40 by default).
As you don't have any control over the upstream side, there's not much
you can do. If qmail-remote cannot successfully send a message, it
will back off on a per message basis. (Dave Sill's LWQ pages has a nice
table showing the back off delays. My SAGE tutorial has a nice graph
showing the same as well as the equations on how to calculate the
delays). The bottom line is that qmail will wait 400 seconds for the
first retry, 1200 seconds for retry 2, 2000 seconds for retry 3 etc etc.
You could try to send qmail-send a SIGALRM on a periodic basis. This
will tell it to flush the queue, but this may start a storm of
qmail-remotes that may swamp the upstream sites all over again.
As you'll be dealing with real remote systems you'll have to weight
your test results accordlingly.
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
Technical Consultant or at present:
eServ. Pty Ltd [EMAIL PROTECTED]
Phone: +61 2 9206 3410 Fax: +61 2 9281 1301
"If you kill all your unhappy customers, you'll only have happy ones left"
