SMTP é uma conversa, não um único botão de envio. Um cliente abre uma conexão, se identifica, fornece um envelope, transfere o conteúdo da mensagem e lê as respostas do servidor. Cada resposta pertence a um comando e servidor específicos. A compreensão dessa sequência permite explicar por que um destinatário falhou enquanto outro foi aceito e por que um sucesso inicial não prova a entrega final.
Comece com a conexão e saudação
O servidor envia uma saudação, geralmente começando com 220. O cliente usa EHLO identificar-se e solicitar informações de extensão; HELO fornece o formulário de saudação básico mais antigo. Uma resposta EHLO multilinha usa linhas de continuação antes de sua linha final. Depois de um sucesso STARTTLS aperto de mão, RFC 3207 exige que ambos os lados descartem o conhecimento SMTP aprendido antes TLS ; o cliente deve enviar EHLO primeiro para descobrir os recursos da sessão protegida. Não reutilize a lista de extensões anterior.
A sequência do protocolo e as regras de resposta são definidas por RFC 5321. Autenticação, TLS e política de envio são preocupações adicionais e não são evidências de que o endereço De visível seja automaticamente autorizado. Registre os recursos de ponto, horário e negociados sem reter senhas ou tokens de autenticação reutilizáveis.
Mantenha o envelope separado
CORREIO DE fornece o caminho inverso usado para manuseio e falhas de transporte. RCPT TO fornece um destinatário para a transação atual. Nenhum dos comandos é o cabeçalho De ou Para visível dentro da mensagem. Uma transação pode conter vários comandos RCPT e o servidor pode aceitar alguns enquanto rejeita outros.
Considere esta sequência sintética, não uma troca capturada. MAIL FROM recebe 250. RCPT TO missing@receiver.test recebe 550 5.1.1, enquanto RCPT TO para accepted@receiver.test recebe 250. O destinatário aceito pode permanecer elegível para a transferência de DADOS subsequente; o destinatário rejeitado não foi aceito por esse servidor. Estes endereços e respostas fictícios não descrevem um serviço público.
Transfira a mensagem e leia a resposta final
Após pelo menos um destinatário ser aceito, DATA solicita a transferência de conteúdo. Uma resposta 354 convida o cliente a enviar os cabeçalhos e o corpo, terminando com a linha pontilhada necessária. A transparência do ponto evita que uma linha de conteúdo começando com um ponto seja confundida com o terminador. Por exemplo, uma linha de conteúdo que começa com .example é transmitida com um ponto inicial extra como ..example; a camada SMTP receptora remove o ponto adicionado. Uma linha que consiste apenas no ponto final tem uma função diferente.
A resposta decisiva de aceitação da mensagem vem depois do conteúdo, não em 354. Na sequência sintética, suponha que o servidor retorne 250 após o ponto final, com um identificador de fila local do servidor. Um servidor SMTP de aceitação real assume a responsabilidade conforme descrito pela RFC 5321 , mas a aceitação ainda não é uma garantia de colocação, leitura ou sucesso na caixa de entrada em um salto posterior posterior. Se a conexão desaparecer antes da resposta final, o cliente pode não saber se houve aceitação; leve em conta possíveis entregas duplicadas ao investigar novas tentativas.
Interpretar falhas no contexto
Uma resposta 4xx é uma conclusão negativa transitória; uma resposta 5xx é uma conclusão negativa permanente para a solicitação. Preserve a resposta completa e qualquer código aprimorado, porque um 550 simples não identifica DMARC como a causa. O comportamento de novas tentativas também depende da política de fila e da utilidade da mensagem. Repetir um destinatário inválido indefinidamente não o repara.
Se AUTH não for compatível ou for rejeitado, registre isso como um resultado de comando separado. Por si só, não descreve a validade do destinatário, a aceitação final dos DADOS ou um resultado de autenticação de domínio downstream. Para uma investigação real, correlacione a transcrição com os registros da fila do remetente, o rastreamento do destinatário e a política aplicável, e rotule qualquer estágio para o qual faltam evidências. Os exemplos deste guia são hipotéticos; nenhum login, troca de soquete ou entrega de correio foi realizado para eles.
Crie um livro-razão de comandos e resultados
- Conexão: registre o ponto real, a hora e a saudação.
- Capacidades: salve os resultados EHLO separadamente antes e depois de qualquer negociação TLS .
- Envelope: retenha MAIL FROM e cada resultado RCPT TO separadamente.
- Conteúdo: diferencie o convite 354 da resposta final após o ponto final.
- Incerteza: se a resposta final estiver faltando, marque a aceitação como desconhecida e inspecione as evidências do receptor/fila antes de alegar falha.
- Encerramento: registre a disposição final da mensagem e os estágios downstream não resolvidos, sem registrar credenciais.