I think we have an assumption in this thread that the X-SPAM jobs are the
cause of Paul's problems, and that Paul is forced to accept poor web
response as a result of this legacy spam prevention function. Based on my
knowledge of the code, I would challenge this assumption. Just because there
are a lot of X-SPAM jobs doesn't necessarily mean that they tie up LISTSERV.
There is an easy wait to find out: simply add DEBUG_TIME_ALL=1 to your
configuration. This will make LISTSERV log execution timing for every
command it processes. There is *some* overhead outside of what is captured
by DEBUG_TIME_ALL=1, but it is not very much. I went looking for a really
old backbone site where I have administrator access, and the oldest I could
find was a 733MHz Intel server, where I get the following timings:

16 Nov 2005 19:32:50 From [log in to unmask]: X-SPAM [redacted]
16 Nov 2005 19:32:50 -> Registered.
VCPU=0.000 TCPU=0.015 T-V=0.015 SIO=6 PGIO=0 Elapsed: 0.016 sec (93.8%)

The job took less than two hundredths of a second. Let's say three
hundredths of a second, counting the overhead that is not measured by
DEBUG_TIME_ALL=1, although it's probably less than that. You would need to
process 15 of these jobs in a row to introduce a delay of about half a
second, which is about the minimum a web user is going to notice. And that
is on hardware that is around 5 years old.

Of course, there might be special circumstances at ND. For one thing, my
test was on 14.4 and the server only has a handful of lists.

I don't really have anything against adding an option to discard X-SPAM
jobs, but frankly, I doubt that it will make any difference, especially on
recent hardware. I am more interested in figuring out why Paul is
experiencing poor web performance than in disabling X-SPAM simply because it
is old and only catches a fraction of the spam. Speaking as the
administrator of the old server on which I ran these benchmarks, I am quite
happy to spend a few hundredths of a second a few times per minute to catch
even just one spam every day before it hits a list. The cost of the
aggregated horsepower for all these X-SPAM jobs is far less than the
manpower cost of even one single spam getting to a large number of people
who get distracted and have to discard it. Besides, it's not like I have to
pay for the CPU time by the hour, or get a partial refund from the
manufacturer if I maintain a certain idle time - I wish :-)

As for jobs having priority over interactive requests, this is definitely
not the way it is meant to be. If indeed this is what is happening at ND, it
is a bug and needs to be fixed.

  Eric