Por que o Postfix aceita MAIL FROM de um e-mail não é responsável por

Question

Estou testando uma instalação de postfix. Percebi que, se eu tentar enviar mensagens de uma conta fictícia em outro domínio que não seja meu ( [email protected] ), para um dos meus usuários locais ( [email protected] ), o email ainda será entregue ao meu usuário.

MAIL FROM:<[email protected]>

RCPT TO:<[email protected]>

Não tenho certeza se isso é um comportamento normal ou se pode causar problemas. Por exemplo, estou preocupado que os usuários possam usar o servidor para enviar e-mails falsificados que não sejam originários das contas de e-mail que eles dizem ser originários.

P.S. Ainda estou nos estágios iniciais do aprendizado do postfix, então não tenho certeza se minha pergunta faz sentido.

Conforme o comentário de @ DerfK, testei uma retransmissão aberta (em que MAIL FROM e RCPT TO não estão hospedados neste servidor), e é isso que recebo. Por alguma razão, aceita o RCPT TO , depois diz adeus DEPOIS eu digito o assunto. Então, isso é bom ou ruim?

HELO test.mydomain.com
250 mail
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
Subject: testing for open relay
221 2.7.0 Error: I can break rules, too. Goodbye.
Connection closed by foreign host.

    

Answer 1

Isso é um comportamento normal. Outros servidores SMTP se conectam ao seu como clientes SMTP para entregar e-mails em seu domínio.

Para contornar esse problema de falsificação, há SPF e DKIM. Você deveria vê-los.

    

Answer 2

Em relação à sua primeira situação: é normal que o servidor SMTP aceite e-mails para contas pelas quais é responsável e basicamente é assim que funciona, apenas configure o software de verificação de spam como o SpamAssassin (solução livre mais usada, suporta SPF / DKIM verifique).

No que diz respeito à sua pergunta provavelmente no estágio inicial da configuração do servidor de e-mail, veja algumas dicas relacionadas a mensagens fictícias.

Os usuários normais não tentam falsificar seus e-mails na maioria dos casos. Mais frequentemente, este é o comportamento do spammer, e é por isso que você pode filtrar esse e-mail com base em seu conteúdo. Uma configuração mais complexa pode incluir:

1. verificação de RBL / DNSBL / RHSBL (pode dar muitos rejeitos falsos porque muitos dos remetentes de correio válidos até mesmo quebram alguns dos RFCs). / li>
2. Verificação do endereço do remetente (consulte Leiame da verificação de endereço para o Postfix). Isso também pode rejeitar alguns e-mails válidos (basicamente, novamente por causa de uma configuração incorreta, por exemplo, desautorizando o e-mail com MAIL FROM: <> vazio).
3. Greylisting . Quanto à minha experiência pessoal, isso combate até 90% dos emails de spam por causa da impaciência dos spammers. Mas isso atrasa a entrega de emails válidos, mas isso não é um problema na maioria dos casos.
4. Verificação de SPF / DKIM (embora não obrigatória para suportá-lo).
5. Várias verificações de conteúdo personalizadas (incluindo os spamcheckers já mencionados).

Se falamos de postfix, ele oferece habilidades bastante flexíveis para restringir quais mensagens são aceitáveis.

Com relação à sua atualização: o postfix da mensagem de erro fornece apenas estados que você quebra as especificações do SMTP (não há nenhum comando Subject: SMTP, consulte SMTP RFC mas Subject cabeçalho que você provavelmente quis dizer é parte do corpo da mensagem que deve ser fornecido após o comando DATA SMTP). A partir da transcrição que você forneceu, não posso dizer com segurança se o seu postfix funciona como retransmissão aberta porque não há informações sobre o cliente que teve essa sessão SMTP.

Com postfix de configuração básica, tanto quanto me lembro, permite a retransmissão de email (o que significa que você pode especificar qualquer endereço de email, não apenas no domínio pelo qual o postfix é responsável):

• localhost
• redes confiáveis (definidas via mynetworks)

Então, se você tiver telnetado o postfix do servidor, ele será executado, o que pode ser bom. Se de qualquer lugar na Internet, as coisas estão ruins.

Além disso, leia atentamente o SMTPD Relay e o controle de acesso para aprofundar o conhecimento exatamente no tópico de acesso ao relé postfix .

Espero que isso ajude.

    

Answer 3

Você esqueceu os dados! Eu tive exatamente esse problema. Você tem que ter dados de comando, então assunto. Então resolve seus problemas. Veja assim:

HELO test.mydomain.com

250 mail

MAIL FROM:<[email protected]>

250 2.1.0 Ok

RCPT TO:<[email protected]>

250 2.1.5 Ok

Data

354 End data with <CR><LF>.<CR><LF>

subject: hello

i love you, oh my god! Why do i forget data

.

250 2.0.0 Ok: queued as E10601E09B1

quit

    

Answer 4

O postfix deve aceitar emails de domínios pelos quais não é responsável. Caso contrário, você teria apenas um e-mail local.

Um retransmissor aberto aceita e-mails de domínios aos quais não é responsável os endereços pelos quais não é responsável. Na tabela a seguir: Local representa os domínios pelos quais o servidor é responsável; Remoto representa os domínios pelos quais o servidor não é responsável; e Nenhum representa um remetente vazio:

Source   Destination   Accepted
======   ===========   ========
Local    Local         Yes
Local    Remote        Yes
Remote   Local         Yes
Remote   Remote        NO
None     Local         Yes
None     Remote        NO

Existem várias maneiras de verificar o domínio remoto, incluindo: frases de destaque, SPF, DMARC, listas brancas e listas negras. Tudo isso depende do DNS. Greylisting é uma técnica para garantir que um servidor de e-mail real esteja enviando o e-mail em vez de um spambot. Spamfilters como o Spamassassin usam uma combinação de técnicas para validar o e-mail, o que geralmente inclui a pontuação dos testes acima, bem como o conteúdo e os cabeçalhos.