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-

一直在忙,聊以凑数。

参考

Apple Mail 邮件太多不下载问题的解决

Apple Mail version3.6(936)

原先拿到这个 mac 本本的时候,由于家中网速比较慢,收发邮件比较折磨人,而我又属于对邮件依赖较重的,所以专门申请了个新的 gmail 帐号,专门用在这个机器上,把邮件下载到本地便于处理(平时个人邮件都是自己发给自己的 N 个邮箱共享),顺便体验下 Apple Mail 软件。

Apple Mail 倒算是中规中矩,按下不表,中间有一段时间没怎么用这台 mac,而这个专用 gmail 帐号里面堆积的邮件应该也不少了,简单估计有几百封吧。终于,等到我想用的那一天,突然发现它不下载新邮件了。

逐项检查,系统和软件工作正常,网络正常,gmail 登录进去肯定是有新邮件,而且 pop 设置正常。所有的东西都没有动过,并且原先刚设置好这个帐号的时候,邮件下载都是正常的。Command+0 打开 Activity 窗口监视──连接、登录、查找新邮件、退出,貌似正常,但完全无视我邮箱中赫然在目的新邮件哪。

纯属无意中翻看 gmail 的在线帮助,其实对这类帮助并不报太大希望的,因为一般上面只有一些常规问题的答案,我的问题比较蹊跷,八成没有。帮助里面专门有针对 Apple Mail 3.0 Troubleshooting,列了几个问题,对照我的情况,逐个回答如下:

  • Have you recently used Gmail’s POP service with this client and address?
  • --> Yes, this address just worked recently
  • When are you encountering problems?
  • --> Downloading
  • Does your client display an error?
  • --> No, my mail client does not show an error
  • Downloading issues
  • --> Some or all messages don’t download

然后帮助给了4个解决方法,其中第2条是亮点:

Try enabling recent mode in your POP client by replacing 'username@gmail.com'
in the Username field of your POP client settings with 'recent:username@gmail.com',
and uncheck the box next to Remove copy from server after retrieving a message
in your Advanced POP client settings. Recent mode fetches the last 30 days of mail,
regardless of any other factors. If you don't Leave messages on server your 
messages will be moved to Trash after download.

看仔细了,在邮件帐户前面加上 recent:,只下载最近30天的邮件,这个以前没听说过,从之,我的邮件又愉快的下载了。至于30天以前的邮件如何下载,我是不需要了。至于为什么会这样,还真不明白是 gmail 这里有限制,还是 Apple Mail 无法读取30天以前邮件的邮件头导致无法下载,希望有明白人指点一二。

附 gmail 帮助截图为据:

Gmail帮助中关于Apple Mail的Troubleshooting

Wine下运行的广发委托系统退出时可能会误删mail目录

这个问题不是第一次出现了,网上也查不到相关资料,所以感觉有必要说一说,看有没有和我同样遭遇的朋友。

用wine运行广发委托软件,是比较老的版本了,用起来没什么问题的,新版wine下中文的表现还改进了:

stock_trade_client

偶尔的,好像是打开以后发呆时间比较长了更容易出现,点左上角“退出”按钮的时候,原本应该一下子就关闭的,突然变得迟钝、没有响应了。后来一检查,发现$HOME/mail下的文件都没了,把文件删完之后委托程序才正常关闭。

猜测是委托软件为了防病毒、盗号之类的,在进行安全检查的时候,会检查目录下有没有mail文件(因为一般盗号会采用生成邮件,然后发送到自己邮箱的方式),如果有就删除之。windows下一般人很少会用到mail目录的,用wine运行的委托软件不知怎地阴差阳错的就找到了系统默认的mail目录,文件还删得挺干净。

原先想过把mail放到别处,然后ln过来,可并不解决问题;并且mail这个目录也不宜放到别处,因为那样系统生成的邮件就放不过来了,比如crontab里程序运行的输出。

所以现在只能采取两个临时措施,以观后效。一是在用wine启动程序的时候,先cd到委托软件所在目录,即当前目录下就没有mail目录了;二是在winecfg里把到$HOME下的映射都删掉:

wine_remove_my_documents

话再说回来,在$HOME下操作其实也挺危险的,因为对于个人用计算机来说,系统坏了倒是小事,资料丢了才心疼呢。

[Mutt]用msmtp替代esmtp作发信代理

刚开始使用mutt的时候,由于也没有什么经验,在MDA选择方面抓了一个esmtp就用上了。说实话,esmtp也一直工作的很好,就是发信的时候需要傻傻等着(参见muttrc的sendmail_wait参数),如果不等待也可以,发送失败你就不知道了。虽然失败的情况比较少,一般都是邮件比较大或者网络不太好的情况才会发生,但我们外发的邮件往往都是比较重要的,真想有一种能够自动重试的发信代理,于是就查到了msmtp。

msmtpesmtp两个软件作者都不多,但msmtp确实更新频繁一些,而esmtp作者说现在已经不需要怎么添加功能了,只是维护bug。在多账户配置方面,好像msmtp的配置方法要“聪明”一些,账号规则有一些”继承”的小把戏。在发信队列方面,esmtp在Features中明显声明不支持,而msmtp有一个msmtpqueue,国内用的人非常少,只看到cu blog上提到了一点,smtpqueue能够把要外发的邮件集中在一起,单独发送,但没有说失败处理的事情;再到msmtp在sf.net上的cvs中查msmtpqueue的README文件,终于搞清楚了,和我的需要比较吻合。

