I've got some scheduled procs that spam groups of users. When the list of recipients is more than about 30 or so, it appears that ns_sendmail stalls out. In the aolserver log I see stuff like this:

Error: Expected a 220 status line; got:

Expected a 220 status line; got:

while executing _ns_sendmail ...etc etc 

After this happens, for several minutes port 25 appears choked (or my MTA -- exim -- is choked) since subsequent attempts by the system to deliver mail will generate this in the aolserver log:

Error: could not connect to "localhost:25"

Otherwise, when sending individual messages or smaller groups of email, everything works fine.

I see in this thread http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0000Jd&topic_id=11&topic=OpenACS that ns_sendmail doesn't use the MTA but connects to port 25 directly. However, I also see in my server's log files (/var/log/exim/mainlog) logs of all the mail that ns_sendmail is sending, suggesting that ns_sendmail *does* engage the MTA.

Furthermore, in this thread http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001DG&topic_id=11&topic=OpenACS QMail is described as a solution for high through-put email needs. Why would this be if ns_sendmail doesn't use the MTA? Am I misunderstanding ns_sendmail or MTAs?

A similar sort of problem has been reported here before http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001DT&topic_id=11&topic=OpenACS but that thread included no explanation or solution.

So what might be going on? At what level is the problem?

• Is this a problem with slow DNS responses during email delivery leading to gridlock at port 25? I'm not running BIND locally but rather getting DNS from my ISP.
• Is there some inherent limitation with how fast ns_sendmail can run? Do you have to put kludgey code in loops to slow them down? (I presume that sounds fairly idiotic; sorry.)
• Is this an exim configuration problem? (I see no error messages in the exim logs though.)
• Should this propel me to move to qmail? Of if exim otherwise works OK, should this propel me to somehow use exim for outbound mail instead of having ns_sendmail talk to port 25 directly? And what is the best way to do that -- overload ns_sendmail to call qmail instead, or just brute-force rip out all the ns_sendmail calls in the code by hand?
Many TIA!

Don, many thanks for your prompt reply!

I'm running this at the end of a DSL -- 784-1.5Mdown/128up. So maybe that's it.

Glad to know that ns_sendmail *does* use the default MTA. But if the problem is my uplink bandwidth, does qmail's queueing mechanism allow a better buffer against this limitation than does exim? And is the OpenACS site running on a big pipe in addition to using qmail?

Thanks again!

Hi Stan,

I started that thread msg_id=0001DG that mentions use qmail. We didn't. Instead, we use postfix.org and regularly send out over 12,000 messages in one loop through the db using ns_sendmail and other than slowing down the server for a while, it works great and has never stopped in over 9 months. (knock on wood!).

-Bob

Thanks for clarifying how ns_sendmail interacts with the MTA, Andrew. Obviously I didn't understand something basic.

Given your success with postfix, Bob, I'm going to persevere with exim. Maybe the fact that exim has been running from /etc/inetd.conf and not as a daemon is the problem. (I've gotta figure out why debian installed it that way this last time.)

Interesting point about tcp_wrappers, Jun, though I'm not doing that.

Thanks for all the helpful comments!!

Hi Stan,

I think I must be sleepy but it was not tcp_wrappers but inetd.  That is your problem.  Look at the logs and it will say like shuting down port 25 blah blah for 10 mins.  You have to run exim not on inetd or you will never get to spam a lot of emails.  I am sure inetd is your problem.  I also suggest that you look into qmail.