Exim 4.69 negando o correio de saída devido a EHLO sintaticamente inválido (bizarro pseudo-MAC FQDN)

Question

Desde ontem (novo roteador, que eu suspeito ser a causa raiz), um cliente está tendo problemas para enviar e-mails. Receber é bom, apenas a saída está constantemente falhando.

Principal log-in do Exim do Tailing, este é o EHLO sendo apresentado e o motivo pelo qual o Exim está retrocedendo:

2013-03-09 15:07:00 SMTP connection from host109-155-115-197.range109-155.btcentralplus.com (unknown-68:a8:6d:03:cf:6e.home) [109.155.115.197]:52877 

seguido por

rejected EHLO from host109-155-115-197.range109-155.btcentralplus.com [109.155.115.197]:52848 I=[213.229.88.78]:587: syntactically invalid argument(s): unknown-68:a8:6d:03:cf:6e.home  

Adicionando um ponto-e-vírgula ao helo_allowed_chars no exim.conf, o fluxo de e-mails é o esperado:

Recebido: do host109-155-115-197.range109-155.btcentralplus.com ([109.155.115.197]: 52913 helo = desconhecido-68: a8: 6d: 03: cf: 6e.home)

O cliente de email em questão é o Mail.app,

Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)

Acho que minha pergunta é tripla:

1. Por que os hubs domésticos da BT geram esses FQDNs claramente sem sentido?
2. Por que a OSX aceita cegamente qualquer nome de host local estranho e não compatível?
3. Por que o Mail.app aceita cegamente esse nome de host local estranho e não-compatível ao enviar e-mail de saída - embora seja claramente ilegal e falhe em uma verificação RFC?
4. Por que não vejo esse problema com mais frequência? Esta é a primeira vez que alguém diz que o e-mail de saída não está funcionando e configurei e-mails em muitos Macs usando o Mail.app, todos os quais estão enviando e recebendo alegremente enquanto digito. (Eu posso vê-los no Exim's mainlog .)

Procurando por outro tráfego do BT Home Hub, posso ver uma conexão de entrada usando um cujo EHLO parece mais padronizado:

2013-03-07 20:04:17 H=host81-156-4-96.range81-156.btcentralplus.com (BThomehub.home)

Não se sabe se é um Mac ou PC, mas vem do fora .

Estou no processo de atualizar este servidor para as últimas compilações estáveis, incluindo o Exim (ele está atualmente em execução 4.69). Eu não quero deixar este hack RFC no lugar no conf Exim, deve haver uma maneira mais limpa de fornecer para este problema se um usuário apresenta credenciais válidas.

Todo cliente de Banda Larga da BT que usa um Mac realmente encontra esse mesmo problema com os e-mails facilitados pelo Exim - e eles simplesmente não percebem isso? Eu tive que trabalhar com os Home Hubs antes de incluir os Macs no ambiente e nunca vi um endereço pseudo-MAC como unknown-68:a8:6d:03:cf:6e.home atribuído a um dispositivo de rede, eu normalmente só via nomes de host mapeados para dispositivos como esse na seção LAN de um roteador, onde ele não pode detectar o tipo de dispositivo ou o nome do host, apenas mostra seu endereço MAC com a sujeira padrão anexada e anexada.

Mais premente é tentar descobrir por que esses dados devem ser apresentados a um servidor de e-mail, não desejo suportar esse hack por muito mais tempo. Eu não posso nem garantir que funcionará após uma atualização do Exim, mas não tenho intenção de adiar uma atualização do servidor para suportar um cliente não compatível.

    

Answer 1

Parece que, de alguma forma, alguém não definiu um nome de computador para o Mac. Tente fazer com que o cliente defina um nome de computador indo em Preferências do Sistema e em Compartilhamento.

    

Answer 2

Leia a mensagem # 24 no link . A mensagem # 26 também tem um teste / correção um pouco mais fácil, onde ele diz:

change the 'Computer Name' to have only letters and numbers - no spaces or punctuation/special characters

e.g. I had "Ian's MacBook Air" and changed to "iansmacbookair"

REBOOT the mac

SMTP will burst into life

Em seguida, ele diz que você pode alterá-lo de volta para o que quiser, porque o roteador só tenta resolver o nome do host uma vez. Ele não declarou se isso sobreviveu a um ciclo de energia do roteador, mas eu aposto que não, então você teria que repetir toda vez que o roteador fosse desligado. Para mim, a questão # 24 é a correção melhor e mais adequada a longo prazo.