0

My email server got blacklisted and I get the following message from Zenhaus CBL:

X.X.X.X. was found to be using the following name as the HELO/EHLO parameter during connections: "localhost.localdomain".

Unfortunately there were too many requests and CBL does not let me remove the blacklisting. Also I have absolutely no experience with sendmail and I don't know how to debug it/where to start, because this is what needs to be fixed first.

How can I check the HELO value by myself on the CLI?

Has anyone experienced a similar problem and can help me get sendmail running again without being blacklisted?

P.S:

The strange thing is that the same configuration worked before (I made a P2V migration from a physical machine to a virtual machine) and I never got blacklisted before the migration on the old physical server. The only thing I forgot to do after the P2V migration was changing the reverse DNS (but still this seems to not have anything in common with HELO name).

manifestor
  • 6,079
  • 7
  • 27
  • 39
  • 2
    Unless it is explicitly configured in your mail server configuration to be something else, the system hostname is used. – Michael Hampton Dec 15 '20 at 18:39
  • 1
    I recommend testing with a neutral third party after any changes to your mail system. https://www.mail-tester.com/ is one of many similar test services where you send an email and the website then explains in detail whether is was received without indication of misconfiguration/spam. – anx Dec 15 '20 at 18:51
  • @anx - mail-tester.com is a great resource, thx for that! – manifestor Dec 15 '20 at 20:36
  • @MichaelHampton - thank you very much. I know there's too little information, but if I'd told you that the same configuration worked on another machine without ever being blacklisted, what would you guess the current blacklisting might come from? Maybe from the missing rDNS? Any information/hint would be highly appreciated. – manifestor Dec 15 '20 at 20:41
  • 1
    @manifestor I would guess that the system hostname was not chnaged from its default `localhost.localdomain` on the new system and that the mail server was not configured to use any other name to identify itself. – Michael Hampton Dec 15 '20 at 21:07

1 Answers1

3

It is typical for all mail providers to log the HELO/EHLO parameter in all mail they process.

Open the headers (source) of a mail that anyone recently accepted from your server in question, it likely spells out your EHLO in one of the Received: headers. The topmost Received header mentioning your IP will contain two names: first the name you provided in HELO/EHLO, and the one obtained from looking up your network address. Usually the one next to the address literal [IP] is is rDNS name.

Received: from localhost.localdomain
  (mx7.yourdomain.example [192.0.2.2])
  by example.net (Postfix)
  with ESMTPS
  id ABC12345
  for <mary@example.net>;  21 Nov 1997 10:05:43 -0600

The relevant specification of what mail servers should put there is found in RFC 5321 Section 4.4

When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content [..]

The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

Do note that some list complaining about you using a bad name does not necessarily mean the server you are currently configuring used that name. You or a previous owner of your network address could theoretically have connected to a system reporting to that list operators via other clients.

Do also note that a list operator claiming a high number of requests about a network address is a very bad sign. List operators expect that their blocks lead the affected party to thoroughly investigate before even thinking of requesting removal from the list. Be sure to confirm that the listing indeed was meant for you, specifically (e.g. see IPv6 specific explanations here) and you have firmly established that the problem has been pinpointed and fully resolved.

anx
  • 8,963
  • 5
  • 24
  • 48