Re:Anti-fraud tools can't keep pace with scammers exploiting...
by dredmorbius on Saturday August 01, 2026 @11:14AM
(#49135175)
This rehashes much of the experience fighting email spam in the late 1990s / early aughts.
Initially the approach was a long list of rules, usually a whitelist and blacklist of known good and bad contacts, and then a large set of specific patterns and assigned weights. Procmail was an early standard here, later Spamassassin.
The biggest revolution came with Bayesian classification. YCombinator's Paul Graham (@pg) developed one such system. The idea here was that a small set of mail was classified into two categories, spam (unwanted) and ham (wanted), and the classifier went looking for patterns within each corpus, automatically assigning weights. This took much of the guesswork and assumptions out of the process, but still relied on contextual clues within the mail itself, though both data (the message payload) and metadata (email headers) could be used.
Following that were reputation-based systems, generally looking at domains or IP address space, where a sufficiently large-scale survey of mail patterns, initially based on honeypots, later largely conducted by large email providers themselves such as AOL, Yahoo, Hotmail, (this was the aughts, they still existed), and eventually Gmail and a few others.
Google especially, through Gmail, had access to a phenomenal amount of activity, and could detect both datacenter-based bulk mailing activity and residential proxy campaigns. Effectively its Gmail service serves as a huge, distributed, collection observatory, and can respond to new spam campaigns incredibly quickly. I don't have specific insights, but suspect that response times are measured in minutes if not seconds.
Google of course also has insight to the contents of emails, but network- and header-level adjudication is much faster, cheaper, and surprisingly effective.
This is why I'm strongly advocating carrier-based, network-level phone-spam mitigations, and whatever regulatory changes are necessary to incentivise providers to adopt these. On-device apps are fine, so far as they go, but would best work in concert with network-level countermeasures.
Initially the approach was a long list of rules, usually a whitelist and blacklist of known good and bad contacts, and then a large set of specific patterns and assigned weights. Procmail was an early standard here, later Spamassassin.
The biggest revolution came with Bayesian classification. YCombinator's Paul Graham (@pg) developed one such system. The idea here was that a small set of mail was classified into two categories, spam (unwanted) and ham (wanted), and the classifier went looking for patterns within each corpus, automatically assigning weights. This took much of the guesswork and assumptions out of the process, but still relied on contextual clues within the mail itself, though both data (the message payload) and metadata (email headers) could be used.
Following that were reputation-based systems, generally looking at domains or IP address space, where a sufficiently large-scale survey of mail patterns, initially based on honeypots, later largely conducted by large email providers themselves such as AOL, Yahoo, Hotmail, (this was the aughts, they still existed), and eventually Gmail and a few others.
Google especially, through Gmail, had access to a phenomenal amount of activity, and could detect both datacenter-based bulk mailing activity and residential proxy campaigns. Effectively its Gmail service serves as a huge, distributed, collection observatory, and can respond to new spam campaigns incredibly quickly. I don't have specific insights, but suspect that response times are measured in minutes if not seconds.
Google of course also has insight to the contents of emails, but network- and header-level adjudication is much faster, cheaper, and surprisingly effective.
This is why I'm strongly advocating carrier-based, network-level phone-spam mitigations, and whatever regulatory changes are necessary to incentivise providers to adopt these. On-device apps are fine, so far as they go, but would best work in concert with network-level countermeasures.