MimeMessage中BodyPart未识别八进制流元素，附件解析异常求助

MimeKit 默认通过 Content-Disposition: attachment 头或带文件名的非内联 Content-Type 识别附件，你遇到的问题是目标邮件的附件缺少正确的头标记，导致被归类到 BodyParts 而非 Attachments 集合中。以下是安全且精准的解决方案：

核心判断逻辑（规避风险） #

只筛选符合以下特征的 BodyPart，避免误将正文内容或内联资源当成附件：

• 排除已被默认识别的附件
• 排除 Content-Disposition: inline 的内联资源（如正文嵌入图片）
• 满足任一附件特征：
  1. 类型为 application/octet-stream 且带有文件名
  2. 明确为 PDF/TXT 等附件类型，且文本类型必须带有文件名（防止误判正文文本块）

C# 代码实现 #

using MimeKit;
using System.Linq;
using System.Collections.Generic;

// 假设已从邮件服务器获取MimeMessage实例
var message = GetMimeMessageFromServer();

// 先收集默认识别的合法附件
var allAttachments = message.Attachments.ToList();

// 从BodyParts中筛选未被正确标记的潜在附件
var unmarkedAttachments = message.BodyParts.OfType<MimePart>()
    .Where(part => 
        !allAttachments.Contains(part) &&
        part.ContentDisposition?.DispositionType != "inline" &&
        (
            // 处理octet-stream类型且带文件名的情况
            (part.ContentType.MediaType == "application" && part.ContentType.MediaSubtype == "octet-stream" && !string.IsNullOrWhiteSpace(part.FileName)) ||
            // 处理明确的PDF/TXT类型，文本类型必须带文件名
            (
                (part.ContentType.MediaType == "application" && part.ContentType.MediaSubtype == "pdf") ||
                (part.ContentType.MediaType == "text" && part.ContentType.MediaSubtype == "plain")
            ) && (!string.IsNullOrWhiteSpace(part.FileName) || part.ContentType.MediaType != "text")
        )
    );

// 合并所有附件
allAttachments.AddRange(unmarkedAttachments);

关键说明 #

• Thunderbird 重新保存后能正常识别的原因：Thunderbird 会自动修复邮件头，为这类未标记的附件补充 Content-Disposition: attachment 属性，符合 MimeKit 的默认识别规则。
• 安全性保障：通过文件名检查、内联资源排除、特定类型匹配三重过滤，避免盲目解析所有 BodyPart 带来的风险（如误将正文二进制块、内联图片当成附件）。
• 可扩展性：可根据业务需求添加更多允许的附件类型（如 application/vnd.openxmlformats-officedocument.wordprocessingml.document 对应 docx）。

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