Is FraudBL.org dead?

No!

We have evolved.

FraudBL.org has been unusually quiet for several years. From the outside, that may look like the project has been abandoned.

That is not what has happened.

FraudBL has gradually become part of a larger rebuild within Tornevall Networks. Instead of continuing to maintain FraudBL as an isolated website with its own aging infrastructure, much of the technical work is now taking place through Tornevall Networks Tools.

The name FraudBL remains. The DNS-based reputation service remains. What has changed is where the surrounding tools, administration and future development are being built.

From a separate website to a wider platform

FraudBL was originally created as a specialized blacklist for IP addresses associated with phishing, fraud and other activity that could cause financial harm.

The public website at FraudBL.org became the recognizable home of the project. Behind the website, however, FraudBL has always depended on DNS infrastructure, classification rules, reporting sources, maintenance tools and administrative processes.

Those parts are now being brought closer together.

The current DNSBL and FraudBL architecture is increasingly managed through ToolsAPI at tools.tornevall.net. Reputation information is still primarily consumed through DNS lookups, while Tools provides the interfaces used to inspect, maintain, publish and remove DNS-backed records.

The active and historical DNS zones include:

• dnsbl.tornevall.org
• bl.fraudbl.org
• ecom.fraudbl.org
• opm.tornevall.org

Tools can perform live checks across the relevant zones, combine returned classification flags and handle record publication through the current DNS infrastructure. Public DNSBL statistics and selected whitelist information are also available through Tools.

The old API model has also changed

Earlier integrations were built around older versions of the Tornevall Networks DNSBL API. Those APIs allowed external systems to check, add, update and remove blacklist records through a traditional HTTP interface.

That older request model is no longer the primary public contract.

The current structure is based on DNS publication, direct DNS resolution and ToolsAPI endpoints for the administrative and specialized parts of the system. Consumers such as the Tornevall Networks WordPress plugin can perform normal reputation checks directly through DNS while using Tools for functions such as token validation, statistics, administration and controlled removal workflows.

This has also made it possible to improve several parts of the system that were previously fragmented:

• DNSBL record inspection.
• Token-backed access.
• Addition, update and removal workflows.
• Bulk operations.
• Dry-run validation.
• Public and internal statistics.
• Whitelist and local-network handling.
• Operator tools for inspecting existing reputation flags.

The work is still ongoing. Some parts are public, some are intended for delegated integrations and some remain operator tools.

FraudBL is still available through DNS

Ordinary users of the blacklist do not need to communicate with ToolsAPI for every lookup.

FraudBL remains a DNS-based service. A mail server, website, plugin or other application can query the relevant DNS zone and interpret the returned address as a bitmask.

Each flag represents a particular type of reputation information. Several flags can be active at the same time, allowing an address to be associated with more than one kind of abuse.

This DNS-first model is intentionally simple for consumers. An application does not need access to the complete FraudBL database. It only needs to perform a DNS lookup and interpret the response.

Tools is becoming the platform that supports the system around those lookups.

What happens to FraudBL.org?

FraudBL.org will remain the historical and recognizable home of the FraudBL name.

The site contains older status updates, documentation references and articles describing how the service was intended to work. Some of that material is outdated, but it also documents ideas that may still be useful.

One example was published on February 23, 2020.

In the article “När du får bedrägerimail”, we explained that people could submit fraudulent emails to FraudBL by sending them to support@fraudbl.org.

The important requirement was that the entire message had to be included.

The visible text of a fraudulent email is rarely enough. The technical headers may contain information about sending servers, routing, authentication, reply addresses and other details needed to investigate where the message came from.

The instructions linked from that article are now old and need to be replaced. The basic idea may still have a future.

A FraudBL service for private individuals

We are currently figuring out how FraudBL should move forward.

One possibility is to create a reporting service intended for ordinary email users. A person who receives a suspicious email could forward the complete message to a dedicated FraudBL intake address.

Calling it a “private person’s blacklist” could easily be misunderstood. The purpose would not be to create a blacklist containing private individuals.

