As I expected there has been a flood of requests for changes and improvements to the digest support totalling pretty close to 3 months of work. This was in fact one of the main reasons I had stayed away from this (conceptually simple) new function for years. I just can't answer everyone privately, especially as many suggestions are common. I'd like to clarify what the intent of the digest support is and what it is not, so we can all save time on this. The reason for implementing automatic digest support is not to make it technically possible for BITNET lists to have digested versions - people have been doing this for years. The only purpose is to allow users on high-volume lists to ask for a digest version of the list without placing a burden on the list owner. The list owner makes a one-time change to the list header (if the default option is not satisfactory), and that's it. The users get all the traffic for a particular period in a single file, and read it at their leisure. The function must remain simple, so that the list owner does not get confused and does not have to be afraid to enable it. Most of the suggestions are about ways to allow the list owner to review and edit the contents of the digest, or to describe to LISTSERV the tasks he wants to do - automatically justify messages, format everything on a certain amount of columns, remove signature files, and so on. I have been mailed descriptions of all sorts of complicated commands which would allow the list owner to interact with LISTSERV and make changes to the digest. I am sorry, but this is never going to fly. If you want to edit your digest, it is much easier for both LISTSERV and you to just create the digest manually from the messages you are getting from the list than to use complicated commands to extract the posting Joe made on the 5th of january with subject containing the text "foo", edit it, and send it back. All you have to do is ask your mail program to write the message to a certain folder/notebook, and then edit that file as you see fit with the comfort of your preferred editor. There are tools available for most operating systems to assist you in making a manual digest, and LISTSERV is simply not going to become one of them. Similarly, a digest is not a moderation tool - at least not if the non-digested version is available, which is the case with LISTSERV-built digests. If you want to prevent offensive messages from showing in the digest, moderate your list. People who are not getting the digest version will see the offensive message anyway, and users may refrain from subscribing to the digest if you are censoring postings. I agree that it would be useful to remove messages such as "please add me to the list", but they are pretty rare and, in my experience, most list owners don't bother to remove them from the list archives. I don't want to have 500 lines of code to generate the digests and 2000 lines of code to implement fancy commands which are going to be used maybe once a month. And this also means I haven't got the time to implement a scheduling system allowing the owner to request that the digest be cut on mondays at 7am, except it should be done on tuesday if the monday is a holiday, and then on thursdays at 11am, except that if the thursday falls in a new month it should be done on the 1st instead, or the following working day if the 1st is a holiday. We're not running a bank but a computer network, if monday is a holiday people will find the file in their mailbox on tuesday, or if the machine is shut down on monday the digest will be sent on tuesday just as you wanted, and if you have this sort of requirements you can make your digest yourself, my goal isn't to solve the 1% of weird requirements but the other 99%. A lot of suggestions were made regarding the frequency. I understand that for a small number of very active lists, a daily digest is likely to be very large, but I don't think the solution is to ask for a digest every 12 hours, or even 8 hours (most postings will be made during working hours, so you'd get 2 empty digests and a big one). I also understand that a very small number of lists generate so little traffic that a yearly digest is better, in which case the list owner can go to the excruciatingly painful trouble of extracting the yearly notebook once a year and posting it to the list. Besides, as a LISTSERV maintainer I refuse to create lists with yearly notebooks, as the situation always gets out of hand after 3 months in spite of all assurances by the owner that it would be very low volume. I will not do anything that may cause LISTSERV to mail gigantic digests at the end of the year. I agree however that it might be useful to be able to say "don't let the digest grow beyond nnnnn lines". This would solve the problem of high volume daily digests and that of lists which tend to work in bursts, so I'll implement it. On the other hand I don't think this is a useful way to specify the digest frequency (the proposal was to say "max size 1000" as a replacement for "weekly"). If a "burst" dies, there will be a few "last messages" in the digest which everyone will not have seen. Why should people have to wait until the beginning of the next burst to see these messages? Chances are, in fact, that it will restart the discussion at that point! And you would have users posting garbage just to cause the digest to be cut. I see a lot of problems and very little to be gained, so this will be something in addition to the frequency. What I refuse to do however is to implement an option that says "cut the digests as usual, but break them into messages of no more than 1390 lines or 25k, whichever is smaller, because that is all my macintosh gateway will let through". As I've said many times, this is a problem with the gateway policy, not with LISTSERV. It affects you whenever you attempt to order any document exceeding 1390 lines or 25k, and that includes not only digests but documentation, CREN/EARN documents (such as minutes of meetings or proposals) which can be rather long, the output of many LISTSERV commands such as LIST GLOBAL, and so on. What would you do if your internal mail service threw away all envelopes containing more than 3 pages? Would you complain until they stopped doing that, or would you instead ask your correspondents to please mail this contract in 5 envelopes of 3 pages each? Why is it you accept things from people who run computers that you'd never take from people running other real-world services? It is totally unreasonable to expect the world to start cutting everything in pieces of 1390 lines or 25k, whichever is smaller, simply because of a handful of sites which can't handle more. By helping people get past this limitation, I would only decrease the amount of complaints sent to the people who are responsible for this ridiculous limitation, and it would prevent the people complaining from saying "but I can't access the list of lists and get my work done!", because you'd have a way to get it in 25 tiny pieces. And of course, as a user of a working mail system I don't want to have all the messages I get cut into pieces of 25k which I then have to reassemble manually just because there are 3 users on the list who don't complain loud enough about their mail system. Last, but not least, I am not responsible for this limitation and don't see why I should waste my time getting around it. This just is someone else's problem. Eric