O cliente SMTP remoto nem sequer tenta autenticar e não faz nenhuma tentativa de enviar uma mensagem. Seu arquivo de log mostra que ele simplesmente SAIR depois de receber uma resposta para seu comando EHLO User :
< s72-38-252-2.static.datacom.cgocable.net[72.38.252.2]: EHLO User
...
< s72-38-252-2.static.datacom.cgocable.net[72.38.252.2]: QUIT
Eu suspeito que o cliente remoto esteja verificando algo específico na resposta ao seu comando EHLO (que deve ter um nome de domínio totalmente qualificado em vez de User ). Diferentes servidores SMTP respondem de maneira diferente a tais comandos, por exemplo, seu Postfix smtpd indica que ele suporta STARTTLS e AUTH PLAIN .
O comando EHLO em si é a extensão Extended SMTP do comando original% HELO do SMTP; Os servidores ESMTP respondem a ele com êxito (código 250 seguido de uma lista de recursos do servidor), falha (código 550) ou erro (código 500, 501, 502, 504 ou 421), dependendo de sua configuração.
O host remoto pode estar verificando uma resposta específica que indique o potencial de uma exploração que poderia ser usada. Se não receber essa indicação, simplesmente desiste.
Na minha experiência, há grandes variações em como as tentativas de quebra são "brutais"; alguns são mais sutis do que outros (presumivelmente para evitar atrair atenção indesejada para si mesmos).
Rejeitando comandos HELO inválidos
Se você aceitar conexões de muitos clientes SMTP diferentes, seria melhor não rejeitar o comando EHLO inválido sem um FQDN. Encontrei alguns clientes SMTP (em impressoras / scanners, software antigo do Windows que incluem funcionalidade de e-mail, etc.) que não enviavam nomes de domínio completos e formatados corretamente com o comando HELO / EHLO . A configuração padrão do Postfix fornecida pelo Red Hat Enterprise Linux 5 não restringe HELO de uso ou até mesmo exige isso.
Se você sabe que todos os clientes legítimos enviarão um HELO válido, ele poderá ajudar a reduzir o processamento usado para lidar tentei isso eu mesmo).