Estou enviando e-mails recebidos para um script PHP, imediatamente armazenando o e-mail RAW em um banco de dados MySQL. Funciona muito bem, exceto que ~ 0,7% dos e-mails chegam com um corpo de mensagem truncado.
Encontrei alguém cujos e-mails estavam falhando e mandei um e-mail para minha conta do Gmail e para o servidor. Gmail não teve problemas, eu vi a mensagem inteira. Mas meu servidor cortou a mensagem bruta assim:
Delivered-To: [email protected]
Received: by 10.152.1.193 with SMTP id 1csp3490lao;
Mon, 20 Oct 2014 05:33:31 -0700 (PDT)
Return-Path: <[email protected]>
Received: from vps123.blahblah.com (vps123.blahblah.com. [74.124.111.111])
by mx.google.com with ESMTPS id fb7si7786786pab.30.2014.10.20.05.33.30
for <[email protected]>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Mon, 20 Oct 2014 05:33:30 -0700 (PDT)
Message-ID: <14FBD481E1074C79AF3D@acerDator>
From: =?utf-8?Q?sende=C3=A4r?= <[email protected]>
To: "test" <[email protected]>
References: <[email protected]>
Subject: Message body will contain only Det h
Date: Mon, 20 Oct 2014 14:33:24 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0018_01CFEC72.CE424470"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 14.0.8117.416
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
X-Source:
X-Source-Args:
X-Source-Dir:
Det här är ett flerdelat meddelande i MIME-format.
------=_NextPart_000_0018_01CFEC72.CE424470
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
This email will not be received correctly. EXIM may not handle =
some poorly formed emails. For example ...
Det h=E4r =E4r ett flerdelat meddelande i MIME-format.
... is directly above this quoted-printable wrapper, thanks to the =
Swedish email client Microsoft Windows Live (circa 2009), adding UTF-8 =
chars where there should only be ascii. At least, that's what I think =
the problem is.
------=_NextPart_000_0018_01CFEC72.CE424470--
Meu servidor corta a mensagem imediatamente antes do primeiro caractere estrangeiro. Os dados brutos armazenados contêm os cabeçalhos, uma linha em branco, "Det h" e nada mais.
Quando eu canalizo o email acima para o script PHP no shell ( /blah/email_in.php < bademail.txt ), e ele armazena a mensagem perfeitamente. Então eu não acho que meu script é a culpa, ele armazena o STDIN bruto corretamente.
Eu usei o cPanel para "Set Default Address" para "Pipe to a program". Eu não sei se essa configuração ignora o EXIM completamente, mas eu li em algum lugar que o EXIM manipula o transporte de pipe, então meu primeiro palpite é que o EXIM está desconcertando uma mensagem mal formatada e sufocando o fluxo no primeiro caractere unicode ä .
Para confirmar isso, eu preciso de uma maneira de mandar um e-mail para INTO EXIM, basicamente enganando o EXIM pensando que ele acabou de receber um e-mail quando na verdade ele acabou de receber um arquivo txt. Eu encontrei vários tutoriais sobre como fazer telnet para a porta 25, etc, mas nada que preservaria os cabeçalhos, multipartidos limites, nem que fizesse sentido para um unix n00b como eu, que depende do cPanel.
Estou certo de que o EXIM é o provável culpado?
Alguém pode sugerir uma maneira de testar isso, ou uma abordagem alternativa?
Meu servidor executa o EXIM + Dovecot no CentOS 6.5.
p.s. Meu único outro pensamento é deixar o servidor armazenar mensagens normalmente, e se essas mensagens forem magicamente armazenadas corretamente, usar o IMAP para recuperar / excluir as mensagens, em vez de ir diretamente para o pipe ... parece menos eficiente para adicionar o intermediário IMAP, embora essa abordagem seja provavelmente mais robusta.