This is a draft in development by the W3C Systems Team, created in response to reports that W3C participants are not receiving email from W3C due to SpamCop blocklisting.
W3C occasionally receives reports of mail from our systems being rejected by sites that use SpamCop's Blocking List (BL).
This generally only happens if organizations configure their servers to reject mail from servers that are on the SpamCop BL. Using SpamCop on its own is problematic and contrary to SpamCop's own advice:
Given the power of the SCBL, SpamCop encourages use of the SCBL in concert with an actively maintained whitelist of wanted email senders. SpamCop encourages SCBL users to tag and divert email, rather than block it outright. [...]
The SCBL is aggressive and often errs on the side of blocking mail. When implementing the SCBL, provide users with the information about how the SCBL and your mail system filter their email. Ideally, they should have a choice of filtering options. Many mailservers operate with blacklists in a "tag only" mode, which is preferable in many situations.
If your mail servers reject mail from W3C based solely on a listing in SpamCop's BL, please ask your mail server administrators to consider modifying the server configuration to match the recommended configuration.
Sites that do choose to block mail based on SpamCop BL entries (against the advice of both SpamCop and W3C) are likely to lose mail from W3C from time to time due to the way SpamCop has chosen to implement their automated spam detection system.
The specific reason W3C's servers become listed in SpamCop's BL has to do with SpamCop's use of "honeypot addresses" to detect mail abuse. Occasionally SpamCop receives mail at these addresses from autoresponders at our site, in response to mail forged from the honeypot addresses. We use these autoresponders for a variety of purposes, such as:
Such practices are widely accepted by the community as legitimate, yet SpamCop's policy suggests avoiding autoresponders completely, or using them only on mail whose origin has been confirmed with something like SPF or DomainKeys.
W3C was an early adopter of SPF, and our mail servers reject mail that is forged according to SPF records. If SpamCop's honeypot addresses had SPF records, forgeries would be instantly rejected by our servers, and autoresponses would not be sent to SpamCop's honeypot addresses.
W3C has asked SpamCop repeatedly to add our servers to a permanent whitelist, but our efforts to date have not proved successful. We have tried to resolve these issues with SpamCop, but have been unable to convince them to make changes.
W3C recommends that sites either use SpamCop's BLs in the recommended configuration (not as the single criteria by which to judge whether a message is spam), or avoid using SpamCop's BL's completely.
Note: W3C uses SpamCop as one input to our own spam-scoring system, but we have been careful to implement it in a way that avoids false positives -- our mail hubs reject tens of millions of malware and spam messages per week with zero reported false positives in almost a year of operation.