MailMum Whitepaper

Forward

MailMum offers individual services for email administrators to monitor incoming mail traffic and to control it by blocking IP addresses or even IP networks of abusive systems using Real-time Blackhole List (RBL) technology. The admin has full control over the listings by defining parameters, blacklisted (abusive), and whitelisted (trusted) IP addresses. The defined rules may apply for the whole account down to an individual server.

Mail System Today

Provided by several sources email traffic is up to 90% or unwanted emails (called spam or junk). Controlling them through spam filters (like SpamAssassin or Rspamd) is hard as it is expensive by teaching, running, and maintaining them. Also, this high load of unwanted emails wastes a lot of costly resources that must be paid and run by specialists.

The biggest pain on spam is the same/similar spam from the same people but sent through different systems. The user sees them and asks themself, why this „same thing“ can’t be stopped/rejected by admins.

To understand what problems admins face running an email server, we need to understand what can be done and which consequences are implied through these actions.

How a MailMum Query Works

A mail server performs a standard RBL-style DNS lookup against MailMum for every connecting client IP — a reversed IP address under a server-specific subdomain, the same pattern used by public lists like Spamhaus. MailMum answers from your account’s or server’s blacklist/whitelist rules and, independently of that DNS answer, logs the query as an auditable event: which IP connected, to which server, when, and whether it was blocked or passed.

This is the mechanism behind everything described below: blacklisting and whitelisting control the DNS answer, while the audit log records every query regardless of the answer given.

Blacklisting

Blacklisting is listing an IP address in a blacklist for different reasons. Using such blacklists results in rejecting incoming email server traffic from listed IP addresses before any email data is received or even processed through an email server.

Current State on blacklisting

Currently, Real-time Blackhole Lists (RBLs) are global. If an IP address is listed on a blacklist, it is rejected by all servers using this blacklist.

Removing a server from a blacklist is considered to be hard to stop spammers from easy delisting. Only the company running this blacklist is in full control of this blacklist and defines all the rules on this list.

A lot of public RBL services rely on users providing them spam emails to create blacklist which is considered very harmful as a common email user is not aware of the problems and work he can provide for an email admin by getting his server listed on a public blacklist.

Some services like Sender Score work with a reputation system, where algorithms decide based on parameters whether an IP address is harmful or not. Getting a bad reputation is hard for email admins as they only can wait until their reputation gets better, so they can send emails to customers using such services.

Selecting a blacklist for blocking unwanted emails is also hard, as you must evaluate the quality and the usefulness of such a list for your systems. Also, most services don’t have information or statistics you can use to evaluate it.

Often admins avoid using public blacklists or live with disadvantages due to missing whitelisting of important servers or services. That’s why there is a lot of room for improvement.

Additional Problems regarding blacklisting

Using such a blacklist on an email server is trusting the blacklist provider for all incoming emails which is considered harmful or even wrong (TODO see …) as blacklisting services like Gmail by Google, Mailchimp, etc. results in a significant rejecting of valid email traffic which results in support and work. Whitelisting services on a blacklist are not possible, as these are global blacklists which can be right for one use case and wrong for another.

Blacklisting in MailMum Service

Our service is different in many cases. Every blacklist is individual down to a single server. It is in full control of the admin who is maintaining it. He can set up the system and create his blacklists and whitelists for every server IP, server group, or the whole company.

Blacklist and whitelist rules resolve hierarchically: a rule set on a single server takes precedence over a rule set for the whole account, and a whitelist entry always wins over a matching blacklist entry.

Also getting blacklisted on MailMum is not global. Blacklisting is done between two servers (sender and receiver) of emails, reducing pain for the admin being blacklisted — an IP is only blocked from the specific mail servers whose admin chose to block it, not from every mail server using MailMum.

Whitelisting

Whitelisting is listing an IP address in a list, which email traffic should not be rejected.

Current State on Whitelisting

Whitelisting IP addresses is hard as every admin has to maintain a list of services, which are relevant/important to him. Big providers like Gmail run several systems in parallel and can add or remove IP addresses for outgoing email traffic at any time. This must be monitored by admins who want to whitelist a provider or service (like Postmark, Drip, …).

As whitelisting and blacklisting works in contrast to each other, email server setup must be done in a way, that whitelisting should skip blacklisting if matched. This setup is not possible for every email server system. Also, a whitelist must be set up and managed for every server separately which is considered error prawn.

Whitelisting in MailMum Service

Whitelisting is a very important part of MailMum service, as the admin can whitelist his relevant networks or services on MailMum without any additional setup on his email servers. Controlling and running the blacklisted and whitelisted IP addresses is done by MailMum.

The admin adds the IP addresses or IP ranges that matter to him — important senders like Gmail, Outlook by Microsoft, or Sendgrid, or any other service relevant to his users — as whitelist entries, either account-wide or scoped to a specific server.

Blacklisting an IP range or network skips blacklisting whitelisted IP addresses by our systems. Our systems control whitelisting even if an admin blacklists a whitelisted IP or service. Information regarding overlaps in blacklisting and whitelisting is shown in frontend and API requests.

Delisting

Delisting is removing an IP address from a list.

Current State of Delisting

Delisting (removing) IP addresses from a list is considered to be hard, expensive, and sometimes impossible based on the blacklist rules (TODO see …).

Especially reputation based blacklists are a big pain for admins having only one or view IPs/servers to send out emails. They must wait to be delisted or get enough reputation to send emails to servers using these lists. Being listed hurts the reputation of an admin and even his customers, as the email service limited, until the delisting is finished.

Delisting in MailMum

Because every blacklist entry in MailMum belongs to a specific account and, optionally, a specific server, delisting is direct: the admin who owns that rule edits or removes it, or adds a whitelist entry (which always takes precedence) to override it immediately. There is no waiting on a shared, global list and no dependency on a third party’s review queue.

MailMum does not provide a built-in messaging channel between the sending admin and the receiving admin. If you’re blocked on someone else’s MailMum-protected server, you still need to contact that admin directly, the same way you would for any privately-run blacklist. The advantage is scope: because every listing is tied to a single server or account rather than a global reputation score, you’re only ever asking one admin to fix one rule — and a spammer sending to many different servers has to get delisted by every receiver individually, rather than clearing one entry on a shared list.

Making a decision based on figures

MailMum is a data platform, not a simple blacklist: every DNS query it answers is logged as a permanent record — source IP, destination server, pass/block status, and timestamp — so you can make decisions based on data and history, not guesswork. You can start on MailMum with zero whitelisting and blacklisting rules and let this audit trail build up first.

Dashboards surface blocked-vs-passed traffic, hourly request volume, and blacklist match counts per server and per account, so you can see what’s actually happening at your mail boundary before deciding to add a rule.

Incoming IPs are also automatically enriched with network/ownership information — who operates the network behind a given address — fetched and cached so you have that context without running a lookup by hand.

Comparing this data against your own server log entries and user feedback helps clarify whether a rule is still needed, or a stale entry can be removed.

Summary

By providing MailMum service there are a lot of improvements for the email ecosystem outside big cloud providers like Gmail from Google or Microsoft Email services.

As the MailMum service sees only sender and receiver IP addresses of servers, there are not facing privacy issues. The content and the communication stays in control of the companies using this service and in full control of the specialists responsible for them.

Building up a community, data, and reputation of IP addresses helps to create a sustainable service for a better and more diversified and independent email ecosystem.