вызывает ли программа электронной почты проблемы с символами Юникода?

Я перенаправляю входящую почту в PHP-скрипт, сразу сохраняя RAW-сообщение в базе данных MySQL. Он работает очень хорошо, за исключением того, что ~ 0,7% писем приходит с усеченным телом сообщения.

Я нашел кого-то, чьи электронные письма не работали, и попросил их отправить электронное письмо НА мою учетную запись gmail И на сервер. У Gmail проблем не было, я все сообщение видел. Но мой сервер обрезал необработанное сообщение следующим образом:

Delivered-To: asdasd@gmail.com
Received: by 10.152.1.193 with SMTP id 1csp3490lao;
        Mon, 20 Oct 2014 05:33:31 -0700 (PDT)
Return-Path: <sender@test.com>
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 <asdasd@gmail.com>
        (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?= <sender@test.com>
To: "test" <test@asdasd.com>
References: <CAEMnOreG=99=qxBdSav5WP303BA@mail.gmail.com>
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--

Мой сервер обрезает сообщение непосредственно перед первым иностранным символом. Сохраненные необработанные данные содержат заголовки, пустую строку, «Det h» и ничего больше.

Когда я перенаправляю вышеуказанное электронное письмо в PHP-скрипт в оболочке (/blah/email_in.php < bademail.txt), и он отлично хранит сообщение. Поэтому я не думаю, что мой скрипт виноват, он правильно хранит необработанный STDIN.

Я использовал cPanel, чтобы «Установить адрес по умолчанию» на «Канал в программу». Я не знаю, полностью ли обходит этот параметр EXIM, но я где-то читал, что EXIM обрабатывает конвейерный транспорт, поэтому мое первое предположение состоит в том, что EXIM искажает плохо отформатированное сообщение и блокирует поток первым символом Unicode. ä.

Чтобы подтвердить это, мне нужен способ передачи электронной почты В EXIM, по сути, обманывая EXIM, заставляя думать, что он только что получил электронное письмо, когда на самом деле он только что получил текстовый файл. Я нашел несколько руководств о том, как подключиться по telnet к порту 25 и т. Д., Но ничего, что сохраняло бы заголовки, составные границы, и это не имело смысла для unix n00b, как я, который полагается на cPanel.

Правильно ли я говорю, что вероятным виновником является EXIM?
Может ли кто-нибудь предложить способ проверить это или альтернативный подход?

Мой сервер работает под управлением EXIM + Dovecot на CentOS 6.5.

p.s. Моя единственная другая мысль - позволить серверу хранить почту в обычном режиме, и если эти сообщения волшебным образом хранятся правильно, использовать IMAP для извлечения / удаления сообщений, а не напрямую в канал ... кажется менее эффективным, чтобы добавить посредника IMAP, хотя этот подход, вероятно, более надежен.