Loading today’s stories
Build1 distinct publisher3 min readUpdated
An email verification box that only ever probed other people's mail servers was filed under composite snowshoe spam. The cause was a stale HELO, and the fix was a support ticket.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
An operator building an email verification service found iCloud rejecting his probes with "550 5.7.1 Mail from IP 207.180.207.175 was rejected due to listing in Spamhaus", on a box that had never sent a single message [2][3]. Spamhaus had filed the address under CSS, its composite snowshoe category, return code 127.0.0.3 [4] - and by the author's account the trigger was one stale line of configuration rather than anything the machine delivered [16][18].
The service answers "does this mailbox exist" by connecting to the recipient's mail server and walking the SMTP dialogue up to RCPT TO [1]. That is the whole point worth absorbing: reputation systems score the conversation, not the payload. A machine that opens hundreds of SMTP sessions and never sends anything is still a machine with an SMTP identity, and it is judged on the same four checks as a bulk sender.
The diagnosis is instructive mainly for how much of it was wasted effort. First trap: Spamhaus does not answer queries arriving through public resolvers, so a lookup via 8.8.8.8 or 1.1.1.1 returns 127.255.255.x, meaning query refused, which reads as clean if you are not careful [6]. An empty answer is equally ambiguous between clean and no response, so the author replaced the one-liner with a script that distinguishes all three states [7]. Eighteen blocklists were checked and everything except Spamhaus came back clean, including UCEPROTECT levels 2 and 3, which list whole ranges and autonomous systems, ruling out a blanket ban on the hosting provider [8][9]. The host itself was tidy: local MTA on loopback only, empty queue, no open relay [10].
Then the plausible wrong answer. The author assumed CSS had been issued for behaviour, since his server knocks on dozens of unfamiliar SMTP servers per hour with short sessions that drop after RCPT, which resembles reconnaissance ahead of a spam run [11]. He built a hard cap on new domains contacted per hour, which is decent neighbourship, but it was not the cause and the listing did not expire [12][13].
Spamhaus delisting is free, and the ticket came back within half an hour with the actual finding: rDNS mail.proofmailapi.com, HELO proofmail.207.180.207.175.sslip.io [14][16]. sslip.io maps any IP to a domain name, which is convenient on a staging box without real DNS [17]. When the service moved to its production domain, PTR and SPF were updated and the HELO in the config was not [18]. To a receiving MTA, a host introducing itself through such a name is indistinguishable from the infected machines that do the same [19].
The receiving side checks PTR, forward-confirmed reverse DNS, a HELO that matches the rDNS, and a MAIL FROM domain with an MX, sometimes going further and calling out to that MX to see whether the sender address is even accepted [20]. Three of the four matched here; the HELO did not, and that was sufficient [21].
Two things to watch if you run probing infrastructure. The submission rules are policy, not engineering: Spamhaus will not take requests from freemail addresses, and the requester's domain must match the domain in the IP's PTR record [15], so your ability to argue depends on identity you set up beforehand. And the behavioural hypothesis was never disproved, only displaced [11][12] - the per-hour cap remains the cheaper insurance against the listing you cannot ticket your way out of.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author is building an email verification service that works via live SMTP probing: syntax and MX checks first, then connecting to the recipient's mail server and walking the SMTP dialogue up to RCPT TO.
Not a single message ever left the author's server; it had never sent an email.
Probes to iCloud began failing with the verbatim response: 550 5.7.1 Mail from IP 207.180.207.175 was rejected due to listing in Spamhaus.
A check of zen.spamhaus.org showed the IP listed as CSS (Composite Snowshoe Spam), return code 127.0.0.3.
Snowshoe spam is when a spammer spreads sending thinly across many IPs so that no single one stands out.
Spamhaus does not serve queries coming through public resolvers; asking through 8.8.8.8 or 1.1.1.1 returns 127.255.255.x, meaning query refused, which is easy to misread as clean.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-hand account, no external corroboration
The technical chain is unusually specific for a self-report: a verbatim 550 5.7.1 rejection, the zen.spamhaus.org return code 127.0.0.3, the quoted Spamhaus reply with IP, rDNS, and HELO values, an eighteen-blocklist sweep including UCEPROTECT L2/L3, and host-hygiene checks. It is also entirely single-source: no Spamhaus, iCloud, or hosting-provider statement appears, no log excerpts or lookup transcripts are shown, and the supplied text stops before the post-fix expiry result is reported. The stated causal mechanism (HELO must match rDNS) is consistent with well-established mail practice, which raises plausibility without independently verifying this incident.
One self-reported deployment and fix
Observable adoption signal is limited to a single small service on a rented VPS: one listing incident, one config fix, and one earlier quota change. No third-party usage, customer, traffic, or industry-wide incidence data is supplied, and no other operator reports a comparable CSS listing for probe-only traffic, so the pattern cannot be shown to be widespread from this material.
Slightly understated relative to its operational value
The piece makes no grand claim: it presents a configuration mistake, publishes the author's own wrong hypothesis, calls the quota a fix for a disease he did not have, and concedes that the delisting ticket was an accelerator rather than a necessity. Framing therefore tracks the evidence. If anything the transferable operational content — DNSBL queries being refused through public resolvers and reading as clean, and the identity coupling of PTR/FCrDNS/HELO/MAIL FROM — is more broadly useful than the incident-story headline suggests, so the small negative rather than zero.
Self-published by the vendor of the system described
The author is building the commercial email verification service whose infrastructure is the subject, and the product domain is surfaced through the rDNS and PTR values without any disclosure of that interest; the venue is a developer platform with no editorial gatekeeping. Countervailing signals lower the score: the post is self-critical, admits an incorrect hypothesis and a forgotten config variable, and includes no pricing, sign-up, or performance pitch, so the promotional pull is moderate rather than dominant.
Plausible mechanism, thin verification base
Confidence is held down by a one-source, one-publisher cluster with no external confirmation of the listing or its removal, and by a truncated ending that omits the measured outcome. It is held up by internal specificity (verbatim return codes and reply fields), by the self-correcting structure of the narrative, and by the fact that the asserted mechanism — HELO/rDNS alignment and FCrDNS checks at the start of an SMTP dialogue — is standard, long-documented mail behaviour rather than a novel claim requiring extraordinary support.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 20, 2026