I think the problem is that the definition of "Sizelim=" is a bit fuzzy. This keyword was added in 1986 to solve a problem with the redistribution of ARPA lists. If I remember correctly, the goal was to INCREASE the maximum message size for lists which needed it. At the time, a typical value for MAILMAXL was 1000, which was too low for some digested lists. To clarify, the purpose of the (global) MAILMAXL and FILEMAXL limits are to allow the maintainer to tell LISTSERV that one of the following is true: 1. There is no point in attempting to process files larger than XXXXMAXL because this would cause LISTSERV to run into some operating system quota or other. That is, it is known in advance that this operation will fail, although it may chew quite a few cycles before this happens, and produce all sorts of nasty error reports. It is much better not to attempt the operation. The reason there are different limits for FILE and MAIL is that the latter requires more resources. 2. While LISTSERV's quotas are big enough to allow the operation, this would be a disaster for some other system component (typically the mail system). Maybe it can't handle files of that size, maybe the 2.4bps network link is too noisy to transfer a file of that size before the usual intermittent carrier drop, whatever. Or maybe the other systems on campus just won't accept a message of that size. In practice people left FILEMAXL alone and set MAILMAXL to the largest message size they wanted to accept on local mailing lists and/or to the largest message other systems would accept. "Sizelim=" allowed larger values for lists that really needed it. Then I guess what happened is that people discovered they could use "Sizelim=" to impose a maximum message size on the list, and used it that way. It works, but doesn't behave in a very sensible way, since that wasn't its purpose. The logical thing to do would be to return the message to the sender. So I think I'm going to make it work that way in the next version if the limit is less than MAILMAXL. Eric