Mailing list policies
W3C hosts thousands of mailing lists for our group members and the general public to discuss and send feedback on Web standards work.
Consult our Mailing lists page for an overview on usage.
Acceptable behavior
We expect all who use our mailing lists to respect our Positive Work Environment framework that includes a Code of Conduct (Code) for the W3C Community to follow.
We may remove addresses from our lists if they generate unwanted network traffic, such as email bounces or autoreplies to members of our lists.
Spam policy
Unsolicited Bulk E-mail (UBE) is strictly forbidden!
Our definition of spam is: any form of Unsolicited Bulk E-mail (UBE). Unless it is specifically related to W3C's work in some way it is not welcome at our site. It need not be commercial: political, religious, or even academic topics are unwelcome if off-topic or bulk-posted.
This policy applies to all of W3C's systems, including mailing lists and personal e-mail addresses as well as blogs, wikis and issue tracking systems.
CfPs and announcements are generally not welcome.
Each of W3C's mailing lists has a specific topic or purpose, as noted on the archive's cover page. Subscribers to these lists and other members of our community are generally authorized to post directly to these lists without having their messages reviewed or moderated. We trust the members of our community to post responsibly, and in rare cases we will ask people to modify their behavior.
Many of our lists allow participation from members of the public as well. Posts from people who are not members of our existing community are moderated manually, to prevent spam from being distributed to our lists. We welcome comments and feedback from the general public (subject to the policy of the list in question), but this capability is not intended to allow people to send bulk announcements of conferences or workshops, even if somewhat related to W3C work.
Different lists may have different policies, for example the semantic-web list allows Calls for Participation if the subject contains [CfP] and the event is specifically about Semantic Web technologies, but unless otherwise noted on the archive's cover page you should assume that such messages are not welcome on our lists.
We may allow exceptions on a case-by-case basis, depending on the post and the nature of the list. To increase the chance of your message being delivered to one of our lists, it should be sent to a single list and explicitly mention why it is of interest to the members of the list. Sending bulk announcements with generic text and cross-posting to multiple lists at once is a sure way to have your messages rejected, and possibly be banned from posting to our site in the future.
No cross-posting
Each W3C mailing list has its own policies regarding who is subscribed and may post to the list. Those subscribed to a list are generally able to post directly to the list without delay; those who are not may be subject to manual moderation.
Please avoid cross-posting to multiple lists because since few lists have identical access rights the replies when cross-posted may not reach everyone, thus creating fragmentation.
Email attachments
Submissions to W3C email lists should conform to the following guidelines:
- Avoid unnecessary email attachments. Use an attachment only when use of a separate file is likely to be a benefit to recipients. Otherwise, place the information (in plain text format) in the body of your message.
- If an attachment is necessary, avoid formats that are virus prone, proprietary or platform dependent. For example, whenever possible you should use HTML instead of MS Word, PowerPoint or PDF.
- If you must use a proprietary or platform-dependent format, please also include an alternate version in a universally readable format such as HTML or plain text, if possible. If you cannot, then at least include a format that has widely available free viewers, if possible.
- Beware of automatic conversions to HTML. They often produce HTML that can only be viewed on certain browsers. HTML Tidy may be helpful in cleaning up HTML.
- Follow Web Content Accessibility Guidelines (WCAG).
Archive editing
W3C generally does not remove or edit messages in our mailing list archives. The archive approval system is intended to prevent messages from appearing in our archives without the poster's informed consent.
If you believe there are exceptional circumstances that merit an exception being made to this policy (for example unintended disclosure of personal or otherwise confidential information), please send details to [email protected] for consideration by our staff.
In the case of a message in our archives being removed, edited, or marked as spam, the archive page for that message will be updated in place to reflect the action taken as appropriate.
Filtering mail from W3C lists
Messages distributed by W3C mailing lists are sent with a List-Id header identifying the list, for example for www-html:
List-Id: <www-html.w3.org>
This is the standard way to identify a mailing list, defined in RFC 2919. Users who wish to filter mail from mailing lists into different mailboxes should do so using this header. Mail clients should use this header and the related headers specified by RFC 2369 to allow users to filter, join and leave mailing lists with a standard interface.
We do not offer subject tagging for our lists (for example prepending [www-html] to the Subject of each message), because this is not a reliable way to identify messages for the purpose of filtering, it wastes precious space in the subjects of messages, and it breaks DKIM signatures.
For help with filtering messages from our lists using the List-Id header, please see email client configuration for mailing-list filtering in the W3C tools wiki (contributions are welcome).
Forgery prevention
W3C has published SPF records for our domains, to prevent email forgeries appearing to be sent from our site. For the w3.org domain, our SPF record ends in ~all (softfail) to avoid SPF's issues with mail forwarding.
We also have a custom forgery prevention system that can prevent forgeries from being distributed to W3C lists for members of our community with W3C user accounts. To activate this system for your account please edit your profile and look for the 'Email forgery blocking' option.
We are in the process of deploying DMARC to further reduce email forgeries.
Is W3C sending me spam?
No. It may be that our domain name appeared in the source code of a message you received. See our Help page for more information.
Can you add list prefixes to messages?
No; for more info please see our advice on filtering above.
Can you obfuscate email addresses in the archives?
We do some simple obfuscation, but you should not expect email addresses to be kept private if participating in public forums like our mailing lists. For more info please see Email address obfuscation in mailing list archives.
Do you honor the X-No-Archive message header?
W3C's mailing list software does not honor the unofficial X-No-Archive message header to prevent archiving of messages. All messages distributed to W3C's mailing lists are archived on our site; this is a requirement of participation on our lists.
What is the archive approval system?
In the past we have had problems with people sending mail to one of our archived mailing lists and then being surprised to learn that their message ended up in a public archive.
We have thousands of archived lists and although we try to be clear about the purpose of a list whenever we refer to it, we can not control how others refer to our lists. Therefore there is always the possibility that someone will send a message to our lists without knowing it will be archived on our Web site.
This system takes care of that problem by requiring explicit approval from each poster before allowing their message to be distributed to the list. For the vast majority of posters who do not mind having their messages available in our Web archives, there is an option to approve any future messages they may send to W3C mailing lists as well.
A nice side effect of this system is that it helps to reduce spam on our lists, since spammers generally do not read the replies they receive (and many or most of the return addresses they use are bogus anyway.)
If you received a notification message from us but did not send us a message, someone else may have forged a message with your email address as the sender. You can find out where the message originated by looking at the Received: headers of the message. (note that the only such header that can be trusted to be accurate is the one that shows when/where it entered our email systems.)
If you are interested in preventing email forgeries claiming to be from your site, you may want to consider publishing SPF and/or DMARC policies for your domain. W3C's mail servers reject forgeries for domains that have published SPF records.
If you have any feedback on this system please send it to archive-approval-comments.