I recently set up an SMTP server for myself to use, and I am getting some traffic from two IP addresses and none else (though for obvious reasons I will not state the addresses here).

An example session (which, in fact, repeats itself EVERY TIME) would be:

Server: 220 <hostname> ESMTP
Client: HELO *.*
Server: 250 <hostname>
Server: 503 5.5.1 Error: authentication not enabled
Client: QUIT
Server: 221 2.0.0 Bye

Why would the attacker(s) keep trying this, when LOGIN auth is clearly disabled?

Furthermore, why would the potential attacker(s) use SMTP (when ESMTP is clearly available), and what does HELO *.* mean? (I am aware of what the HELO command does)

For reference, I am getting roughly one "attack" every 15 minutes.

  • The log you got is the typical signature of an automatic attack badly coded. If the origin IP isn’t changing, I advise you to put it on black list for one year. You can’t waste your time to eliminate such stupid attacks.
    – dan
    Commented Jan 14, 2019 at 9:00

2 Answers 2


Attack code is often a hastily scripted affair, poorly written and without proper error handling. It’s probably only checking for a a 200 OK response, and retrying in case of any non-200 response.

To elaborate further, the attacker isn’t interested in complying with the protocol. His goal is not to make your server happy. He’s only interested in testing login credentials.

There’s not much you’ll be able to do about it. Make sure your SMTP server is patched and on the most current levels, etc.

  • So "bad code" is really the answer? Interesting, if no other answers show up I'll accept yours, in the mean time, could you please answer the other two subquestions? Commented Jan 13, 2019 at 17:12
  • 2
    @KryštofPíštěk: I agree with JohnDeters and the answer to the other two subquestions is also bad code. Such tools are commonly just quickly hacked together by someone who has no deeper understanding of the protocol and just saw some old protocol examples. Additionally servers often accept any protocol which looks sufficiently correct and do not actually enforce protocol standards. And, as long as it works for enough cases it is not worth to be improved. Commented Jan 13, 2019 at 17:17

It does seems like a script left unattended. See if you can block the IP address. Besides, once every 15min may not have performance impact anyway.

If you can find a specific pattern in the log files, you can block using fail2ban.

  • The OP says that the events are being generated by two IPs. That should be enough to block. I'm not sure why one would configure fail2ban for this.
    – schroeder
    Commented Jan 21, 2019 at 9:19
  • Yes, manually block 2 IPs. But it can happen from elsewhere too. Just being proactive.
    – user195975
    Commented Jan 21, 2019 at 9:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .