IMAP收件箱分类代理

解决什么问题

邮件收件箱的堆积看似简单，实则卡在三个工程难点上：

• 规则脆弱：传统过滤规则依赖固定发件人或主题词，遇到变体地址或动态主题就失效，维护成本随时间指数级上升。
• 手工标注不可持续：人工分类依赖个人判断，跨设备同步状态困难，团队协作时版本冲突频发。
• IMAP客户端差异：不同服务对协议实现不一，例如RFC3501规范中RFC822.HEADER的替换逻辑在Fastmail与Gmail之间表现不同，导致行内代码级的字段读取行为难以统一。

工作原理

该代理通过以下方式处理邮件流：

1. 协议层兼容：直接连接IMAP服务器，兼容Gmail、Outlook、Fastmail的底层通信差异。例如处理RFC822.HEADER字段时，识别现代实现中已用&替代旧版特殊字符的场景。
2. 双引擎过滤：结合规则引擎（如label:inbox条件）与轻量级ML模型，动态学习用户对历史邮件的分类偏好。例如当检测到From:头包含特定域名时自动触发优先级提升标签。
3. 自动化标签流：分类结果通过IMAP的STORE命令写入邮件标记，实现跨客户端同步。例如将INBOX.Receipts规则命中邮件标记为invoice类别并归档。

适用边界与注意事项

• 协议依赖性：必须保证目标IMAP服务完整实现RFC3501规范，部分非标准实现（如旧版Exchange）可能导致搜索结果与标签写入行为不一致。
• 字段替换风险：当代理处理RFC822.HEADER时，若上游邮件已由非IMAP客户端重写头字段，需验证&替换逻辑是否被正确执行。
• 客户端交互限制：不支持通过HTTP API调用，必须以IMAP客户端身份直接交互，无法绕过服务端对APPEND命令的权限控制。