IEEE 802.1 Email Lists
Sending to the Lists

Before posting email to a list, you should understand the restrictions on format, content, and message size. Microsoft^® Outlook^® users should also understand how to avoid an Outlook^® bug.

Format

A non-blank subject line is required. For ballot responses, the correct subject is prescribed in the ballot announcement.

The preferred message format is plain text. HTML is discarded if present, and the message rejected if it lacks plaintext.

Before sending email with attachments, please read the comments on attachment types (below) and the restrictions on total message size.

Do not use “return receipt requested” on mail to the list. If someone else does use it, please do not return a receipt.

Replies to list email go to the originator, not to the list. If you use “Reply All” to circumvent this, make sure you don’t send multiple copies to the list or extra copies to the list owner.

Attachments

The preferred attachment type is Acrobat PDF. Others, though tolerated, may not be accepted or supported by all participants’ systems.

Because they cannot be scanned for viruses, ZIP files are to be avoided. If a file exceeds size limits, it should be posted online for download, and the location announced to the list.

Mail exceeding the size limit is automatically rejected.

Message content

Don’t send “pings” or other null-content messages. If you are investigating a problem with your subscription, that probably won’t help; contact the list administrator instead.

Spam is not welcome! This includes announcements of trade shows and other commercial activities, even those that have something to do with LANs or MANs, unless there’s a direct and clearly stated relationship to list discussions.

If your email service adds advertising footers, a legitimate message might be delayed by our spam filters.

Proprietary claims

Each list is an open forum; contributions are shared by all. Therefore, please ensure your email is free of:

• any proprietary or confidential information,
• any claims of proprietary interest, and
• any restrictions on disseminating the contents.

As a matter of principle, participants may choose to disregard messages containing such claims or restrictions. They may be removed from email archives, and not treated as valid submissions. Consideration or discussion of the contents may be refused.

Whether or not that is done, any message sent to a list is effectively published worldwide, irretrievably. The contents may subsequently circulate anywhere in the universe, with no one but the original sender to blame. That’s not a policy, just an observation of fact. If you want to control information, don’t broadcast it to an open forum.

Message size limit

The lists reject messages over the maximum length, 150 KB. Large contributions should be sent to committee or task group chairs for posting on 802.1 web pages, and the document, with its URL, announced via the list. (If your document is in any format other than plain text, PDF, or a specified ballot-comment format, you might also discuss whether it should be converted.)

Encoding an email attachment expands it by a little more than one third. Therefore, the size limit for attached files is in the neighborhood of 100 KB, to allow sufficient margin for accompanying text, email headers, and MIME formatting.

If your email client attaches an HTML version, it is discarded before checking against the size limit.

Because of the virus risk, compressed (ZIP) files are not a good way to beat the limit.

Hint: Watch out for unintended attachments, especially forwarded items.

Participants’ conduct

Usually, our discussions have remained free of flaming, inappropriate promotional messages, insults, and other misconduct. It was hoped that this section would remain superfluous forever, but apparently we need to state some rules.

The IEEE Acceptable Use Practices apply, but 802.1 reserves the right to enforce its own rules as well.

If your conduct is questioned or challenged, you may appeal to the list administrator for advice, or to the Working Group Chair for a ruling. In any case, do not continue the dispute, or the disputed conduct, via the list.

Microsoft^® Outlook^® allows you to copy and modify a received email message, and then send it on (or back). This feature is reportedly called “Resend this message” (on the Tools menu). It looks tempting, especially for responding to 802.1 ballots.

Do not use this feature to send to the list! It preserves header information from the original message, which distorts list communications two ways:

• The sender of the original (copied) message appears in the “Reply-To:” field.
• The header retains tracking information from the original message. If the original also passed through the list, the new message appears to be looping and will probably be rejected at many destinations, requiring extra work from the list administrator.

List access

You can send email contributions using the appropriate link below. But first, make sure you understand our restrictions on format, content, and size.

DO NOT send list administration requests (subscribe, unsubscribe, etc.) to these addresses! For those matters, you want to communicate with the server or the list administrator, not the other subscribers.

If you send from an address that isn’t subscribed, your message will not be accepted until you answer a confirmation request.

If the mail is from a new subscriber, or if it looks suspicious to our filters, it may be delayed for administrator approval. The delay can be anywhere from a few minutes to several days, but averages about half a day. All mail from nonsubscribed addresses is automatically subject to approval delays.

In a few common error cases (such as a missing subject line), mail may be rejected immediately, without administrator review. This allows the author to correct the error and resend quickly. Senders should monitor their email for rejection notices.

Links

• Working Group 802.1
• 802 Architecture
• To send to the ballot list, use the address supplied with the form in the ballot announcement.

DON’T PANIC!

If you have posted a message to the list, and have not yet received your copy, resist the impulse to send it again immediately. This is not an instant-messaging system; there are many possible delays inbound to the list server, and many possibilities for loss of a single outbound copy.

Maybe you didn’t send it. Check your sent mail, if possible.

Maybe you didn’t confirm. If your sending address doesn’t match a subscription, you have to respond to a server request. Look for one in received mail, then in filtered mail.

Maybe the server delayed or rejected it. Check for server notices in both normal received mail and filtered mail. If you find one, it should indicate whether you need to correct an error and resend. If your post is queued for approval, retransmitting it merely adds to the list administrator’s workload.

If your posts consistently require confirmation or approval, you may need to change your subscribed address, or to add a send-only subscription, so your “From:” header address is recognized as a subscriber.

Maybe your copy is delayed, bounced, filtered, or misplaced. This is the most common case. Therefore, always check the list archive. The archive is a subscriber; if it has a copy, your post has been distributed to the list, whether or not you received it.

Timing: If you send a duplicate within four hours of the first copy, you didn’t wait long enough. If you send a duplicate more than five minutes after the first copy was archived, you didn’t check the archive just before sending.

Other considerations

Some common email services, particularly Google™ mail, put received mail in the sender’s “sent mail” folder if the “From:” header address belongs to the recipient.

IEEE handling delays up to 20 hours have been observed for individual outbound copies.