Alongside the SSH honeypot I've been running since early March, I also set up an SMTP honeypot on the same VPS - a fake open mail relay on port 25 that accepts everything and delivers it nowhere. This post covers the 10 weeks of messages that accumulated.

the indy scanner

The most frequent visitor by far is spameri@tiscali.it, showing up almost every single day:

From: spameri@tiscali.it
Subject: [honeypot IP]
To: spameri@tiscali.it
X-Priority: 3
X-Library: Indy 8.0.25

t_Smtp.LocalIP

The X-Library: Indy 8.0.25 header is the giveaway - Indy is an old networking library for Delphi/Pascal. The body t_Smtp.LocalIP is a Delphi variable name that was never resolved - someone's relay scanner has a bug that's been printing the variable name literally instead of the actual value. It's been doing this every day for ten weeks.

Worth noting: back when I ran mail servers I was seeing this exact address hitting them, and that was roughly 15 years ago. Whatever this is, it has been continuously running for a very long time.

the relay verification ecosystem

Once discovered, multiple independent services start tracking whether the relay stays up:

The "GOLD" alert showed up four separate times (March 10, April 21, April 24, May 4-5), each time blasting the same seven-or-so recipients:

Subject: VULNERABILITY PROOF: GOLD [redacted]

Vulnerability: GOLD
Target: [redacted]
IP: [honeypot IP]
Verified: 2026-03-10 13:16:55

"GOLD" appears to be their rating for a fully open, no-auth relay. This looks like a relay broker notifying buyers when a new relay comes online.

The marker system from one service sends a base64-encoded data blob to a fixed recipient with a unique random marker per send:

DATA For [honeypot IP]
Date: 22 : 03 : 2026
SMTP: [honeypot IP]:25
HOSTNAME: [honeypot hostname]
🔑 MARKER: 7FWC2ZG78S

Appeared twice then stopped - likely a monitoring service logging relays with timestamped proof-of-delivery.

The PHPMailer autodiscovery tests (System Test <it@[honeypot hostname]>) used PHPMailer 7.0.2 to send to several business addresses - probably automated deliverability-checking tools.

The "server details" dump sent the relay's full connection info to a small set of specific addresses including what looked like a lawyer/barrister inbox and personal accounts:

Mode: NOAUTH
IP: [honeypot IP]
Mailserver: [honeypot hostname]
Port: 25
User: N/A / Pass: N/A / SSL: False

Someone sharing relay credentials with specific people rather than broadcasting them.

the day-of-week tester

One sender uses test@test.com with Indy 9.00.10 and fires to a fixed recipient list with bodies that are just the day of the week, mangled:

COOK / MONDAEE / TUEDAEE / GOD OF SABBATH IS GOOD / SATURDAEE / THURS 444

Later the same sender/library combination starts routing actual scam content. Classic relay warm-up before graduating to payload.

the scam ecosystem

The bulk of the content is advance fee fraud. A few technical patterns:

Two senders used the same federalministryofagriculture@vp.pl From address with different personas - shared infrastructure or the same operator running parallel campaigns.

At least six distinct dying-widow/cancer-patient personas followed the same template: spoofed From on a legitimate-looking domain, Reply-To pointing to a personal Gmail. One sender fired two identical copies to the same list within minutes - no deduplication in the script.

The most persistent campaign ran almost daily from April 23 through today using the same fixed recipient list, alternating between two templates from the same reply-to. Still running when I pulled this data.

spoofing legitimacy

A few senders used real organization addresses as their From: header:

• ghunterbt@redcross.org - used to send "my XMAN" to four recipients
• federalministryofagriculture@vp.pl - used by two separate scam campaigns
• info@rin.org, test@gpl1.limberapps.com - From spoofed, Reply-To pointing to Gmail

With no authentication on port 25, the From: header is meaningless - these senders are just borrowing visual authority.

the Standard Bank phishing

One elaborate message (April 10) impersonated Standard Bank of South Africa with full HTML formatting and branding images pulled from Google's image cache. The reply URL chain was a deeply-nested deref-mail.com redirect stack - roughly 20 levels of URL encoding deep - to obscure the final destination from link scanners. A raw IP address was accidentally left in the body text, probably a template error.

the word soup

Two messages from sting@terradevins.cat and sting@sopaic.com sent incoherent word salads with MID: hashes in the subject - spam scrambled to evade content filters. The actual payload was presumably a link or attachment that didn't make it through the honeypot.

what I've learned

On SSH I see people trying to gain access to machines. On SMTP I see what they do with open relays once they have them:

• Relay brokers catalog and rate open relays, selling access to buyers
• Advance fee fraudsters route campaigns through relay inventory without tying them to their own infrastructure
• Automated scripts verify relays on a regular cadence to maintain fresh working lists

The Indy library shows up across multiple unrelated actors - there are clearly decades-old Delphi codebases still in active use for this.

Still collecting. Will follow up when I have connection log data to cross-reference.