Sign in to follow this  
Followers 0
MailMan

SMTP connect-disconnect events

4 posts in this topic

I've been running a mail-server for more than 10 years, using the "quaint" but very reliable and bullet-proof software known as "Post.Office" made by the long defunct "Software.com" company. I do not have it connected to any third-party anti-spam solution (probably not possible anyways) but I do maintain a rather length list of IP net-blocks that I add to daily that it will reject SMTP connections from.

So I've come here to ask the following non-Spamcop question about remote machines that perform SMTP connections (port 25) to my server that just time-out without anything else appearing to happen.

I see this happen several times a day, but 99.9% of the time it's just a single SMTP connect/timeout pair, repeated maybe 3 or 4 times over a 24 hour period from different IP addresses. Sometimes, instead of a single connect/timeout, it will be a string of maybe a dozen.

Then maybe once every other month I'll see a sequence of hundreds or even a few thousand connects/timeouts - like what happened yesterday morning.

This is on my SMTP server. Here's an example:

------

20140222055948-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22

20140222055951-0500:SMTP-Accept:Connect:[98.190.158.7]

20140222055956-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22

20140222055958-0500:SMTP-Accept:Connect:[98.190.158.7]

20140222060002-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22

20140222060006-0500:SMTP-Accept:Connect:[98.190.158.7]

20140222060010-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22

20140222060013-0500:SMTP-Accept:Connect:[98.190.158.7]

20140222060018-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22

20140222060020-0500:SMTP-Accept:Connect:[98.190.158.7]

20140222060025-0500:SMTP-Accept:Timeout:[98.190.158.7]:9:0:22

-------

The "9:0:22" means

- the time of the total connection (9 seconds)

- the number of messages exchanged (zero)

- the total amount of data transferred (22 bytes)

Between 4:35 am until 8:35 am (exactly 4 hours to the second) my server was answering SMTP connect requests from 98.190.158.7, a total of 2204 attempts which works out to an average of one attempt every 6.5 seconds.

I have no idea what was contained in the 22 bytes that was supposedly transfered - they are not logged.

A graph of the time between connections over the 4 hours shows quite erratic times for the first 1/2 hour, alternating between 3 to 12 connections per second and then nothing for 1 to 2 minutes before repeating. Then during the next 3.5 hours it settles very quickly into a tighter spread of between 2 to 12 seconds between connections.

Also during the first half-hour, the connect-time rises quickly to 80 seconds, then levels off at 120 seconds, and then falls quickly to a rock-solid floor of 9 seconds during the remaining 3.5 hours.

For the first 4 or 5 attempts, the number of bytes transferred was 22, but then drops to 0 during the first 1/2 hour, then goes right back to 22 bytes for the remaining 3.5 hours.

If these were attempts to deliver email to non-existent accounts, or relay attempts to other domains (both of which I've seen happen) they would be indicated as such in the log files (which I don't see here). So what-ever is happening during these connections is not the result of a dictionary attack or a relay attempt.

So I'm wondering what is really going on here.

Is this a DoS attempt on my server from a single IP (98.190.158.7) or from multiple computers - all of which are forging the same IP?

If the IP is being forged - would it cause my server to generate responses aimed at 98.190.158.7 - which would be a way to use my server as DoS tool against 98.190.158.7 ?

Or is this all this a (known) symptom of a broken spam-bot?

Share this post


Link to post
Share on other sites

Interesting = according to SenderBase - http://www.senderbase.org/lookup/?search_string=98.190.158.7 - that IP address has been sending an awful lot of e-mail (around 80,000 a day), mostly in bursts, the lookup currently shows:

[tcol]wsip-98-190-158-7.ph.ph.cox.net
IP Address 98.190.158.7 SenderBase
Fwd/Rev DNS Match Yes
Email Reputation Neutral
Web Reputation Neutral
[/tcol] Last Day Last Month
Email Volume 4.7 2.8
Volume Change 5318%
Hostname
Domain cox.net
Network Owner Cox Communications
But it is very selective and hasn't triggered any RBLs. SenderScore.org (another, unrelated, monitor) hasn't seen anything of it at all.

Maybe you should contact Cox network operations in Atlanta and request an explanation and cessation. Possibly something misconfigured their end? They shouldn't be rattling your cage like that anyway.

Share this post


Link to post
Share on other sites

Maybe you should contact Cox network operations in Atlanta and request an explanation and cessation. Possibly something misconfigured their end? They shouldn't be rattling your cage like that anyway.

When I looked up the IP and saw it was Cox, I pretty much knew any LART would be a waste of time. I just added the entire /16 netblock to my server's IP blocking list (I do this with every spam that gets through, but I first check to see if I've ever gotten any "good" mail from the /16 before blocking it).

I really just wanted to know what is really going on with these connect/disconnect events, particularly when they happen by the dozen (or thousand). Apparently either nobody here operates their own SMTP server, or has seen anything similar in their logs (if they are logged, if they look at them once in a while) or nobody here is sufficiently plugged into the botnet/spambot scene to know what sort of intention or mechanism is leading to these SMTP log entries.

Share this post


Link to post
Share on other sites

Some of our "regulars" operate mail servers, don't give up hope of useful response. I see that server peaked at around 1 million e-mails per day as seen by SenderBase (the day you first posted by the looks) - and goodness only knows how many truncated connections. Must have created some ripples elsewhere.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0