Apache SpamAssassin Leads A Growing List of Open-Source Projects Taking Steps to Correct Instances of Racism and White Privilege
- by Brittany Day
Over the past few weeks, a heated debate has arisen on the Apache SpamAssassin users list regarding the replacement of racially charged terms like “whitelist” and “blacklist” used in the Apache Spamassassin Project’s code with more inclusive language. Certain community members have been very supportive of Apache SpamAssassin’s efforts to remove racially insensitive language from the project, while others have loudly voiced their disapproval.
Guardian Digital, the open source cloud email security company, is committed to the open-source development model and the core values of transparency and inclusion that it embodies. We felt it was important to speak with members of the community about this critical issue and share this story with other leaders and those not directly involved - hopefully inspiring them to take similar action in their communities.
A Movement Is Underway in the Open-Source Community
Racial tensions in the US are higher than they have been in over 50 years, spotlighting instances of racial injustice and white privilege that have been systematically ignored far too long. Interestingly, a social movement - which began prior to this recently heightened awareness of racial injustice - has already been underway to address racially charged language and conventions online. In light of the current environment, this movement is now gaining momentum and a growing number of organizations are stepping back and rethinking whether the messaging conveyed in their products could be deemed stereotypical or offensive. These organizations are now analyzing the potential changes to make their products and environments more accurate and inclusive.
Virtually all significant open-source projects and various tech giants who have adopted open-source software and programs including IBM, Microsoft, Amazon Web Services (AWS), Python and Drupal have already removed language that is potentially racially insensitive, and have found that doing so hasn’t been a significant impediment to their development efforts. Many other companies and projects are following suit, as the open-source community is faced with the reality that “the future is open source” - as long as open-source projects and initiatives continue to prove that they value equality and moral integrity.
Apache SpamAssassin Speaks Out Against Racial Insensitivity and White Privilege
Well before the tragic death of George Floyd on May 25th, which sparked heightened awareness of racial inequality around the globe, the Apache Spamassassin Project was actively working on improving the language used in its spam filtration framework by replacing “whitelist” and “blacklist” with terms such as “block”, “deny” and “allow”. For almost a decade, the project had been ahead of its time - using the term “blocklist” at least as early as 2011. After a vote on May 3rd, the Apache SpamAssassin Project Management Committee (PMC) formally decided to remove all racially charged language from Apache SpamAssassin. The first test of this work is already done with “allowlist_to” replacing “whitelist_to” in the 4.0.0 codebase, with no timeline for this release at the moment. Sites running the current "bleeding-edge" development code can expect to see this new language sooner.
Kevin A. McGrail, who has been personally been involved with the Apache SpamAssassin Project for nearly two decades and is a member and past chair of the Project Management Committee and past VP of Fundraising and Assistant Treasurer for the foundation, explains from his perspective why the project has chosen to replace “whitelist” and “blacklist” with “welcomelist” and “blocklist”: “Using ‘welcomelist’ and ‘blocklist’ is non-offensive, more descriptive and, since ‘welcome’ and ‘block’ start with ‘W’ and ‘B’, we avoid having to rename things like RBLs, WLBL, DNSBL, etc. This should help minimize the disruption when version 4.0 is released with the renamed configuration options.”
Like all proposed changes to the status quo, this transition has already stirred up great controversy among Apache SpamAssassin contributors and users. A message posted to the Apache Spamassassin users list on July 9th, 2020, by Kevin A. McGrail has already exploded with both supportive and highly critical comments. A host of vocal developers and users opposed to these changes argue that the sole motive behind this transition is political correctness. However, the loudest objection is that there is no technical reason for making these changes, and that doing so risks destabilizing what has been stable code and breaking existing production third-party tools and site-local configurations and customizations for no good technical reason, and according to one user, "If it ain't broke, don't fix it."
That being said, McGrail has clearly addressed concerns regarding backwards compatibility: “We went to the trouble to make rules and configuration lines work with aliases and feature checks so nothing breaks because of this. Moreover, the project is committed to backwards compatibility for at least one year after version 4.0.0 is released AND not removing the backwards compatibility until 4.1.0 is released.” McGrail adds, “This change is not being made for engineering reasons. Rather, it is solely driven by morality. As an open-source project, we are part of a movement built on a foundation of inclusion, and any engineering concerns are outweighed by the social benefits of making this change. Regardless, we are taking measures to ensure that things run as smoothly as possible, such as notifying the community and projects that build on Apache SpamAssassin at least a year in advance so they have adequate time to implement the coming changes.”
If we look to history for an indication of the risk that Apache SpamAssassin contributors and users face with these proposed changes, it appears that the chance of “breaking something” is very small. Further, examining the outcome of similar changes implemented by other significant projects and organizations including the UK National Cyber Security Centre (NCSC) and Chromium suggests that changes in the terminology used in their code hasn’t negatively impacted their development efforts. The experience from these groups suggest that, in general, very positive results can come from implementing inclusive, descriptive language, and any possible negative effects resulting from this shift will likely only be short-lived.
Strength in Diversity
Transitioning from metaphorical, connotative, and potentially offensive terminology to explicitly descriptive language seems like a logical move for the Apache SpamAssassin Project on many levels. Bill Cole, an Apache SpamAssassin Project contributor, Senior System Administrator at CipherSpace, LLC, and strong supporter of the elimination of racially charged language from Apache SpamAssassin’s software, offers a great explanation of how this transition will benefit the project - morality aside:
The Apache SpamAssassin Project has a particular self-interest in attracting contributors from a diversity of cultures, because we are always at risk of mislabelling a pattern of letters or words as 'spammy' when in fact it is entirely normal in a cultural context other than those of the existing contributors to the project. Continuing to use 'black' and 'white' as indicators of value in code and configuration directives leaves in place a minor nuisance for some potential contributors and users who are understandably tired of being on the bad side of this semantic collision, where the most common word for their ethnic identity is constantly being used as a label for things which are bad, undesirable, malfeasant, etc. The naming collision is a problem and because the inanimate entities for which we use black and white do not in fact have any color we can both eliminate the collision AND improve the quality of the names we use.
Cole goes on to explain how the low level of diversity seen among the Apache SpamAssassin Project’s developers is a significant hurdle that must be addressed. He elaborates on the issue: “None of us has the time and skills to make a focused recruiting effort to get a more diverse set of contributors or even just more contributors. Changing a few labels in the code is something we CAN do.”
From an ethical perspective - this formal acknowledgement of an instance of racial insensitivity in its messaging is something the project CAN and SHOULD do, regardless of the current political environment. McGrail explains:
While this may appear to be a response to racial tensions in the US of late, you might be surprised to learn that the project has been working on this type of change for quite some time. We start using “Blocklist” at least as early as 2011. So this isn't about US politics and it isn't rash. This is about doing the right thing and getting rid of racially charged language. If this symbolic gesture helps even one person feel more included, that’s a win in my book.
The Tide is Turning Against Systemic Racism
In the words of Dr. Martin Luther King, Jr., "It's never the wrong time to do the right thing." Apache SpamAssassin and numerous other open-source community projects clearly recognize this, and are doing what they can to correct previous generations’ wrongs - as opposed to reinforcing, legitimizing, and perpetuating them. The tide is turning in our social culture. Change needs to come from the majority; however “the majority” is made up of individuals, organizations and communities, whose actions additively have the potential to create significant, positive societal shifts.
The recently heightened awareness of systemic racism and white privilege in our society provides a great opportunity for the open-source community to demonstrate leadership and morality in the midst of the turbulent times we’re currently living in. Guardian Digital CEO and LinuxSecurity Founder Dave Wreski reflects on the matter:
No single open-source project - or even the open-source community as a whole - isn’t necessarily going to have a monumental impact on this worldwide social movement, but does an open-source project, which supposedly embodies transparency and the inclusion of all ideas, perspectives and backgrounds, really want to contradict its core values simply to avoid minor inconveniences and small, calculated risks? It is our duty to make pronouncements against hate and take action within our communities to rectify instances of racial insensitivity and white privilege.
From the software and technology the company uses to the services it provides, Guardian Digital is committed to ensuring that every customer knows that he or she is valued and respected. Wreski elaborates: “I truly admire the initiative and leadership that Apache SpamAssassin and an expanding group of open-source community projects are demonstrating in their response to this global issue and, now more than ever, I am extremely proud to be a member of the open-source community.”
Must Read Blog Posts
- Demystifying Phishing Attacks: How to Protect Yourself in 2023
- What You Need to Know to Shield Your Business from Ransomware
- Shortcomings of Endpoint Security in Securing Business Email
- Microsoft 365 Email Security Limitations You Should Know in 2023
- Complete Guide to Email Viruses & Best Practices to Avoid Infections in 2023
- How Phishing Emails Bypass Microsoft 365 Default Security
Latest Blog Articles
- What To Prioritize In Ransomware Protection
- Cybersecurity Mistakes That Could Cost You Your Job
- Top Microsoft 365 Security Concerns & How To Overcome Them
- Why Cybercrime Continues to Thrive, And What You Can Do About It
- Top Malware Strains and How to Mitigate Them
- What is the Difference Between SIEM and SOAR?
- SPF, DKIM & DMARC: What Are They & How Do They Secure Email Against Sender Fraud?
- Assessing the ROI of Your Email Security Solution
- What is a Brute-Force Attack?
- How Guardian Digital Stops Impersonation Attacks