Why cant I just receive a Digest or Index to cut down on my email?
The IEEE supports a huge number of lists. Their staff decided the best way to ensure the ListServ® server did not get swamped was to put the archives elsewhere. Instead of ListServ® archives called "Notebooks" we send a copy of each email to MHonArc, which maintains our archives on another server.
Unfortunately, ListServ®'s Digest and Index options depend on the Notebook feature; they are unavailable on lists that don't have it.
Why do ListServ® Web pages offer Digest and Index services if they dont work?
These pages come with ListServ® and are pretty generic. So far, IEEE staff has not chosen to modify them.
Why cant we have separate lists for different projects to cut down on my email?
We've tried that, a couple of times. There's a risk some participants could miss important information because they aren't on the right list. To compensate, many announcements get sent to all the lists; then those who subscribe to every list, so they don't miss anything, get multiple copies. Overall, there's usually an increase in email instead of a reduction.
We've been more successful with a single list for all 802.1 email. If you aren't interested in an item, you can throw it away.
You might think we could have one list for announcements with everybody on it, and others just for those interested in particular topics, but then someone has to enforce the requirement that nobody subscribes to a topical list without getting on the main one. If you ask volunteers to step forward, the list administrator is experienced enough to take a step back. (We tried that before, too.)
The participating population for 802 Architecture is significantly different from 802.1 itself, so a separate list is workable. Within 802.1, ballots and meeting schedules on any project involve all of us.
ListServ® supports subdivisions by topic; cant we use those to cut down on my email?
That yields exactly the same management problems as separate lists, with the added complication that someone has to police the subject line of every message. ListServ® documents agree that this doesn't work well unless the list is moderated, meaning every message has to wait for someone to read and approve it. That would slow up discussion and dump extra work on the moderator.
The present arrangement allows the moderator to moderate in moderation.
There is also no easy way to enforce the rule that everyone subscribes to "Other" emails (those not assigned a topic); that problem is worse than with multiple lists, because subscribers' topic selections are less easily controlled by the administrator.
Why the inconvenient restriction on message size?
Inconvenient for whom? Big messages clog up storage space, and even with the present limits, we regularly lose contact with subscribers temporarily because their mailboxes fill up. (When that happens, the administrator's mailbox starts to fill up with bounce reports, and it's Hello, gridlock!)
Big messages also chew up more bandwidth to download. File transfer is quicker for anything other than text, because most attachments are base64 encoded more than a third bigger than the file itself. Also, for some users, the file transfer is more flexible, because it is separate from retrieving email. We prefer you send big documents to the appropriate WG or TG chair for posting on the FTP site, so only the URL needs to be sent to the list.
If you are sending an email, sans attachments, that exceeds the limit, perhaps you should prepare it as a separate document.
My employer puts a confidentiality notice in email footers. Why cant you guys just ignore it?
We do understand the management aspects of the problem. But most of the people receiving list email also work for (or are) management with its own legal concerns, including the possibility of an action arising from making free use of material that arrived with such a notice attached. If we ignore the notices, we fail to address that legitimate concern.
Therefore, as these notices have no place in standards work anyway, we actively discourage them.
For the convenience of participants who might include such notices by accident (by failing to invoke some bypass mechanism, or by its failure), the administrator attempts to tune the list filters to reject contaminated email immediately.