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