☰

电子邮件管道传输到程序是否会导致 Unicode 字符出现问题？

tag-icon • tag-icon email exim pipe
电子邮件管道传输到程序是否会导致 Unicode 字符出现问题？

我将收到的邮件导入 PHP 脚本，立即将原始邮件存储在 MySQL 数据库中。它运行良好，但约 0.7% 的邮件正文被截断。

我发现某人的电子邮件出现故障，并让他们向我的 Gmail 帐户和服务器发送了一封电子邮件。Gmail 没有问题，我看到了整封邮件。但我的服务器将原始邮件裁剪如下：

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--

我的服务器会截断第一个外来字符之前的消息。存储的原始数据包含标题、空白行、“Det h”，没有其他内容。

当我将上述电子邮件导入到 shell ( /blah/email_in.php < bademail.txt) 中的 PHP 脚本时，它会完美地存储消息。因此，我认为我的脚本没有问题，它正确地存储了原始 STDIN。

我使用 cPanel 将“默认地址”设置为“管道到程序”。我不知道这个设置是否完全绕过了 EXIM，但我读到过 EXIM 处理管道传输，所以我的第一个猜测是 EXIM 正在破坏格式错误的消息，并在第一个 unicode 字符处阻塞流A。

为了证实这一点，我需要一种方法将电子邮件传输到 EXIM，基本上就是欺骗 EXIM 认为它刚刚收到了一封电子邮件，而实际上它刚刚收到了一个 txt 文件。我找到了几个关于如何远程登录到端口 25 等的教程，但没有一个可以保留标题、多部分边界，而且对于像我这样依赖 cPanel 的 unix 新手来说也没有意义。

我说的 EXIM 可能是罪魁祸首，对吗？
有人能建议一种测试方法吗，或者有其他方法吗？

我的服务器在 CentOS 6.5 上运行 EXIM + Dovecot。

ps 我唯一的另一个想法是让服务器正常存储邮件，如果这些消息神奇地正确存储，则使用 IMAP 来检索/删除消息而不是直接进入管道......添加 IMAP 中间人似乎效率较低，尽管这种方法可能更强大。

答案1

你可能想尝试斯瓦克斯：

  swaks --to [email protected] --server your-server.example.net -d your_mail_with_headers.txt

当然，其中your_mail_with_headers.txt包含原始消息（标题、正文、MIME 等）的文件

但是，我认为 exim 管道不应该是问题所在（事物通常不加修改地通过管道，甚至是二进制字符串）；更可能的是，你的脚本在 shell 上和通过管道时的行为不同（例如，由于LANG环境LC_ALL变量等）

相关内容