Claws Mail 不识别 PHPMailer 发送的附件

环境:Claws Mail 3.9.1, PHP 5.4.16, PHPMailer 5.2.6 c5e9f7873f

现象:PHPMailer 发送带附件的邮件,直接使用 AddAttachment() 方法

$mailer->AddAttachment($attach_file);

没有其他设置。Claws Mail 收到信以后,查看邮件内容为空白, 附件栏显示:

message/rfc822
    multipart/mixed

以下就是空白了。 而能够正常识别附件的邮件,附件栏内容一般为:

message/rfc822
    multipart/mixed
        text/plain
        text/html   (这个是附件的 mime 类型)

gmail 和 mutt 中识别这样的邮件是正常的。

分析:通过对比正常和不正常的邮件原始码, 发现不正常邮件在声明内容是分节之后,多了一句传输编码声明,比如:

Content-Type: multipart/mixed;
    boundary="b1_95a848b14cb4385965320b915d5829dd"
Content-Transfer-Encoding: base64

最后的 Content-Transfer-Encoding 就是比正常邮件多的一行。

由于邮件原始码的这个部分,只是用来声明后续邮件是多个部分组成, 并定义了每个部分的辨识边界 boundary,并没有实际的内容, 所以应当是不需要声明编码类型的。在 PHPMailer 中相关代码为:

  public function GetMailMIME() {
    $result = '';
    switch($this->message_type) {
      case 'inline':
        $result .= $this->HeaderLine('Content-Type', 'multipart/related;');
        $result .= $this->TextLine("\tboundary=\"" . $this->boundary[1].'"');
        break;
      case 'attach':
      case 'inline_attach':
      case 'alt_attach':
      case 'alt_inline_attach':
        $result .= $this->HeaderLine('Content-Type', 'multipart/mixed;');
        $result .= $this->TextLine("\tboundary=\"" . $this->boundary[1].'"');
        break;
      case 'alt':
      case 'alt_inline':
        $result .= $this->HeaderLine('Content-Type', 'multipart/alternative;');
        $result .= $this->TextLine("\tboundary=\"" . $this->boundary[1].'"');
        break;
      default:
        // Catches case 'plain': and case '':
        $result .= $this->TextLine('Content-Type: '.$this->ContentType.'; charset='.$this->CharSet);
        break;
    }
    //RFC1341 part 5 says 7bit is assumed if not specified
    if ($this->Encoding != '7bit') {
      $result .= $this->HeaderLine('Content-Transfer-Encoding', $this->Encoding);
    }

特意加上了这个申明,因为按照 RFC1341,7bit 编码类型是默认的。

解决: 或许问题是出在 Claws Mail 上,但我暂时只能修改 PHPMailer 来适应这个问题了。 上面的问题弄清楚之后,在 multipart 后面不添加传输编码声明即可:

    //RFC1341 part 5 says 7bit is assumed if not specified
    // Not after multipart/mixed, claws-mail will not recoginize attachment
    if (($this->Encoding != '7bit') && (!in_array($this->message_type, array(
        'attach',
        'inline_attach',
        'alt_attach',
        'alt_inline_attach',
    )))) {
      $result .= $this->HeaderLine('Content-Transfer-Encoding', $this->Encoding);
    }

同步 Claws Mail 的回收站到邮件服务器

Gmail 依然是经常抽风,没办法了,只好弄个客户端用, 至少工作的时候用起来比较方便,不用老是等待、重试。

我的使用模式比较复杂,简单描述如下: 工作邮箱主要从 Web 和 Mutt 客户端访问, 主要作用一个是搜索浏览,一个是存档。 所有邮件还会自动转发到另外一个个人邮箱, 这个邮箱使用 Claws Mail 客户端下载,本地管理。 日常工作中,以个人邮箱的客户端为主, 工作邮箱的 Web 界面为辅。

这篇文章所解决的问题就是, 在 Claws Mail 客户端中删除邮件后, 实现这些邮件在上述两个邮箱中也删除到回收站。 用于处理一些垃圾邮件和确定不再需要的正常邮件。

如果用 IMAP 客户端来管理可以达到同样效果, 但我的邮件比较多, IMAP 太慢了,动不动就要刷新上千封邮件信息, 耗不起。

闲话扯完,下面来讲处理思路和一些心得, 希望直接找结果的请猛击 imap-del-for-mh.php ,运行环境中需要包含 Fwlib

  1. 定位邮件文件

    Claws Mail 使用 MH 格式存储邮件, 一封邮件对应一个文件, 一个目录就对应 Claws Mail 中的一个目录, 结构非常清晰。

  2. 连接邮件服务器

    由于邮件都已经使用 POP3 方式下载过了, 所以这里只能采用 IMAP 方式连接了(不然列不出邮件)。 连接 Gmail 不敢说快,倒也能够接受。

  3. 解析邮件文件,找出用于在服务器上定位邮件的必要信息

    读文件,用正则。 IMAP 中查找邮件所用时间是 d-M-Y ,减号可以省略, 比如 11-May-2013 或者 11 May 2013 。 From 和 Subject 中可能会有非英文字符,需要进行转码。 Message-ID 应该是邮件的唯一标识, 但不是是否因为其包含了部分隐私信息的原因, IMAP 服务器没法依据它来检索邮件。

  4. 第一次查找、比对邮件

    由于 IMAP 并没有提供准确查找、定位邮件的方法, 所以只能按照各种条件来检索邮件, 然后一封封的检查 Message-ID, 看与本地邮件文件中是否一致。

    第一次查找邮件使用 From 发件人和 Date 邮件时间, 尝试过使用 Subject 邮件标题, 反正有可能搜索不到, 原因大概是无法依据其中的中文进行模糊匹配。 From 也是只使用 <> 尖括号以内的部分,更准确。 Date 检索条件稍微麻烦一点,PHP 文档中有 ON date 方法, 但实际没法用,所以使用的是 SINCE [前一天] BEFORE [后一天] 。 由于无论怎么检索都无法匹配, 转而寻找“一定”包含指定邮件的最小结果集。

    这种方式能够匹配到大部分正常发送的邮件。

  5. 第二次查找、比对邮件

    一些不正常邮件,尤其以各类垃圾邮件为代表, 存在着信息不全、时间不对等稀奇古怪的问题, 所以如果第一次没有找到,再换条件补查一次。 这次使用的是邮件头中的 Recieved 接收时间, 这是邮件服务器接收到这封邮件的时间, 然后以这个时间为基准, 在 前一天、后一天 的范围内查找邮件、逐一匹配。 虽然速度要慢一些, 但理论上所有邮件采用这种方式都能找到。

  6. 删除邮件

    通过 Message-ID 匹配准确定位到邮件后, 便得到了邮件的 UID。 UID 和 msgid 是不同的,msgid 是在某一目录或者列表下的序号, 而 UID 才是 IMAP 下邮件的唯一编号。 不过邮件被删除到回收站,再从回收站恢复的时候, UID 也是会改变的。

    Gmail 的 IMAP delete 操作和一般的“删除”含义并不同, 只是把邮件从 Inbox 中去除了,跑到 All Mails 里面了, 所以把邮件先 move 到 trash 目录下,再进行 delete, 最后执行 expunge 操作。

最后回想一下,如果一次性把所有邮件头都读取出来, 再和本地的 Message-ID 进行对应, 在需处理邮件相当多的情况下应该会有总体效率的提升, 但不适用于我这个场景

如果 IMAP 能够直接使用 Message-ID 来精确匹配, 那就省事多了。

-EOT-

一直在忙,聊以凑数。

参考