The EFA Collective is the part of OpenEFA that lets deployments share what they learn about senders, so that an attack seen at one organization is recognised at the next. It is in production. This is what it does, what it will never do, and where you can see it working.
What is shared
Every OpenEFA deployment, hosted by us or running on a customer's premises, contributes the outcome of what it sees and consumes what the others have seen. The shared intelligence is about senders and their infrastructure:
- Sender domain and IP reputation. Delivered, held, released or confirmed as spam, aggregated across deployments. A domain that behaved badly at one customer no longer gets a clean slate at the next.
- URL and host reputation. Links that led to credential harvesting or malware, and the hosts that served them. The Collective also serves Google Safe Browsing data to every deployment, so link checks happen without any deployment sending its mail to Google.
- Template, link-set and attachment fingerprints. The shape of a campaign, so a wave recognised at one organization is already known when its first copy reaches another.
- Drop-box addresses. The free-mail addresses that scams ask you to reply to, which are checked when a message steers replies away from its sender.
- A shared blocklist of sending infrastructure confirmed as abusive by multiple deployments.
What is never shared
The line is simple: sender-side signals are shared, recipient-side data is not. Message bodies, attachments, your users' addresses, who writes to whom inside your organization, and your quarantine decisions as individual records stay in your deployment. The Collective learns that a sender did something; it never learns what you received. A forged sender is reported by its connecting address, not by the domain it pretended to be, so a victim of spoofing is not penalised for the spoof.
Where it shows up in scoring
- Reply diversion. A message asking you to reply to a different free-mail address is checked against the Collective's known drop boxes. A known one is a strong signal on its own.
- Campaign detection across organizations. The template fingerprinting that finds snowshoe waves works across every deployment, not just within one.
- Honeypot intelligence. Domains with no real users receive attacker mail that is analysed and never delivered. Everything learned from them, fresh templates, new infrastructure, flows into the Collective within minutes.
- Sender reputation. The first-contact check at your organization is informed by how that sender behaved everywhere else.
A public face: rbldb.org
The Collective's IP listings are published as a public DNS blocklist at rbldb.org (zone ip.rbldb.org). Anyone can look up an address, read the listing policy and request removal. Requests are reviewed by a person, usually within a business day, and automatic listings expire on their own fourteen days after the activity stops. The list is built for blocking authentication attacks and exploit traffic; OpenEFA uses it as one signal among many and never as the sole reason to reject a message. A blocklist that anyone can inspect and get off is the standard we hold the Collective to.
How it has grown
The Collective began by accepting submissions from administrators. Today it is automatic in both directions: every deployment pushes every disposition, a spoof guard attributes forged senders to their real connecting address, Safe Browsing data is distributed through it, and the drop-box list is kept current. The reputation and template feeds are consumed by every module that needs them rather than by a separate score bolted on at the end.
What it means for a customer
You do not configure anything. Your deployment contributes and consumes as part of normal operation, and the effect is that the second organization an attacker tries is already warned by the first. The relevant Signal is Cross-Environment Intelligence, which explains the idea behind it. Changes to the Collective appear on the What's New page like everything else.