Python imaplib fetch命令兼容问题：RFC822与长参数差异解析

问题背景 #

以下是使用Python imaplib 包从IMAP服务器获取邮件的最简示例：

import imaplib
import email

HOST="MY_AWOSOME_IMAP_SERVER"
USER="me@awsome.domain"
PASS="awesome password"

with imaplib.IMAP4_SSL(host=HOST, port=993) as imap:
    # 登录
    print("Logging in...")
    resp_code, resp = imap.login(USER, PASS)

    # 获取最后两封邮件
    resp_code, mail_ids = imap.search(None, "ALL")
    print(f"Response code: {resp_code}")
    for mail_id in mail_ids[0].decode().split()[-2:]:
        print(f"-> Mail {mail_id}")
        resp_code, mail_data = imap.fetch(mail_id, '(RFC822)')
        msg = email.message_from_bytes(mail_data[0][1])

        print(f"From   : {msg.get('From')}")
        print(f"To     : {msg.get('To')}")
        print(f"Date   : {msg.get('Date')}")
        print(f"Subject: {msg.get('Subject')}")
        print()

    imap.close()

• 该代码在Gmail等多数邮件服务器上运行正常，但在客户的邮件服务器上失效。
• 客户邮件服务商工程师建议修改fetch命令的第二个参数为：

resp_code, mail_data = imap.fetch(mail_id, 'UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Reply-To)]')

替换后，代码可在客户服务器正常运行，但在Gmail等其他服务器上失效。

长fetch参数的具体作用 #

这个参数是IMAP协议中FETCH命令的请求项，每个部分的作用如下：

• UID: 获取邮件的唯一标识符（UID），该标识符在服务器上是持久唯一的，不会因邮件的删除、移动等操作改变。
• RFC822.SIZE: 获取整个邮件的字节大小。
• FLAGS: 获取邮件的状态标记，比如已读(\Seen)、已删除(\Deleted)、已标记(\Flagged)等。
• BODY.PEEK[HEADER.FIELDS (...)]:
  • BODY.PEEK：读取指定邮件内容但不会将邮件标记为已读，区别于普通的BODY指令（后者会触发已读状态变更）。
  • HEADER.FIELDS (字段列表)：仅提取括号内指定的邮件头字段，避免获取完整邮件内容，减少请求数据量。这里指定的字段包含发件人、收件人、主题、日期等基础信息，还有邮件ID、优先级、引用关系、内容类型、回复地址等扩展头字段。

兼容性差异的原因 #

为何适配客户服务器 #

客户的IMAP服务器大概率存在以下一种或多种情况：

1. 性能/限制问题：服务器性能较弱，或者对单次请求的数据包大小有严格限制，RFC822指令会获取完整邮件内容，数据量较大，触发了服务器的报错或超时；而仅获取指定头字段的轻量请求能避开这些限制。
2. 标准实现缺陷：服务器对RFC822指令的解析存在bug，无法正确处理完整邮件的返回数据，但对指定头字段的BODY.PEEK指令支持正常。
3. 状态变更限制：服务器对邮件已读状态的变更有特殊规则，RFC822指令会自动标记邮件为已读，触发了服务器的权限或逻辑限制；BODY.PEEK不会修改状态，因此能正常执行。

为何无法兼容Gmail等服务器 #

不同IMAP服务器对标准的实现细节存在差异，Gmail等服务器失效的原因主要是：

1. 参数格式要求严格：Gmail的IMAP实现要求UID作为FETCH命令的前缀（即使用imap.uid('fetch', mail_id, ...)而非将UID放在请求参数中），原代码将UID直接写在fetch参数里，不符合Gmail的解析规则。
2. 指令语法差异：部分服务器对BODY.PEEK[HEADER.FIELDS]的字段列表格式有特殊要求（比如空格、括号的处理），Gmail无法正确解析这种格式的请求，导致指令执行失败。
3. 冗余参数冲突：Gmail本身对RFC822支持完善，而该长参数中的部分项（比如UID）与原代码使用的邮件ID（序列ID）逻辑冲突，引发服务器解析错误。

内容的提问来源于stack exchange，提问作者user19906