My mail server having a problem on blocking some attacker that trying to telnet to our mailserver. but i'm not able to block it, ip will keep changing even we block by ip. seems like he is trying to telnet instead of normal from smtp transaction. They are not able to enter our email server, but that is a transaction every second. is there any way to block it/stop it? below are the error message:   [0968] 16:14:01 Connected, local IP=xx.xx.xx.xx:25   [0968] 16:14:01 >>> 220 mymailserver.com ESMTP IceWarp; Fri, 13 Feb 2015 16:14:01 +0800   [0968] 16:14:02 <<< EHLO ylmf-pc   [0968] 16:14:02 >>> 250-mymailserver.com Hello ylmf-pc [], pleased to meet you.   [0968] 16:14:03 <<< AUTH LOGIN   [0968] 16:14:03 >>> 334 VXNlcx5hbWU6   [0968] 16:14:04 <<< aGFua3M=   [0968] 16:14:04 >>> 334 UGFzcxdvcmQ6   [0968] 16:14:04 <<< ODg4ODg4   [0968] 16:14:24 >>> 535 5.7.8 Authentication credentials invalid   [0968] 16:14:24 *** <> <> 0 0 00:00:00 INCOMPLETE-SESSION   [0968] 16:14:24 Disconnected
  • 4
    If he's bruteforcing credentials you can use fail2ban to ban his IPs after multiple attempts.
    – user186340
    Feb 13, 2015 at 9:15
  • 2
    If you're using exim4 you can add a 2 second delay before you write your 220 hello banner, and drop the connection if they don't wait for you. If they're serialising their attempts that will slow them down without significantly penalising legitimate traffic. And another vote for using Fail2Ban. Feb 13, 2015 at 9:56
  • Also you can rate-limit the connections or limit simultaneous ones; I know Postfix can do it, I suppose any other MTA also has these features, and in the worst-case scenario that can be done with IPtables.
    – user186340
    Feb 13, 2015 at 16:54
  • There is no evidence to support the assertion that the client is using telnet. Besides it absolutely doesn't matter whether the client is using telnet or not.
    – kasperd
    Dec 8, 2018 at 20:23

3 Answers 3


That idiosyncratic and invalid EHLO argument "ylmf-pc" is a known fingerprint of a widespread spamming botnet known as "PushDo" (and sometimes alternatively "Cutwail"). As shown in your transcript, it is mostly trying password guessing to authenticate and send mail through your server. Keeping it from sending spam to or through your server is easy, because of three characteristics:

  1. It actually sends the EHLO command before it receives the SMTP banner sent by the target MTA, a behavior that any modern MTA worth using (i.e. maybe not Exchange or QMail) can detect as a definitive indication of an unwelcome, pure-spam client. No legitimate SMTP client exhibits such "fast-talking" behavior, since it breaks basic SMTP functionality.

  2. The string "ylmf-pc" is not a valid EHLO argument, because it is not a fully qualified hostname or bracket-enclosed IP address literal. No legitimate SMTP client will ever use that argument. As with the fast-talk behavior, any decent MTA can be configured to reject mail from clients using an inherently invalid EHLO argument.

  3. Nearly all infected members of PushDo/Cutwail are listed in the free zen.spamhaus.org DNSBL, by way of its "CBL" component. Even if you can't block for fast-talking or using a bogus EHLO arguiment, you should be able to block based on a DNSBL and doing so with the Zen list is almost universally a good choice.

Preventing your MTA from accepting any spam being offered should therefore be relatively easy with a well-configured MTA, but exactly how to do that with the "IceWarp" MTA you seem to be using is a question best asked of the vendor. It is more difficult to address the pure volume of traffic that can be involved, since a single PushDo zombie may try to open many hundreds of simultaneous sessions and come back multiple times in a day, while there can be dozens of different zombies actively trying to attack one server on any given day. Options to mitigate that can come from the MTA; for example recent versions of Postfix can be set to simply drop fast-talker clients unilaterally (using its 'postscreen' facility) instead of playing along with them through the whole SMTP conversation politely, and Sendmail can be similarly configured. To further reduce the problem, you can use a log-sniffing tool like fail2ban (described in a previous answer) to block traffic from the specific IPs. If you choose that option, note that PushDo infections tend to last for many days at a time so you shouldn't expire blocks any faster than about a week.


The helo name of the attacker is invalid (ylmf-pc) because it's neither a FQDN, nor resolvable via DNS, so you can easily get rid of it earlier, by blocking him after the invalid EHLO is sent.

To do this with postfix, for example, do:

smtpd_helo_restrictions = permit_mynetworks, check_helo_access reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, permit

But please also read the docs about smtpd_helo_restrictions

Then, you can use fail2ban to block him after some of those invalid queries came in. There's already an example for postfix included by fail2ban, but I don't know if it also includes rules for the HELO errors. You can add them if necessary.



enabled  = true
port     = smtp,ssmtp
filter   = postfix-helo
logpath  = /var/log/mail.log
maxretry = 5


before = common.conf

failregex = reject: RCPT from (.*)\[<HOST>\]: 504 5.5.2

ignoreregex =

This is totally sufficient to block those kiddies. You can turn down the maxretry setting in fail2ban to block the attack instantly, though I don't recommend that.

  • helo restriction work for bad script , but good script show a good helo . You can get a good helo with a telnet session too . Fail2ban is just good when you have same ip trying to brute force . But distributed brute force (with tor or botnet) will just show a massive log lock in fail2ban .
    – YuKYuK
    Feb 13, 2015 at 10:51
  • 1
    Which Mailserver do you use? Knowing that, makes it easier to provide better information.
    – sebix
    Feb 13, 2015 at 14:19

One of the other problems with the CutWail attacks, that while it is easy to stop on Port 25 as usually that is MTA->MTA traffic, it gets harder to address on port 587, where legitimate customers may be trying to connect. While the IP's might be on many RBL's such as SpamHaus and SpamRats, because customers use dynamic IP(s) to connect, shared connections etc, just because the IP is listed, doesn't mean the connection is bad. However, in order to be effective brute force attacks normally need lots of connections, and you can mitigate this be limiting the successive attempts, especially if the banner (HELO/EHLO) is 'ylmf-pc', but you should be aware that whatever tool you use to do this, make sure the block is temporary. And while the botnet will soon probably pick a different HELO, in the mean time blocking all attempts that present that EHLO on port 587 is probably best.

  • 1
    I'm not entirely sure I can agree with that last. Many MUAs would like to speak to their mail servers under cover of TLS while exchanging authentication information, and to do that they'll need to say EHLO and see STARTTLS being advertised. How do you propose to serve such clients if you block everyone who EHLOs on port 587?
    – MadHatter
    Nov 26, 2015 at 18:37

You must log in to answer this question.

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