msmtpqueue会”冒充”成一个MDA,当mutt发信时,它接收外发邮件并返回成功信息,而实际上只是把信件保存在QUEUEDIR里了,当调用msmtp-runqueue.sh的时候,再进行实际的发送处理。发送成功一封信,就会从QUEUEDIR中删除,发送失败就继续保持不动,下次再调用msmtp-runqueue.sh的时候自然又会处理(相当于重发)了。比起mutt中的邮件失败重发还会多生成一个邮件副本(我设定了发信的同时record在当前目录)应该是好多了。

Mails sent successfully will be deleted from the queue directory.
Mails whose delivery failed will be left untouched; you may want to edit
them, delete them by hand or simply run msmtp-runqueue.sh at a later time.

工作开始,首先通过apt安装msmtp,很小的,加上TLS/SSL所需的libgsasl7,一共才182k。然后配置账号文件~/.msmtprc,格式和~/.esmtprc比较类似:

# Default value for all following accounts
defaults
#      tls on
    tls_trust_file /etc/ssl/certs/ca-certificates.crt
#   keepbcc on
    logfile ~/log/msmtp.log

# Gmail
account gmail
    host smtp.gmail.com
    port 587
    auth on
    tls on

account mailbox@gmail.com : gmail
    from mailbox@gmail.com
    user "mailbox@gmail.com"
    password "secret"

# Another mail service
account another_mailbox@domain.com
    host smtp.domain.com
    auth on
    from another_mailbox@domain.com
    user "another_mailbox"
    password "another_secret"

# Default account
account default : mailbox@gmail.com

Copy自官方文档,语法很简单,最开始的defaults是默认设置,然后的account就是各个账号的设置了,账号名称最好和邮件中的From:对应,这样msmtp就能知道调用哪个账号了。最有意思的是,account可以用冒号:来”继承”其它已定义账号的设置,使用这个机制,就为所有gmail邮箱指定了host、port、auth、tls四个属性,然后在具体的账号设置中,只要再设定from、user、password就可以了,很方便,”继承”多个账号的话用逗号隔开。最后默认发信账号(匹配寻找account失败时使用)default可以直接”继承”某个账号的设置过来。

然后设置~/.muttrc,用msmtp来发信:

set sendmail="/path/to/msmtp"
set use_from=yes
set from="Fwolf <mailbox@domain.com>"
set envelope_from=yes
set sendmail_wait=0

测试一下,发信正常,现在可以让msmtpqueue出场了。由于msmtpqueue只是在”转达”msmtp发信的命令,所以需要先把msmtp调试好以后再配置。

msmtpqueue已经随msmtp安装上了,放在/usr/share/doc/msmtp/examples下,按照这里README文件的说明,把msmtp-enqueue.shmsmtp-runqueue.sh两个文件加上执行属性,然后ln到$HOME/.mutt下,再在这里创建一个新目录msmtpqueue,ln成~/.msmtpqueue(两个脚本默认的QUEUEDIR),最后修改muttrc中的sendmail:

set sendmail = "~/.mutt/msmtp-enqueue.sh"

好了,现在再来发信,是不是瞬间就完成了?再看~/.mutt/msmtpqueue目录下,也多了两个文件,分别以.mail.msmtp结尾,他们分别包含了刚才所发信件的信件内容和发送命令。现在运行msmtp-runqueue.sh

~/.mutt$ ./msmtp-runqueue.sh 
*** Sending 2008-01-12-23.03.52.mail...
2008-01-12-23.03.52.mail sent successfully

邮件就这样顺利的发出去了。

工作到这里基本就都完成了,发信时按y嗖一下就完成的感觉真不错,为了更方便的发送邮件,还可以在mutt中定义启动邮件发送程序的快捷键:

macro generic S "!~/.mutt/msmtp-runqueue.sh\n"

ubuntu的包里没有,但svn上还有一个msmtp-listqueue.sh脚本,列出当前QUEUEDIR中信件的From/To/主题,凑合能用,但用RFC2047编码方式的中文标题自然是不能正常显示的了。

Update @ 2009-03-27

知道gmail的两个端口,465和587有区别么?还真不完全一样,我用msmtp试出来的结果是这样的:

  • 如果使用465端口,则置tls_starttls off
  • 如果使用587端口,则置tls_starttls on

否则不是连不上就是无回馈数据。是看了标题: 我翻译的 msmtp 的手册页后受启发发现的。

Message rejected for Sector 5 policy reasons

用邮件订阅了一些google groups讨论组,发现有些文章值得保存的话,我会用mail forward转发到自己的另外一个讨论组,这样便于以后查找,可有些邮件在转发的时候会失败,gmail会返回一封“Delivery Status Notification (Failure)”发送失败的邮件,内容如下:

This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: somewhere@googlegroups.com Technical details of permanent failure: PERM_FAILURE: Message rejected for Sector 5 policy reasons —– Original message —– ……

退信的原因是“Sector 5“,而这个神秘的“Sector 5“ google并没有给出详细的内容,哪怕是出处也没有。网上也有很多人遇到了类似的情况,甚至在一些google groups中也有讨论,但都没有结果,google官方也没有出面指明。不过,今天在看某个电影的时候,发现了这个:

FBI WARNING

这是大家常见的“FBI WARNING”信息,就是警告信息,一般正规影碟前面都有的,告诉观众不得非法传播、拷贝,否则最高可以判5年徒刑或者罚款25万美元(够恨的),而在这些的法律依据,就是“Title 17 U.S.Code, Section 501, 506 and 508”。

所以我觉得gmail退信的原因,和这个Section 501等等有关系,没准就是同一部法律,或者类似的条款,都是关于版权保护的内容。gmail在我转发邮件的时候,发现转发的内容不是我写的,并且和其他groups中的文章惊人的相似,所以就以“Sector 5”为由,拒绝我传播“盗版”了。

Update @ 2008-03-23

找到一篇和508沾边但仍未完整解答我的疑问的文章:section 508