On Oct 19, 2011, at 5:36 PM, Wauford, Melissa wrote:

> I’m running Listserv 15.5 under Solaris 10 on a standalone SPARC system. I have a lot of generally small lists, but I have a small handful quite large lists that we tolerate because they are used infrequently and the owners are generally good citizens and avoid sending out email during high traffic periods. However.
>  
> Last week I had one of said list owners send a VERY large message to her quite large list of subscribers. Which, of course, backed up listserv right at the worst time, but that wasn’t the thing that really killed me. Apparently, Listserv decided to re-queue an individual copy of the message for every subscriber on the list which filled up the 32G or so I had free on the Listserv spool partition. Then all of my incoming mail queued up behind 18,000 copies of that message that had to be individually processed by Listserv. It took a while.
>  
> I can’t say I’ve ever seen this before. And there is no indication in the Listserv log that it is reprocessing the message, so there’s no way to know how often it happens on other lists that I just haven’t noticed because the lists are small and the messages are small. But I need to figure out how to keep this from happening again without hanging the list owner up by her thumbs or buying HPO for the 3-4 lists I have that would benefit from it.
>  
> I’m guessing that it may have something to do with the Auto-probe setting on the list, but I’m not sure. Can anyone shed any light?

Generally how LISTSERV delivers mail is by creating .mail files in ~listserv/spool/.  Then the SMTP workers (if SMTP_FORWARD_1 is configured) or the main LISTSERV process (if not) read the .mail files and deliver them to the outgoing mail server.

It sounds like LISTSERV was creating a separate .mail file for each recipient, which happens for mail merge messages (since each recipient gets a slightly different copy of the message), or if MAXBSMTP is set to 1 in LISTSERV's configuration, or under a couple of other sort of specialized situations.

To prevent the sort of situation you describe, I would probably impose a limit on the size of messages, either using 'SizeLim=' settings on individual mailing lists or by setting a global limit via FILEMAXL.

-jwgh
############################

To unsubscribe from the LSTSRV-L list:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=LSTSRV-L&A=1