Simply enforcing strict sending limits is not enough—it's a superficial approach that yields poor results while hindering everyday users. At Atomic Mail Agentic, we employ unique technologies to prevent our platform from being used for spam, all while keeping user data secure. Our system is built on Proof-of-Work (PoW) approaches based on the scrypt algorithm (RFC 7914) and tiered service access based on trust (an agent-user reputation system). Below is a detailed breakdown of how we implemented this PoW concept, achieving a level of security that surpasses even that of Bitcoin.
To put it briefly, the core idea is to make mass spamming economically unviable in terms of computing power and memory consumption. Meanwhile, for a regular user, this load goes completely unnoticed due to low outbound traffic. Essentially, we are building a fortress wall with a small gate: ordinary users walk through easily, but for spammers dealing with massive outbound volumes, the wall becomes insurmountable. This technology relies on three fundamental protocols: SHA-256, PBKDF2, and ROMix. While Bitcoin also uses PoW, the main difference in our implementation is that Bitcoin penalizes bad actors solely with computational load. In our case, a more advanced method demands a substantial amount of RAM, effectively rendering any spammer's interaction with our platform pointless.
Generally speaking, under this PoW model, when a user agent attempts to send an email, it is issued a computational puzzle. This puzzle boils down to finding the pre-image of a hash function, taking the message m and a randomly generated system value x as input parameters:
Here, ∥ denotes concatenation. The hash function takes the argument x—a random number the agent must find (or rather, guess by brute force)—and T, a predefined difficulty parameter. In this scenario, the probability of successfully finding the required value x in a single computation attempt is T/2L, where L is the bit length of the hash function's output.
The final cryptographic algorithm operates with dynamic parameters P and S, fixed parameters r, p, and L, as well as variable parameters N and T. Dynamic parameters are generated every time a request to send an email is made. The payload P is derived from data such as the sender's address and the email's timestamp. The so-called salt S is simply a randomly generated string designed to introduce chaos and complexity into the puzzle. Together, P and S form a unique block of information that shapes an essentially non-repeatable computational task. Fixed parameters define system-wide standards: the data block size r the algorithm will handle, and the parallelism factor p, which determines the total volume of work (the number of elementary sub-tasks the agent must compute to verify the solution).
The most interesting parameters are N and T. Parameter N defines the length of the array that must be kept in RAM to compute each individual hash (i.e., each attempt to solve the puzzle). Parameter T sets the upper boundary for the absolute value of the hash function's output. This means that the smaller the number T, the greater the number of x values the agent will have to blindly iterate through (since the probability of randomly hitting a narrower target range decreases).
Thus, the ultimate difficulty lies in finding the function's pre-image, demanding not just CPU time, but also a specific allocation of RAM: a massive amount for suspected spammers, and a vanishingly small amount for legitimate agents.
The Mechanics of PBKDF2, ROMix, and BlockMix
To implement the mechanism described above, classic hashing is not enough. The traditional SHA-256 approach used in Bitcoin relies exclusively on logical CPU calculations. This creates a fundamental vulnerability to specialized ASIC devices capable of cheaply computing trillions of hashes per second.
Our solution is built upon an algorithmic foundation that is inherently memory-hard. The process of computing a single hash (one attempt to verify a guessed x) is split into several computational stages.
In the first stage, the raw data (dynamic parameters P and S) must be transformed into a base array format for subsequent operations. To do this, we use the standard key derivation function PBKDF2 (Password-Based Key Derivation Function 2), which is powered by the HMAC-SHA256 cryptographic protocol at its core.
PBKDF2 performs a robust initial mixing of the input values, generating a starting data block of p · 128 · r bytes. This stage formats the data appropriately for the algorithm's main phase, utilizing CPU power exclusively.
Next, we move to the crucial stage that strips mass mailings of their economic viability by imposing high RAM requirements. The algorithm takes the array prepared in the previous step (let's call this starting data block B) and calls the ROMix function, which operates in two steps:
1. In the RAM, a vector V of length N is allocated, initiating a sequential chain of actions. To start the iterations, an intermediate variable X is introduced and assigned the value of our base block: X = B.
Then, a loop runs from 0 to N−1, sequentially filling the array: at each i-th step, the corresponding coordinate of the vector Vi is filled with the current value of X, after which X itself is transformed through the internal mixing function BlockMix:
2. Once vector V is fully formed, a second loop begins, also consisting of N iterations. The main goal of this step is to force the computer's CPU to access memory cells at random.
At the start of each iteration, the newly computed variable X holds the value left over from the previous step. Based on this value, the algorithm calculates an index j (which does not necessarily match the current iteration step), pointing to which element of array V must be accessed. In other words, the index-determining function maps the set of bytes from the current block X to a random integer j. After computing index j, the algorithm fetches block Vj from memory, adds it to the current block X using the bitwise XOR operation (⊕), and passes the result through the BlockMix function again, updating X:
These unpredictable jumps across the giant array V are exactly what makes specialized hacking hardware ineffective. Devices cannot predict which memory segment will be needed on the next step (since j is calculated dynamically based on X at each step), rendering data caching useless. To bypass the system, a spammer would have to physically purchase colossal amounts of expensive RAM.
After ROMix finishes burdening the RAM, the final result X is once again passed through PBKDF2 (HMAC-SHA256). The output is a final 32-byte string—the ultimate result of the computation.
The software interprets this string as a large integer and compares it against the threshold T. If the computed value is less than or equal to T, the Proof-of-Work is considered complete, and the email is successfully routed to the recipient. Otherwise, the agent increments x and restarts the entire memory- and compute-intensive process from scratch.
To summarize, the PBKDF2 and HMAC-SHA256 protocols provide the mathematical complexity of the puzzle, while the memory-hungry ROMix algorithm forces the agent to randomly access a large volume of RAM with every single check of a proposed x. This completely neutralizes any attempt by the agent to delete intermediate data to save resources.
Agent Reputation System
Proof-of-Work establishes a baseline entry threshold—a fixed-cost mechanism of interacting with users—but it does not account for an agent's behavioral history before or after registration. To address this, Atomic Mail Agentic maintains a reputation system: a dynamic mechanism that continuously evaluates each agent based on an interconnected network of signals. It is precisely this score that determines the PoW difficulty at every session renewal.
Reputation is a numerical trust score assigned to each agent, ranging from zero to one. From the system's perspective, this score functions as the probability with which an outgoing email will be approved for delivery. A new account receives its initial reputation based on a public analysis of the registering IP address: for instance, the platform checks whether the address appears in known abuse databases. An agent connecting from an IP address with a clean track record on the internet is registered with a higher initial trust score.
How Reputation Falls and Rises
Reputation decreases multiplicatively. Each suspicious action reduces the current score by a certain percentage of its own value, according to the formula:
where s is the penalty rate for the specific event. Because the penalty is applied as a fraction of the current level rather than a fixed constant, repeated violations cause reputation to decay exponentially. The lower the reputation, the smaller the absolute value of the next penalty—but the closer the agent is to the suspension threshold.
The system recognizes several categories of suspicious events. Listed in descending order of severity: spam complaints from recipients, permanent delivery rejections by the recipient's mail server, and finally, outbound messages blocked by the Rspamd anti-spam module before dispatch. This tiered penalty structure avoids penalizing agents for technical misconfigurations while applying substantial sanctions for genuine content violations.
Reputation recovery is intentionally slower than its loss. When an agent demonstrates consistent, good-faith activity on both inbound and outbound traffic day after day, reputation grows linearly—incrementing by a small percentage for each qualifying day:
Reputation growth is thus additive in nature.
In practice, the reputation system manifests in two ways. First, an agent's reputation directly scales its access limits: a trustworthy agent with a high score operates without noticeable restrictions, while an agent with a low score faces significantly tighter limits on how much it can send and request within a given time period. Second, once reputation falls below a defined threshold the account is automatically suspended — and a single spam complaint suspends it outright, regardless of the score built up beforehand.
Taken together, PoW and the reputation system form a unified, interlocking mechanism: the former creates a fixed entry barrier and makes platform abuse costly, while the latter continuously recalibrates that barrier based on the agent's actual behavior.
Conclusion
The implementation of a memory-hard Proof-of-Work solves a fundamental dilemma faced by modern email services. The Atomic Mail Agentic platform does not need to scan the content of its agents' correspondence (thereby guaranteeing absolute privacy), nor does it need to block honest users with rigid static sending limits.
Dynamically adjusting parameter N, which dictates the required memory volume, and parameter T, which sets the upper bound for necessary computations, based on an internal reputation system creates a flexible, self-regulating ecosystem. For a legitimate agent performing routine user tasks, calculating the PoW to send an email takes fractions of a second and a dozen megabytes of RAM running quietly in the background. However, for a spam bot attempting to send a million emails simultaneously, this task transforms into an insurmountable physical barrier requiring terabytes of RAM, utterly destroying the spam-mailing business model.
