Why Rules Fail for Spam

Every internet service eventually attracts bad actors, and Slack's invite system is no exception. Spammers exploit the invite function to send unsolicited emails through Slack's reputable domain, counting on the trust associated with the service. These invites typically have very low acceptance rates?recipients either ignore them or join and immediately leave. Meanwhile, legitimate team invitations are almost always accepted.

Slack's initial defense relied on hand-tuned rules: deny lists of IP addresses, string matching, and regex patterns. Engineers monitored a Slack channel for notifications about blocked teams and missed spammers, then manually updated the rules to catch similar patterns. The system worked but demanded constant human attention, and it frequently erred on the side of caution, generating many false positives. For instance, the string "линк" (Russian for "link") was banned because it appeared in spam, yet it also occurs inside common Russian surnames. Similarly, rate-limiting invites from recently created teams with non-ASCII characters blocked plenty of legitimate sign-ups alongside the spam.

A Dataset for Supervised Learning

This scenario—rules continuously updated from historical outcomes—is precisely where machine learning outperforms manual effort. The problem is supervised: given past invites labeled as spam or not, the model learns to predict future labels. Building that training set required two components: features and labels.

The feature set was easy to adapt from the existing rules; recalculating those facts for historical invites was straightforward. Labels were harder. Slack hadn't systematically recorded which teams were spammy, so it adopted a proxy: whether an invite was accepted. That label existed for every invite, and while legitimate invites are occasionally ignored, team-level acceptance rates reliably separate normal activity from spam. Blocking invites that wouldn't have been accepted anyway carries little risk.

Two data collection practices proved essential:

  • Log features at scoring time. Recomputing features later risks errors, including accidentally incorporating the very outcome being predicted.
  • Fix the label window. Since users may take days to respond, an invite counted as accepted only if accepted within 4 days. Over 90% of legitimate acceptances happen within that span, and it lets the model treat old and new invites consistently.

Model Design and Deployment

Slack trained a sparse logistic regression over roughly 60 million features per invite. Regularization prunes features that don't help predict invitation acceptance, and each remaining feature contributes a score. Summing these scores and passing them through a logit function yields the predicted acceptance probability. The approach has two practical strengths: it handles a massive feature space comfortably, and it's easy to debug. For every blocked team, the model generates an explanation of the features that drove its decision.

The most predictive feature sets included known team and user IDs, email addresses and domains, IP addresses, word stems for Western languages, character n-grams for Chinese text, websites, and team age.

The usual bottleneck in production ML—running the trained model on live traffic—was eased by Slack's internal model-serving infrastructure. Deploying a model requires implementing a lightweight Python class with a generic prediction method; the service packages it as a Kubernetes microservice queryable from the rest of the stack. Scheduled updates are handled by checking a static folder in S3 for newer model versions.

Measuring the Difference

The machine-learned model flagged far fewer false positives than the old rule set. Only 3% of invites the ML model would have blocked were actually accepted when allowed through; for the hand-tuned filter, that figure was around 70%, meaning most of its flags were normal invites. Neither system let significant spam through, but the ML model avoided collateral damage.

The bigger win was operational. Manually updating rules had consumed hours of engineering attention each week, coordinated in channels that saw hundreds of messages monthly. After automation, those channels went essentially dormant. Blocked invites are still logged and periodically reviewed, but human intervention is now rare—the intended outcome of letting machines handle pattern detection while people focus on harder problems.