The list below are specific to the lists.armlinux.org.uk mailing lists. Where they differ with respect to RFC1855, these points override those in RFC1855:

1. Subscription requirements.
2. Sending a new message to the list.
3. Replying to a message from the list.
4. Sending a message to multiple linux-arm* lists.
5. HTML encoded messages.
6. Email attachments.
7. Commercial email.
8. Searching the archives.
9. Support for commercial products.
10. Cross-posting between linux-arm* lists and other lists.
11. Automatic replies.
12. Virus scanners and email sanitisers.

1. Subscription requirements. [rmk]

Recently, we have had to impose a restriction on the mailing lists. You must be subscribed to the mailing list in order to post messages to that mailing list. This is because of the UK Data Protection laws. Only subscribe to these lists if you accept the legal notice displayed on the relevant pages; by subscribing, you accept the terms laid out in the legal notice. Answers will be copied to you.

2. Sending a new message to the list. [rmk]

Please do not reply to an existing message as a short-cut to post a message to the lists. Email is not a disjunct set of messages, but is threaded, and mailing lists use this feature to provide a coherent archive. Some email clients (notably better than Microsoft based clients) also group messages into a thread. When ever you hit the "Reply" button, it adds information to your outgoing email that tells the rest of the world that it is a reply to that message.

Messages which violate this etiquette point are automatically rejected.

3. Replying to a message from the list. [erikm, dwmw2]

When you do reply to a message someone else has posted, please use the "Group reply" or "Reply to all" button on your mailer. Individual developers don't know everything, and by replying to them personally, you effectively cut yourself off from all the other people who could help you. Please ensure that you reply to the list and the sender of the message.

See this popular news item for more information (as seen on linux-kernel by gregkh.)

If you are including the original message in your reply, always edit the message such that it only quotes the sections which are relevant to your reply. Don't just quote the whole of the message to which you're replying.

Also, please use a mail client which correctly includes References: and/or In-Reply-To: headers in email replies. These headers are what keeps threads together by indicating precisely which messages you are replying to, and the absence of them obfuscates the mailing list by making your reply appear to start a new thread of its own rather than being correctly associated with the message to which you replied. Some mail clients, in particular some configurations of Microsoft Outlook, are not standards-compliant and do not conform to the recommendations of RFC 2822. In the case of Outlook you may be able to work around the bug by switching to its 'Internet Email' mode.

If you reply to a message, avoid top-posting like this:

Thank you for your reply. Wouldn't it be a better idea to frobnicate
foo?

Bob

-----Original Message-----
From: Alice [mailto:alice@example.com]
Sent: Tuesday, January 11, 2005 8:47 PM
To: Bob
Cc: linux-arm-kernel
Subject: Re: What is foo supposed to do?

It's to make sure bar does not eat the gnats.

This is why top posting is so bad (as seen on linux-kernel by gregkh):

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
  

All this is pretty straight forward, and can be found in RFC 1855 - Netiquette Guidelines.

4. Sending a message to multiple linux-arm* lists. [rmk]

Don't do this. If you do attempt this, the list server will filter your message out and will with-hold it until the list administrator does something with it, which normally ends up bouncing it back to you. In addition, you will receive a message about "Cross-posting".

Choose one and only one list which is most appropriate for the subject of your message. Don't post to all the mailing lists you can find. rmk himself has a policy where, if he sees this happening, he will ignore both your posts.

5. HTML encoded messages. [rmk, rfs]

Sorry, we don't accept HTML encoded messages on these lists, even if they are multi-part with a text alterative; the list server filters them out. Please ensure that your mailer does not send HTML encoded mail; Microsoft Outlook and Netscape Mail send HTML encoded mail by default.

6. Email attachments. [rmk]

Please ensure that all attachments are plain text. There is a limit of around 40KiB on the overall size of the message, so if you want to send a large attachment, please upload it to a web site somewhere, and post with a URL instead. The main ARM Linux FTP site does have an incoming directory where files can be uploaded, located at ftp://ftp.armlinux.org.uk/pub/armlinux/incoming/. Please ensure that if you are going to use this directory, that you use this one, and not /pub/incoming nor /incoming.

