There seems to be a new(?) email spam bot in the wild that is pretty pernicious and anyone who runs an email server will want to be on the lookout for it. The signature of it is like this:
Google searching the email addresses, shows hits dating back about one month. Here is a related blog entry that I found. I've also attached a text file showing the sample entries I have received on one server over the last few days. I am seeing this activity on multiple servers.

While an even moderately configured email server will reject these messages, I do recommend that everyone who is running an email server to be sure that you are using an application like fail2ban because the more we can collectively make traffic like this fall into the void will reduce the reward for the script authors and users.

There are a couple of things to note about this bot that should be mentioned:
1 - the originating IP address changes frequently.
3 - the interval between delivery attempts varies but is typically 10-30 minutes.
4 - the bot does NOT respond to 500 level error codes by ceasing transmission.
5 - the same IP address will be re-used over a periods of time. For example, in the attached log, the first IP 207.237.187.163 scores hits on both Nov 4th and Nov 5th, but there is a LONG delay between them.
6 - the time frame between IP reuse is such that a short BAN time will not be effective. For this reason, you are probably better off to reject the email with a 400 level (try again) error code, which may encourage retransmission from the same IP more frequently allowing for better IP capture. This also means that you will need to use a long ban time to achieve the desired effect of dropping repeat attempts.
7 - If you use Greylisting be sure that your (long delay) filter does not trigger on greylisted entries.

*NOTE: Based upon the rate of change in the IP addresses, it may be necessary to adjust the fail2ban REGEX to specifically target this entry with 1 hit and ban that IP. I have not yet tried tried to implement this but will watch my logs and experiment if normal banning does not show effective. Given the repeatability of the email headers, this should be effective, at least initially.

Lastly, this is another example of a case that demonstrates that security is a process. I discovered thee events because of routine log monitoring. In this particular case, I saw a massive jump in the number of rejected emails via the pflogsum report.

Attached Files

email_log.txt (102.6 KB, 25 views)

Ok, thank you, Noway2. I see it in the logs of my east-coast ec2 instance.