O comando HELO (e o seu sucessor moderno EHLO) representa o primeiro estágio ativo de comunicação entre o cliente SMTP e o servidor receptor, logo após o estabelecimento da conexão TCP. Este processo, tecnicamente conhecido como o Aperto de Mão (Handshake) do SMTP, é onde as identidades são apresentadas e as capacidades técnicas de ambos os lados são negociadas para o restante da sessão.

1. Fundamentos Técnicos e Evolução (HELO vs EHLO)

A evolução da identificação reflete o crescimento da complexidade da Internet e a necessidade de extensibilidade do protocolo original.

HELO (RFC 821)

O comando original era extremamente simples. O cliente enviava HELO seguido de seu nome de host. O servidor respondia apenas com um 250 OK. Não havia provisão para negociar recursos extras como segurança ou autenticação. Atualmente, o HELO é considerado um comando de compatibilidade retroativa e deve ser evitado em servidores modernos.

EHLO (Extended HELO - RFC 5321)

Introduzido com o SMTP Estendido (ESMTP), o comando EHLO mudou o paradigma da conexão de correio:
1. O cliente se identifica: EHLO mail.emissor.com.
2. O servidor responde com uma lista estruturada de capacidades suportadas (Extensions).
3. O cliente agora sabe exatamente o que pode fazer (ex: autenticar, cifrar, enviar mensagens de 20MB).

2. A Negociação de Extensões ESMTP

Quando o cliente envia um EHLO, a resposta do servidor (código 250) funciona como uma vitrine de recursos protegidos pela IANA.

• 250-STARTTLS: Indica que o servidor pode elevar a conexão para TLS. Essencial para a privacidade.
• 250-SIZE [bytes]: Informa o limite físico de uma mensagem única. Se o e-mail for maior que este valor, o cliente deve abortar o envio antes de transferir qualquer dado.
• 250-AUTH LOGIN PLAIN: Lista os métodos de autenticação permitidos. Vital para submissão de usuários finais (MUA).
• 250-PIPELINING: Permite ao cliente enviar vários comandos de uma vez, reduzindo o impacto da latência de rede.
• 250-8BITMIME: Indica que o servidor pode processar caracteres de 8 bits sem corrupção, facilitando o transporte de textos acentuados.

3. Identificação e Validação: O Papel do DNS no Handshake

Para um administrador de redes ou profissional de Cyber Security, a identificação do cliente não é apenas uma formalidade, é um ponto de controle de segurança (Admission Control).

Validação de FQDN (Fully Qualified Domain Name)

O cliente deve usar o seu nome de domínio completo no comando EHLO. Servidores receptores realizam as seguintes verificações:
1. Reverse DNS (PTR) Match: O servidor verifica se o endereço IP do cliente aponta para o mesmo nome de host declarado no EHLO. Se não houver registro reverso, a mensagem é frequentemente marcada como SPAM.
2. FQDN Check: Recusar conexões que usam nomes inválidos (ex: EHLO localhost ou EHLO 192.168.1.1).

O Banimento de Clientes Precipatados (Pre-greeting Spam)

Uma técnica de segurança comum é observar o “timing” da identificação.
- O Ataque: Robôs de spam enviam o comando HELO imediatamente, sem esperar o banner de saudação do servidor (código 220).
- A Defesa: Servidores modernos implementam um pequeno atraso deliberado no banner. Se o cliente enviar qualquer dado antes de receber o banner (o chamado “Pre-greeting”), a conexão é cortada imediatamente, pois MTAs legítimos sempre esperam a palavra do servidor primeiro.

4. Cyber Security: Banner Grabbing e Enumeração

O banner de saudação que precede o EHLO é uma fonte rica de metadados para atacantes em fase de reconhecimento (Recon).

Anatomia do Banner (Código 220)

220 mail.empresa.com ESMTP Postfix (Ubuntu)
- Vulnerabilidade: Se o banner expõe a versão do software (Postfix (Ubuntu)), o atacante pode procurar por CVEs específicas para essa versão.
- Hardening: A recomendação de segurança é remover a versão e o nome e as capacidades do banner, apresentando apenas o FQDN do servidor: 220 mail.empresa.com ESMTP.

5. Respostas de Erro no Handshake

Se as coisas derem errado durante a identificação, o SMTP utiliza códigos específicos:
- 500 Syntax error, command unrecognized: O cliente enviou algo que não é um comando válido.
- 501 Syntax error in parameters: O comando EHLO foi enviado sem um nome de host ou com um formato inválido.
- 504 Command parameter not implemented: O cliente tentou usar uma extensão não suportada.
- 421 Service not available, closing transmission channel: Frequentemente usado por defesas anti-spam (como o Greylisting) para desconectar o cliente suspeito temporariamente.

6. Diagnóstico e Auditoria em Cyber Labs

Como o Handshake é o primeiro passo, ele é o ponto ideal para testar a conectividade base e as políticas de criptografia.

Comando de Auditoria (OpenSSL):

openssl s_client -connect mx.alvo.com:25 -starttls smtp

Este comando permite ao analista de segurança ver exatamente qual é a resposta do EHLO e diagnosticar problemas de certificados digitais ou suítes de cifra fracas durante a negociação de criptografia.

7. Conclusão da Identificação

A identificação correta com EHLO define o tom e as fronteiras técnicas para toda a sessão SMTP. É o momento em que o servidor estabelece as “regras do jogo”. Sem uma identificação validada e robusta, os e-mails subsequentes correm o risco de serem descartados silenciosamente pelos motores de inteligência de reputação e filtros bayesianos que protegem as caixas de correio de bilhões de pessoas em todo o mundo.