It would be a blacklist and reporting service that private individuals can use.

The simplest possible workflow could look like this:

1. A person receives a suspected phishing or fraudulent email.
2. The complete original message is forwarded to FraudBL.
3. The message is received and analyzed by Tools.
4. Technical indicators are extracted from the email.
5. The report is compared with previous submissions and existing reputation information.
6. Confirmed infrastructure can be reviewed for possible publication through FraudBL.

The submission would preferably be sent as an attached original message or as an .eml file.

A normal forwarded email often removes, replaces or rewrites parts of the original headers. Forwarding the message as an attachment usually preserves much more of the technical information required for a useful investigation.

What could be extracted from a report?

A future intake system could inspect information such as:

• Sending IP addresses.
• Mail server hostnames.
• Message routing.
• Envelope sender information.
• From and Reply-To addresses.
• Domains contained in the message.
• Links leading to login forms, payment pages or fake websites.
• SPF, DKIM and DMARC results included in the headers.
• Repeated wording or templates used across several reports.
• Connections to earlier reports and existing FraudBL records.

Tools could group reports that appear to belong to the same campaign. That would make it easier to distinguish an isolated suspicious email from a larger operation being sent to many recipients.

The technical details could also be separated from the personal content of the email before information is retained or used elsewhere.

One forwarded email must not create a blacklist entry

Receiving a report would not automatically mean that an IP address, domain or mail server should be blacklisted.

Email sender addresses can be forged. Legitimate servers can be compromised. Fraudulent links can be placed on hacked websites. Redirect services and URL shorteners can also appear in messages without being responsible for the fraud itself.

A single report may be mistaken, incomplete or deliberately submitted to harm someone else.

Reports would therefore need to enter a review process.

Automation could extract evidence, group duplicate submissions and identify known indicators. It should not make the final publication decision on its own.

Before a record is published, the system may need to consider:

• Whether the original message is complete.
• Whether the sending address can be verified from the headers.
• Whether several independent recipients have reported the same campaign.
• Whether the infrastructure is compromised or intentionally operated for fraud.
• Whether an IP address belongs to shared hosting or a large mail provider.
• Whether the information is recent enough to remain relevant.
• Whether publishing the record could affect unrelated users.

Privacy must be part of the design

Forwarded emails can contain personal information.

They may include names, email addresses, account references, order numbers, telephone numbers, message history and other information that should not become part of a public blacklist.

A future FraudBL intake service would therefore need clear rules for data minimization.

The original report may need to be stored temporarily for investigation, while only the technical indicators required for abuse prevention are retained for longer periods. Personal content should not be published through DNS or exposed through public reputation responses.

The sender must also be told what happens to a submitted message:

• What information is stored.
• Why it is being processed.
• How long it may be retained.
• Whether it may be reviewed manually.
• Whether extracted indicators can be added to FraudBL.
• How incorrect information can be challenged or removed.

Protecting the reporting system itself

A public reporting address would immediately become a target for spam, automated submissions and attempts to manipulate the blacklist.

The intake process would need protections of its own.

Possible safeguards include:

• Submission limits.
• Duplicate detection.
• Sender verification.
• Automated spam filtering.
• Attachment and message-size restrictions.
• Malware-safe parsing.
• Separation between unverified reports and confirmed evidence.
• Human review before public publication.
• Audit logs for additions and removals.
• A correction and delisting process.

Reports from established providers or trusted integrations could eventually be handled differently from isolated public submissions. They should still be traceable and reviewable.

Where we are today

The consumer reporting service described here has not been launched.

The current work is focused on rebuilding the technical foundation through tools.tornevall.net, improving DNSBL and FraudBL administration, restoring documentation and creating safer record-management and removal workflows.

The older FraudBL article shows that public fraud reporting was already part of the idea in 2020. The rebuilt Tools platform gives us a better foundation for revisiting it.

FraudBL.org is not dead.

FraudBL is becoming part of something larger.