7. Commercial email (job offers, product advertisments, etc). [rmk]

The list server is provided for members of the Linux Community free of charge, and the generous space and bandwidth are provided under an agreement with the hosting company.

As such, do not send any mail which furthers your commercial interests (job advertisements, advertisements for selling hardware or services, etc) to these lists. Such postings are off topic for mailing lists devoted to technical development issues.

Providing links to where patches for particular hardware platforms can be downloaded is acceptable though, although you are encouraged to seek the necessary permissions to post announcements for such to the linux-arm-announce list. In either case, your mail may contain your standard company signature/disclaimer, but must in no way appear to advertise your products or services.

Failure to comply with this requirement will result in immediate and permanent expulsion from the mailing lists of the email address and/or IP address, without warning. Further infringements of this requirement will result in the offenders companies the entire IP netblock being prevented from posting messages to the list.

This is important and must be complied with without any exception what so ever.

(the other solution is that the mailing lists are permanently closed down, which none of us want.)

8. Searching the archives. [rmk]

Please search the mailing list archives before posting a technical question or a problem to the mailing lists. It is highly possible that your question has already been asked before, or someone else has encountered your problem and a solution has already been aired on the lists.

9. Support for commercial products. [rmk]

These mailing lists are not a support forum for commercial products such as debuggers and closed-source binary kernel modules. Do not post queries about these here, but direct your questions to the suppliers of these products.

10. Cross-posting between linux-arm* lists and other lists. [rmk]

Please do not do this. Subscribers on other lists may not be subscribed to the linux-arm lists, so when they try to reply to such a message, they will receive a bounce. This is deemed by others to be rude behaviour on the part of the person who originally cross-posted.

11. Automatic replies. [erikm, rmk, dwmw2]

We don't need to know that you're out of office. If you enable an autoresponder, do it in such a way that it doesn't respond to mailing list messages. Failure to do so will get you unsubscribed from the list.

Autoresponses should never be seen on the mailing list for many reasons.

Firstly, an automatic response should only ever be sent to the 'reverse-path' of the message which triggered the reply; the address to which bounces are expected. It should never be sent to the address taken from the From:, Reply-To: or other headers. In the case of mailing list traffic, the reverse-path is a different address which feeds directly to the list software; messages sent there will not reach the list.

Secondly, an automatic response should always be sent with an empty reverse-path of its own, just like a bounce. This is essential to avoid the potential for mail loops as autoresponders talk to each other. Failure to obey this simple rule is dangerous and could be reported as abuse to your ISP because it's a denial of service attack waiting to happen. The mailing list submission address is never used in a reverse-path of outgoing mail, and hence the list submission address is configured not to accept bounces.

Finally, the autoresponder should never send a report in reply to list traffic because the list messages themselves indicate that they are bulk mail. The autoresponder should check whether the message contains a Precedence: bulk or Precedence: list header and refrain from replying if such is found.

Note that the good old Berkeley "vacation" program does the right thing w.r.t. detecting mailing list messages, while certain other programs (most notably made by a company from Redmond, WA) fail to recognise mailing list messages.

You can get some guidance on setting up MS Outlook correctly.

12. Virus scanners and email sanitisers. [erikm, dwmw2]

There are a couple of low quality virus scanners and email sanitisers that trigger on valid messages. In the past, we've seen scanners wrongly triggering on gzip'ed patches and sanitisers wrongly triggering on the use of "xxx" in the Adaptec "aic7xxx" SCSI drivers. Those were of course obviously correct messages and the list owners got flooded by the amount of virus warnings. If you want to use a virus scanner, make sure it is a good one. If you fail to do so, you risk being unsubscribed from the mailing list.

See also the comment on automatic responses above. In the case of virus checking, no message should be sent to the apparent sender of the virus. It is almost unheard of nowadays for the sender address of a virus to actually bear any relation to the real sender, so by sending a virus 'warning' you are knowingly spamming a third party. Again, any instance of this reaching the mailing list may be reported as serious network abuse to your ISP.

People listed above:

• dwmw2 - David Woodhouse
• erikm - Erik Mouw
• rfs - Ralph Siemsen
• rmk - Russell King