SMTP Probing: When Bots Scan Your Mail Gateway for Open Relays

If you operate mail infrastructure, you will see strange things in your logs. Most of the time it is noise. Sometimes it is a coordinated scan. In early July 2026, two Proxmox Mail Gateway instances I run started logging the same pattern over and over — and it turned into a small investigation spanning abuse reports, reverse DNS fixes, and a polite but firm exchange with a VPN provider.

This post is my write-up of that incident: what SMTP probing looks like in Postfix logs, how to tell it apart from legitimate traffic, and what I learned along the way.

The First Hit#

It started with a single log line that made me ask: who the hell is this?

2026-07-04T13:32:21.151882+00:00 mail-gw-01 postfix/smtpd[911843]: connect from unknown[141.98.9.31]
2026-07-04T13:32:21.303790+00:00 mail-gw-01 postfix/smtpd[911843]: NOQUEUE: reject: RCPT from unknown[141.98.9.31]: 504 5.5.2 <WIN-CLJ1B0GQ6JP>: Helo command rejected: need fully-qualified hostname; from=<spameri@tiscali.it> to=<spameri@tiscali.it> proto=ESMTP helo=<WIN-CLJ1B0GQ6JP>
2026-07-04T13:32:21.337341+00:00 mail-gw-01 postfix/smtpd[911843]: disconnect from unknown[141.98.9.31] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5

Several red flags jump out immediately:

This is classic SMTP probing — an automated test to find open relays. The bot connects, tries to submit mail between two foreign domains, and moves on if your server accepts it. My gateway rejected the attempt at the HELO stage. No mail was queued, forwarded, or delivered.

Good. That is exactly what should happen.

Reading the Pattern#

Once I knew what to look for, I pulled logs from both gateways over the following week (July 5–11, 2026). The picture was consistent:

• 205 SMTP attempts from 67 different source IPs
• 105 events on the first gateway
• 100 events on the second gateway
• Every attempt used spameri@tiscali.it as both envelope sender and recipient
• HELO hostnames looked auto-generated (WIN-... style)
• tiscali.it appeared only as a spoofed envelope identity — not as a source

The sources were spread across hosting providers and VPN exit nodes. One notable cluster came from networks routed through UAB Host Baltic (AS209605). Another connection originated from a TunnelBear exit IP (98.98.171.66), hitting both gateways within about a minute — strong evidence of automation, not a user sending mail.

This was not someone trying to deliver email. It was infrastructure being tested for misconfiguration.

What the Bots Are Looking For#

An open relay accepts mail from the internet and forwards it to arbitrary external recipients without proper authentication. Spammers love them because they can offload delivery to someone else’s IP reputation.

Probing bots automate the check:

1. Connect to port 25
2. Issue MAIL FROM and RCPT TO with unrelated addresses
3. If the server accepts the recipient, the relay is potentially open
4. Disconnect and try the next target

My PMG instances enforce HELO requirements and reject unauthorized relay attempts. The bots never got past step 2 in most cases. Still, the volume — 205 attempts in a week across two gateways — was worth documenting and reporting.

Filing Abuse Reports#

Rejecting probes is necessary but not sufficient. If you run mail infrastructure, reporting abuse to the responsible network operators is part of keeping the ecosystem functional.

I compiled the logs, grouped events by source network and provider, and prepared separate abuse notifications for each responsible party. Key points in each report:

• Exact timestamps and log excerpts
• Source IP and observed behavior
• Affected target systems (both gateways, both subnets)
• A request to investigate, suspend the abusive service, and prevent recurrence

Practical tip: Do not demand a formal legally binding cease-and-desist declaration from the hosting provider on the first contact. They are the network operator, not necessarily the attacker. A structured abuse complaint with a clear cease request is the right first step.

For the initial incident from 141.98.9.31, the network traced to UAB Host Baltic in Kaunas, Lithuania, with abuse contact at abuse@serveroffer.lt.

The Irony: My Own Mail Server Rejected the Abuse Report#

Here is the part that humbles you. While reporting the spameri@tiscali.it spoofing to Tiscali’s abuse desk, my own outbound mail bounced:

550 5.7.1 Client host rejected: cannot find your reverse hostname, [203.0.113.10]

The abuse report content was fine. My mail server’s configuration was not.

The outgoing connection from my web server used source IP 203.0.113.10, which had no valid PTR record. Tiscali’s receiving server rejected it — correctly.

Reverse DNS: Which IPs Actually Need a PTR?#

Not every IP on your server needs reverse DNS. Only addresses that actually send outbound SMTP need a valid PTR with matching forward DNS:

PTR:  203.0.113.10 → mail.example.com
A:    mail.example.com → 203.0.113.10

Other IPs on the same machine — additional IPv4 aliases, dedicated or shared IPv6 addresses — only need mail-related DNS records if Postfix (or your MTA) can genuinely use them as outbound source addresses. For IPv6, the same applies: PTR, matching AAAA, and SPF coverage if that address sends mail.

TunnelBear and the No-Logs Response#

One probe came from TunnelBear exit node 98.98.171.66. I opened a ticket. The response was polite and predictable:

TunnelBear operates under a strict no-logs policy. We do not collect or store records of users’ online activities, browsing history, or connection data.

Fair enough — but that was not what I was asking. I was not requesting user identity or browsing history. I was reporting ongoing abuse from their infrastructure and asking whether they could:

1. Confirm the IP was a TunnelBear exit at the relevant timestamps
2. Clarify whether outbound SMTP (TCP 25) is permitted through exit nodes
3. Block or restrict SMTP from VPN exits to prevent further misuse

A no-logs policy explains why they cannot identify who did it. It does not answer whether they can stop what is happening. That distinction is worth making clearly in follow-up correspondence.

What I Would Do Differently Next Time#

1. Verify outbound mail DNS before sending abuse reports. Nothing undermines your complaint like a bounce from your own misconfigured MTA.
2. Automate log aggregation early. Correlating 205 events across two gateways by hand works once; a script or SIEM query scales better.
3. Keep the logs. Even rejected probes are evidence if the same network returns.

Conclusion#

SMTP probing is background radiation on the internet. If you run Postfix, PMG, or any exposed MTA, bots will test your server for open relays — continuously, from VPS networks, compromised hosts, and VPN exits.

The important parts are straightforward: reject unauthorized relay attempts, understand what the log lines mean, harden your own outbound mail configuration, and report sustained abuse to the operators involved. My gateways handled the probes correctly. I just had to fix my own house before knocking on anyone else’s door.

If you are seeing similar patterns — identical foreign sender/recipient pairs, invalid HELO hostnames, high IP churn — you are probably looking at the same class of scan. Block, log, report, and move on.

Links#

• Postfix HELO restrictions
• Proxmox Mail Gateway documentation
• SWAKS — SMTP testing tool
• RFC 5321 — SMTP