核心用法
本 Skill 基于 Resend API 提供完整的邮件收发能力，分为出站发送与入站接收两大模块：
出站功能
- 使用
outbound.py发送邮件，支持多附件、自定义发件人 - 关键约束：回复邮件必须使用
draft-reply.py工作流，强制维护In-Reply-To和References头部，确保 Gmail 等客户端正确显示线程 - 草稿工作流：
start→content→send，支持多次resume继续同一线程
入站功能
inbound.py检查新邮件，支持附件列表与下载（download_attachment.py）- Cron 定时任务（每 15 分钟）自动推送通知到指定 Telegram 频道/话题
- 通知分级标记：🔥 高优先级 / 📅 会议 / 📬 普通
- 强制确认机制：邮件必须等待用户显式
done/ack后才标记为已处理，禁止自动确认
配置管理
- 零配置文件设计：优先读取环境变量（
RESEND_API_KEY），回退至memory/email-preferences.md（YAML frontmatter 格式） - 首次使用自动引导创建偏好文件，持久化发件人信息与通知目标
显著优点
| 维度 | 优势 |
|------|------|
| 线程完整性 | 强制 `draft-reply.py` 工作流，根治回复变新线程的顽疾 |
| 双向集成 | 收发闭环：邮件→Telegram 通知→聊天记录追溯 |
| 审计追踪 | 完整的 custody chain（DAG 结构），email_id ↔ notification_id ↔ 所有操作可溯源 |
| 零配置启动 | 环境变量 + 内存文件自动发现，无需手动编辑 config |
| 安全设计 | 最小权限读取（仅 `email-preferences.md`，不扫描其他 memory 文件） |
潜在缺点与局限性
1. Vendor Lock-in：深度绑定 Resend API，迁移成本较高；Resend 本身为较新服务商，企业级 SLA 历史较短
2. 接收限制：Resend Receiving 功能目前为 Beta，可能存在稳定性与地区可用性问题
3. Telegram 依赖：通知渠道目前主要支持 Telegram，Discord 等需自行扩展
4. Python 运行时：依赖本地 Python3 与 requests 库，容器化部署需额外处理
5. 线程规则刚性：强制工作流虽保证正确性，但增加用户学习成本；误用 outbound.py 回复会导致不可逆的线程断裂
适合人群
- 需高频邮件自动化但重视线程完整性的团队协作场景
- 已使用 Telegram 作为主力通讯工具的个人或组织
- 开发者/技术用户，能接受 CLI 工作流与 YAML 配置
- 对邮件审计与 custody chain 有合规要求的场景
常规风险
| 风险类别 | 说明 | 缓解措施 |
|----------|------|----------|
| API 密钥泄露 | `RESEND_API_KEY` 泄露可导致邮件滥用 | 使用最小权限密钥，避免硬编码，优先环境变量注入 |
| 线程断裂 | 违规使用 `outbound.py` 回复导致上下文丢失 | 严格执行 `draft-reply.py` 工作流，代码层面可配置强制检查 |
| 通知轰炸 | Cron 配置过频或邮件量大导致消息过载 | 建议 */15 分钟或更低频率，利用重要性分级过滤 |
| 隐私泄露 | `email-preferences.md` 若权限不当可能暴露 Telegram chat_id | 限制文件权限 600，定期审计 memory 目录 |
| 依赖失效 | Resend 服务中断或 API 变更 | 监控 Resend 状态页，保留邮件发送日志用于故障切换 |
---
版本：1.0.14 | 协议：Apache-2.0 | 测试覆盖：43+ 单元测试