Versions of LISTSERV prior to 1.8e only supported the addition of top and bottom banners in non-MIME messages. There was simply no way to put a banner on a MIME message. As MIME became the predominant mail format, a consequence of that limitation is that digests did not have bottom banners. The same was true of regular non-digest messages, but it was most visible in digests. Adding a bottom banner to a non-MIME message is trivial: when you are done sending the message, you either tack the banner at the end, or you don't. This can be done on the fly. Not so with MIME: the banner needs to be added several times, in different formats, with different types of encoding. To know what needs to be done, you need to analyze the structure of the MIME message, etc. This is not something you want to be doing iteratively for every recipient. It needs to be done ahead of time, before you start delivering the message. And it just so happened that we were also implementing the attachment filter, which basically rewrites MIME messages to remove e.g. executables, pictures, HTML versions of the message, anything the list owner doesn't want to allow. So this is where we inserted the banners. The message comes in, it gets rewritten as needed, and then it gets processed. Once banners have been added, it is *extremely* difficult to identify and remove them when the digest is sent, especially if you also must be able to differentiate between top banners (used for "important" legal disclaimers that must never be removed under any circumstances) and bottom banners. This is a major feature in terms of development effort. I have to ask myself if I want to allocate resources to an option to remove bottom banners from digests, or if the resources would not be better spent providing a graphical interface to LISTSERV's document storing functions, which are probably still the most advanced on the market, except for the "slight" problem that they can only be accessed via e-mail, so most people don't even know that they exist. And when I ask myself which of these two developments will better benefit communities, there is no doubt that the graphical document storing functions come out on top. As you have pointed out, the old (pre-15.0) graphical interface was "pretty bad," and we are going to keep focusing our energies in that direction until we are satisfied that the interface is perceived as another reason to buy the product. We have spent a lot of energy on the new 15.0 web interface (somewhere around three times the manpower of a normal release), but there are still a lot more functions that needs to be added. We just had to draw the line somewhere and release what we had so that people could start taking advantage of the new interface. Eric