SMTP MTA para autenticação MTA

Question

Ainda tenho problemas para entender como um MTA de recebimento autentica o MTA de encaminhamento.

Eu imagino um email que é encaminhado pelo MTA do domínio A _A para o MTA do domínio B _B .

Etapas a serem tomadas pelo MTA _A :

1. Encontre o registro MX do domínio B no DNS.
2. Conecte-se, (verifique o X.509 para garantir a autenticidade) e encaminhe a mensagem.

Mas agora, o que o MTA _B faz? Como ele não quer ser spam e provavelmente já ativou a autenticação do usuário, vejo duas opções aqui:

O
1. MTA _B também verifica imediatamente o registro MX do MTA _A , para garantir que esteja falando com um servidor de correio registrado.
2. MTA _B depende apenas de preto, -, lista branca

Do meu host local, recebo problemas de "má reputação" ao tentar se conectar.

Não encontrei nenhuma informação sobre isso na RFC ou pergunta com minhas palavras-chave, além de esta entrada . No entanto, o último só responde como para encontrar e se conectar a um MTA, mas não quais mecanismos são usados para autenticação.

Eu ficaria grato por qualquer dica:)

    

Answer 1

No topo da minha cabeça, as verificações clássicas são:

• assim que o endereço IP de uma conexão de entrada é conhecido: faça uma pesquisa inversa de DNS do endereço IP - se falhar, provavelmente não é um MTA legítimo bem configurado.
• depois que a pesquisa inversa é concluída: faça uma pesquisa de DNS de encaminhamento no nome retornado pela pesquisa inversa - se o IP resultante não corresponder ao IP de conexão, provavelmente não é um MTA legítimo bem configurado.
• à medida que a parte de conexão envia a mensagem HELO / EHLO inicial: o FQDN reivindicado em HELO / EHLO corresponde ao FQDN real informado pelas pesquisas de DNS? Se não, a conexão pode ser tratada com alguma suspeita, embora possa não ser terminada imediatamente. Se a conexão reivindicar um nome de domínio "interno", mas vier de um endereço IP "externo", o requisito de autenticação deverá ser imposto: pode ser uma tentativa de enganar servidores de email antigos / mal configurados ou apenas um cliente de email móvel.

• como a parte de conexão envia a linha MAIL FROM: : o FQDN da fonte reivindicada dentro do (s) domínio (s) pelo qual esse servidor de e-mail é responsável? Em caso afirmativo, este é provavelmente o correio de saída. Nas redes de hoje, a parte de conexão já deve ter habilitado a criptografia (STARTTLS) e autenticado com sucesso - se não, a conexão pode ser terminada aqui. (Clientes não compatíveis com autenticação em redes internas confiáveis podem ser explicitamente incluídos na lista de permissões para ignorar o requisito de autenticação crypto +).

• Se o endereço MAIL FROM: reivindicado não estiver dentro do (s) domínio (s) para o qual este servidor de e-mail é responsável, este deve ser o e-mail de entrada - é o endereço RCPT TO: nos domínios que este servidor de e-mail deve manipular mail para? Se não, esta é uma tentativa de abuso de retransmissão - > terminar a conexão.

Após essas verificações, a conexão é provavelmente legítima o suficiente para que DATA possa ser aceito e as verificações de SPF / DKIM / DMARC e de lista negra mais envolvidas sejam iniciadas. Não há autenticação SMTP universal entre MTAs de organizações diferentes.

Há também uma opção de lista cinza: se essa for a primeira conexão de um endereço de origem desconhecido, a tentativa de correspondência poderá ser rejeitada imediatamente com um código de erro de "falha temporária". Um servidor legítimo aguardará um pouco e fará uma nova tentativa. Se um período de tempo mínimo especificado tiver passado desde a primeira tentativa, o MTA receptor processará agora o email de entrada normalmente e, se o email passar em todas as outras verificações, conexões posteriores da mesma fonte serão aceitas sem o atraso inicial. / p>