Mensagens devolvidas que não atingem o postfix

1

Tenho o postfix e o dovecot instalados em uma máquina de produção Centos 6.4 (www.bw.co.uk). A intenção é enviar todas as mensagens do sistema e transacionais e coletar devoluções. Os IDs de e-mail que resultaram em uma rejeição são sinalizados para impedir que o site envie mais mensagens para esses IDs.

Eu tenho a configuração dos registros SPF necessários na configuração dos registros DNS e PTR no final dos provedores de hospedagem. Meus registros MX apontam para um servidor de e-mail diferente, onde nossa equipe envia e recebe e-mails.

Meu problema é que consegui enviar e-mails da máquina de produção. Não consigo ler as devoluções usando meu fragmento de php. Na verdade, nem sei se os saltos estão chegando à máquina!

Eu tenho uma configuração semelhante na minha máquina de teste (www.st.biz) com o mesmo provedor de hospedagem. Os registros MX, SPF e PTR são configurados de forma semelhante, ou seja, os registros MX apontam para outro servidor de email onde a equipe envia e recebe correspondência. Na máquina de teste, eu posso ler os bounces usando o programa PHP.

Os logs de postfix / var / log / maillog na máquina de produção indicam uma única rejeição que não foi iniciada pelo programa php que envia as mensagens transacionais     03 de março 03:15:03 bw postfix / smtp [22338]: 09420120CA3: para =, relé = mail.st.in [999.999.999.999]: 25, atraso = 0,9, atrasos = 0,05 / 0,02 / 0,43 / 0,41, dsn = 4.7.1, status = deferred (host mail.st.in [999.999.999.999] disse: 451 4.7.1 Por favor, tente novamente mais tarde (em resposta ao comando DATA))

Alguma ideia do que poderia estar errado?

    
por sridhar pandurangiah 03.03.2014 / 04:28

2 respostas

2

Os retornos serão devolvidos ao sistema de retransmissão. Você deve providenciá-lo para encaminhar as devoluções de volta ao seu sistema para processamento. Pode ser mais simples processar as rejeições do que fazer com que os bounces sejam encaminhados de volta para o seu sistema.

Use um endereço de e-mail de envio específico no formato "[email protected]". Deve estar em um domínio ou subdomínio apropriado para seu aplicativo.

No processamento normal, você pode esperar que alguns emails permaneçam enfileirados por um longo tempo antes de serem rejeitados. Normalmente, isso estará no intervalo de 4 a 7 dias.

Alguns sistemas aceitam o e-mail antes de decidir se o entregará ou não. Se eles forem bem comportados, você não verá rejeições deles, pois correm o risco de gerar spam de backscatter se eles enviarem uma mensagem de devolução.

EDIT: Espero que seu e-mail seja enviado usando o servidor MX, que parece ser um servidor diferente do servidor da web. (O e-mail enviado de www. domains é incomum e, na minha experiência, provável spam.) Usar um segundo domínio no mesmo servidor para enviar e-mails pode ser mais apropriado. Nenhum dos domínios que você descreve parece ser válido, por isso não posso confirmar sua configuração.

Se você quiser que as rejeições permaneçam no seu servidor da Web, use-o como o MX para si mesmo ou apenas omita o registro MX. Configure um endereço postmaster que possa ser usado para enviar informações sobre problemas de configuração. Da mesma forma, um endereço abuse é recomendado para que os relatórios de abuso possam ser enviados para você. Ambos podem ser encaminhados para usuários no domínio MX a que você se refere.

    
por 03.03.2014 / 05:06
1

Bill está certo sobre o registro MX que está causando o e-mail não retornado. Basicamente, embora o SPF permita que você envie mensagens, e o registro PTR confirme, o registro MX apontando para outro servidor significa que retornos serão enviados para lá.

Quando o servidor de e-mail remoto tiver que devolver o e-mail, ele fará uma pesquisa de MX em seu domínio e enviará o e-mail para esse registro. Então, todos os seus saltos serão voltados para esse servidor.

Você pode criar um subdomínio em seu servidor e criar um alias na máquina com o registro MX, [email protected] = > %código%. Dessa forma, você receberá todos os saltos.

    
por 05.03.2014 / 11:18