> >What would be the undesirable side effects?
>
> Why don't you take a look at your console logs and see where the bulk of
> the jobs are coming from :-)
I took a look at one log file that I happened to have handy and didn't
see why a reasonable limit would be a problem. What are these people
doing that requires sending hundreds of command jobs per day?
If you are saying that someone should be manually scanning the logs
every day to check for loops, all I can say is that it would be nice,
but is unrealistic. People have too many other things that need doing.
If anyone has written any programs for scanning LISTSERV logs and
emailing statistics and warnings, I am interested in hearing about
them.
> >A limit would also catch some of these turkeys who are subscribing to
> >every list they can find.
>
> This is a separate problem that calls for a different solution. For what
> it's worth, most of these people send a small number of jobs with a large
> number of requests each.
Even the ones who can't supply an address that can be replied to?
> I was about to say all that... I run LISTSERV.NET and about once every
> other month I need to do something to prevent some idiot from jamming the
> system. I would rather it ran on autopilot 100% of the time, but the
> creativity of said idiots is limitless. Now, if LISTSERV.NET ran on a
> faster machine (say, a PC), I wouldn't have to worry about that. I could
> let the problems happen and they'd stop on their own after the idiots'
> mailboxes filled up. With a PC I'd have enough horsepower that it would
> take dozens of loops to impact local service. I can't move LISTSERV.NET
Our case was not a simple loop. We might well not have noticed that.
I believe that the number of messages expanded expontentially because
the other system was sending two messages for each one received from
LISTSERV. LISTSERV sent one response for each message it received.
The growth in the number of messages was limited only by the ability
of the two systems to handle them.
At the time we figured out the problem, there were 4-5000 files in
Mailer's reader. Something like 4000 of those were due to the loop.
Due to the lack of better tools, Bruce purged the ones whose sizes
indicated they were part of the loop (4 different sizes, if memory
serves). Of course, we most likely purged some legitimate mnessages
too, but we had no other reasonable choice. The messages continued to
arrive for about 20 hours after the big purge. Presumably that was due
to messages queued in the other system and in our SMTP servers.
The scariest part is that it was apparently just some Groupwise user
who set up some rules to handle messages that arrived while he was on
vacation. Any Groupwise user can do it. And these rule-based mail
handling systems are becoming more common.
> Let's face it, if there were a maximum number of incoming files per user
> and per day, it would have to be in the hundreds, and of course the net
> effect would be the same as a SERVE OFF. You said it took one day for the
> situation to clear up after you served off the user. So, I don't see that
> this would have suppressed the problem, it would just have made it less
> dramatic.
>
> Eric
I still don't understand what users have a need to send hundreds
of command jobs in one day. Please give an example. If the
limit were on commands instead of command jobs, I can see why
list owners might encounter a problem occasionally and there would
probably need to be an exception mechanism. But I don't see it for
command jobs. A limit of 100 or 200 would have caught the problem
in time for us, I think.
|
