IEEE 802.1 Email Lists
Frequently Asked Questions

Updated May 14, 2011

for Subscribers

General

Sending

I stopped getting the list email. How can I find out why?

Are you sure your subscription address is up to date? Lots of subscribers get lost because old, forgotten forwarding arrangements are terminated, or remappings are retired.

These pages offer several ways to obtain information from ListServ^® about your subscription, and you can email the administrator. If you are sure of the exact subscription address, you can also check the database of recent suspended and deleted subscriptions. It lists changes for about six months; if your browser supports the lookup script, the date of the most recent listing appears on the page.

If my list email is suspended, how can I get it started again?

The administrator starts sending out test messages when an address failure looks permanent. If they bounce, email to that address is suspended. The administrator keeps track of the problem and sends more tests, at increasing intervals. After a month of this (seven tests with no evidence of contact), the subscription is deleted.

If you receive a test message, you may reply and ask the administrator for help. You can also restart email delivery yourself by logging into ListServ^® or sending an email command; test messages include URLs for these pages and for ListServ^® itself. If you do so, the administrator assumes the problem is fixed, unless new errors are reported, even if you don't reply directly.

It's still wisest to reply to a test message: it's possible for an email service to deliver messages but send back failure reports anyway, in which case the administrator needs your response to know your mail should not be suspended.

You can’t restart email from the no-login Web interface to ListServ^®. That feature looks like it ought to work, but it doesn't. You must log in, or use email commands and return confirmations when requested.

I get some list email, but I see discussion of messages that did not reach me. Why?

Some messages are not delivered because the recipient's mailbox has reached a storage limit.

Some gets lost in network glitches; if others received it, the error is probably in your email service. This type of error is more likely if messages are forwarded from the subscribed address to another one; in that case, updating your subscription address might help.

Sometimes copies are exchanged directly among participants, while the copies sent to the list are delayed by IEEE network trouble or for moderator approval. Follow-up exchanges sent through the list can create the illusion of missed email.

One frequent cause of lost email is a low loop-detection threshold in the recipient's email service. Many services add four or five "Received" entries to an email header on both inbound and outbound mail. IEEE handling may add seven or eight more entries, both inbound to ListServ^® and outbound to subscribers. Mail services using 16 entries as a loop-detection threshold are liable to return some email just before it reaches its destination.

A message I sent took a long time to go out on the list. Why?

There have been a few cases of delayed handling at the IEEE because of server problems.

More likely, the message was held for moderator approval for some reason. It might have contained a phrase which accidentally matched a content filter. If that's accidental, the moderator will probably try to fine-tune the filter. New subscribers might also see delays for approval.

Messages are automatically held for approval if the "From:" header field does not match a subscribed address, or if it matches a new subscription.

Why can’t 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 don’t work?

These pages come with ListServ^® and are pretty generic. So far, IEEE staff has not chosen to modify them.

Why can’t 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. We're now refining the arrangement by moving ballot responses to a sub-list.

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; can’t 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 can’t 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.

Why don’t we have a keyword-searchable archive?

The IEEE supports so many lists that staff decided they should not allow ListServ^® archives. We use a different archive program, on another server, that doesn't have the search capability.

Some 802 lists use an external indexing service to support keyword searches. Unfortunately, it doesn't work unless the archive is publicly accessible. Ours isn't; some of the access information disseminated to list participants is restricted by the IEEE.

Some of this information is not linked from the main 802.1 page. Why?

Some of this material is useful only to subscribers. It's not absolutely necessary even for them, but publishing it is a way to offer them fewer delays in managing their accounts (because they don't wait for the administrator to read email). Those who accept that offer, in turn, reduce the administrative workload.

Anything linked to the 802.1 page is regularly harvested by spammers, so the public pages about these lists are kept to a minimum set. See the next question for more.

Why do these Web pages have script dependencies and obfuscated URLs?

IEEE Web pages are a rich field for spammer harvesting, and they have attacked our lists, the list administrator, and generic administrator addresses derived from the list address. We jettisoned most of them by changing the address of the list. That's not convenient for anyone, and we still have occasional address mixups nearly a year later.

The administrator, therefore, does everything in his power to avoid or at least postpone having to change lists again. These pages should be readable with or without script support; those who cannot use scripted links are invited to email the administrator for personal assistance.

IEEE 802.1 Email Lists Frequently Asked Questions