host inteligente não entrega o email se o cabeçalho da data for enviado?

Question

Eu uso o MantisBT 1.2.6 em um servidor Amazon Linux. Ele tem sua própria classe de envio de e-mail sobre a função mail () do PHP. Na verdade, ele tem outras opções para usar o smtp ou sendmail diretamente, mas eu uso o email PHP. Então, o correio PHP, por sua vez, usa o sendmail.

Configurei o sendmail para usar um host inteligente, que estava funcionando bem, pois eu poderia escrever um pequeno programa PHP para enviar uma mensagem com sucesso por meio de sua função mail ().

Mas os e-mails enviados pelo MantisBT nunca chegaram e não retornaram.

/var/log/maillog mostrou que as mensagens MantiBT foram enviadas para o smarthost com sucesso

(relay=my-smarthost-hostname) with "stat=Sent (ok nnnn qp nnnn)"

Se eu mudei o arquivo / etc / mail / authinfo para usar a senha errada, maillog mostrou "stat = Service unavailable" para aquele relay.

Então parecia que o problema tinha que ser algo sutil no código do MantiBT. Eu usei o xdebug para encontrar a chamada feita para o mail (), e obter os valores de seus parâmetros, e extraí-los para um arquivo php separado para brincar. Ele passou vários cabeçalhos além de "From:" no quarto parâmetro, e eu suspeitei que eles pudessem ter sido separados apenas \ n em vez de \ r \ n como o RFC (2) 821 exige, o que causou o problema . Mas eu adicionei código para alterar \ n para \ r \ n na string de cabeçalho e isso não fez diferença.

No final, o que causou o problema foi a presença de um cabeçalho "Date:" (correto). Quando removi esse cabeçalho do quarto parâmetro para mail (), o email foi entregue imediatamente. Então eu editei a fonte MantisBT para não gerar esse cabeçalho, e tudo estava bem (eu também editei a fonte MantisBT para não colocar um espaço entre a opção "-f" e o endereço do remetente).

Portanto, minha pergunta é se a presença de um cabeçalho "Data:" no quarto parâmetro para mail () é conhecida por causar um problema no envio de um smarthost. Com uma continuação de, você não esperaria nem uma rejeição ou uma mensagem no maillog se o smarthost não gostasse de ver o cabeçalho da Data?

PS Na verdade, liguei para o suporte técnico da Network Solutions quando vi a mensagem ok enviada no maillog, mas antes de isolá-la no cabeçalho Date. Naturalmente que não resultou em nada útil, apenas instruções de como configurar seu cliente de email para POP ou IMAP: -)

    

Answer 1

Aparentemente, tenho sido atacado pelo petardo de minha própria metodologia.

Parece agora que o motivo pelo qual o cabeçalho de data fez com que a mensagem fosse aceita pelo host inteligente sem ser entregue é que eu não alterei o registro de data e hora no cabeçalho com cada teste. Assim, o host inteligente viu várias mensagens com IDs de mensagem e carimbos de data e hora idênticos chegando, e simplesmente não forneceu as duplicatas.

No processo de fazer as coisas funcionarem, eu tinha visto erros nos quais a opção -f estava sendo usada como endereço do destinatário (talvez por causa do espaço entre o "-f" e o endereço do remetente) e outros problemas. Então é possível que quando eu consertei esse material, uma mensagem tenha passado bem. Mas, em seguida, tenta confirmar que o sucesso ficou preso na armadilha de mensagem duplicada. Na vida real, é claro, o timestamp nunca será duplicado junto com o ID da mensagem, que era apenas um artefato de capturar os parâmetros sendo passados para mail () em um testcase estático independente.

De qualquer forma, acho que estou tudo pronto agora, e restaurarei o cabeçalho da Data para o código MantisBT.

Não tendo jogado muito com o envio de e-mails antes, essa foi uma experiência de aprendizado para mim. E talvez isso seja útil para outra pessoa, saber que, se você quiser testar as mensagens de saída, não poderá usar cabeçalhos fixos com invariantes códigos MessageID e Date!