imap-smtp-email：让终端直接收发邮件的多账户方案

一、基本信息

为什么这章值得看——先看清它的底细和运行条件，再决定要不要往下读。

二、它解决什么问题

为什么这章值得看——搞懂它的设计动机，才能判断它和网页邮箱、第三方客户端是不是一回事。

邮件自动化的第一道坎是认证。Gmail 不收主密码，必须用 App Password；163 系列要开授权码，还得先在网页设置里打开 IMAP/SMTP 开关。这些前置条件没有现成工具帮你理顺，网上教程鱼龙混杂，很多人卡在「Authentication failed」就放弃了。第二道坎是协议本身——IMAP 的 UID、FLAGS、文件夹层级，SMTP 的 MIME 编码、附件边界，每一样都够写一篇长文。第三道坎是多账户：工作邮箱和个人邮箱混在一个工具里，配置一乱就发错邮件。

imap-smtp-email 把这三道坎都填平了。它用标准的 IMAP/SMTP 协议直连邮件服务器，中间不过任何第三方服务器；配置走一个 .env 文件，官方把 Gmail、163、QQ 等常用服务商的 host 和端口直接列成表格；多账户用环境变量前缀区分，WORK_IMAP_HOST 对应 work 账户，命令行加 --account work 即可切换。装好之后，Agent 或者你自己的脚本就能像调用一个普通函数一样调用邮箱。

一句话概括它的设计哲学：把邮箱变成终端里的一组命令——协议细节它扛，你只管下指令。

三、核心功能

为什么这章值得看——它到底能替你做哪些邮件动作，边界在哪，这一章说透。

收信：IMAP 模块的六件事

收信侧围绕 node scripts/imap.js [账户] <command> 这一条命令骨架展开，六个子命令覆盖了读邮件的完整动作。

search 是这组命令里最实用的一个。比如「找最近 24 小时里老板发来的未读邮件」，一条命令就够：node scripts/imap.js search --unseen --from boss@company.com --recent 24h。时间过滤支持 30m、2h、7d 这类相对写法，也支持 YYYY-MM-DD 的日期区间，组合起来能拼出相当精细的筛选条件。

发信：SMTP 模块与连接测试

发信侧是 node scripts/smtp.js [账户] send --to <email> --subject <text>，功能上是一套完整的邮件发送器：纯文本和 HTML 正文、多收件人、CC/BCC、多附件、从文件读正文（--body-file / --html-file）、覆盖发件人。举几个真实用法：

• HTML 周报：node scripts/smtp.js send --to team@example.com --subject "周报" --html --body "<h1>本周进展</h1>"
• 带附件：node scripts/smtp.js send --to client@example.com --subject "报表" --attach report.pdf
• 多收件人加抄送：--to "a@x.com,b@x.com" --cc "c@x.com"

另有 test 子命令，给发件人自己发一封测试邮件，用来快速验证 SMTP 配置是否打通——第一次配置完强烈建议先跑它，别拿正式邮件当试验品。

多账户与安全边界

多账户机制是它的招牌。所有账户共用一个配置文件 ~/.config/imap-smtp-email/.env，默认账户不带前缀，附加账户用大写前缀区分，比如 WORK_IMAP_HOST、WORK_SMTP_PASS。账户名只用字母和数字，大小写不敏感，work 和 WORK 指向同一个账户。切换只需要在命令前加 --account work，不加就走默认账户。

安全设计上它做了三层。第一层是文件权限：配置文件强制 600 权限，只有属主可读写。第二层是目录白名单：ALLOWED_READ_DIRS 和 ALLOWED_WRITE_DIRS 限定附件的读写范围，防止 Agent 拿着邮箱权限在文件系统里乱翻乱写，也挡住了路径遍历。第三层是传输加密：IMAP 默认走 993 端口 TLS，SMTP 按服务商要求走 465 或 587。另外它不调用任何第三方 API，邮件数据只在你和邮件服务器之间流动。

四、真正有价值的地方

为什么这章值得看——同样是邮件命令行工具，它的差异点在这几处。

兼容性列表是现成的。SKILL.md 里直接给了 11 组服务商配置表：163、vip.163、126、vip.126、188、vip.188、yeah.net、Gmail、Outlook、QQ、腾讯企业邮，IMAP/SMTP 的 host 和端口一应俱全。配邮箱时照着抄就行，不用再到处查文档。这一点对国内用户尤其友好——很多国外工具根本不列 163 和 QQ 的参数。

凭证引导做在前面。Gmail 必须用 16 位 App Password（前提是开启两步验证）、163 必须用授权码而不是登录密码，这些坑它都在文档里写死了。常见故障排查也给了对照表：连接超时查 host/port，认证失败先查凭证类型，TLS 报错对照 IMAP_TLS/SMTP_SECURE 设置。第一次配邮箱能省下大量试错时间。

多账户设计克制而清晰。没有引入账户数据库或交互式登录，就是一个 .env 加前缀机制。配置文件放在 ~/.config/imap-smtp-email/ 下，技能更新后配置不受影响；找不到主配置还会回退到技能目录下的 .env，兼容旧版习惯。简单，但边界清楚。

附件处理完整。收件侧可以按 UID 批量下载全部附件，也可以用 --file 只取某一个；发件侧支持逗号分隔的多附件。配合目录白名单，Agent 可以安全地「把邮件里的附件存到指定文件夹」这类动作，不用担心它写到别处。

包体小，代码可读。整包 16.2 kB，源码就三个 JS 文件加一个安装脚本。想确认它到底怎么处理你的密码、附件存在哪，把 config.js（4.4 kB）读一遍就有答案。对要托管邮箱凭证的工具来说，「看得懂」本身就是一种安全。

五、绕不开的问题

为什么这章值得看——这些局限不是缺点清单，而是决定你能不能用它的前提。

凭证明文存储。密码和授权码以明文写在 .env 文件里，600 权限只防同账户的其他用户，防不住 root，也防不住系统里任何一个能读你家目录的进程。官方没有集成系统密钥链，也没有 OAuth2。如果你的机器是多人共用或跑着来路不明的软件，这一条要认真掂量。

无端到端加密。邮件内容对邮件服务商完全可见，这和用网页邮箱没有区别。但既然你把它接给了自动化流程，就意味着邮件正文会进入 Agent 的上下文——高度敏感的邮件不适合让它代读。

需要 Node 环境。整套工具跑在 Node.js 上，还有五个 npm 依赖（dotenv、imap、imap-simple、mailparser、nodemailer）。对纯终端用户或不想装 Node 的机器来说，这是实打实的门槛。

版本号还年轻。0.0.13 意味着功能还在快速迭代，命令参数和行为可能随版本变化。文档里明确支持的邮箱列表虽然长，但任何服务商调整端口或认证策略，都可能需要等它跟进。

自动化频率会触发风控。Gmail 和 163 对程序化操作都有频率限制，短时间大批量拉取或发送，轻则弹验证，重则临时封禁 IMAP 访问。用它做高频监控前，先想清楚节奏。

没有发送队列和重试。send 就是一次同步的 SMTP 提交，网络抖动或者服务商拒收，都需要调用方自己处理。做关键业务的通知系统，得在外面再包一层容错。

六、官方风险表与解读

为什么这章值得看——安全报告怎么说，和实际使用该防什么，是两件需要对照看的事。

四个风险项里唯一标「中」的是凭证泄露，这个判断很实在。技术层面的防护——600 权限、目录白名单、TLS 传输、无动态代码加载——在 16 kB 的包里能做的都做了。剩下的风险集中在「环境」：机器本身不干净，再严的文件权限也没用。报告给出的建议是：用 App Password/授权码代替主密码、配置目录权限收紧到 700、定期轮换凭证、留意异常网络连接。另外别忘了邮件内容本身没有端到端加密，敏感信息别让它代发。

一条实用纪律：给每个接入它的邮箱都用服务商提供的专用凭证（App Password 或授权码），主密码永远不进 .env。凭证一旦泄露，损失被限定在一个可撤销的副钥匙上。

七、适合谁，不适合谁

为什么这章值得看——工具没有普适性，对号入座比看完就走有用。

八、落地路径

为什么这章值得看——按这个顺序走，能在最短时间把风险降到最低。

1. 跑安装脚本。解压后执行 bash setup.sh，它会装依赖并引导配置第一个账户；手动装则先 npm install --production。脚本会问你选哪个服务商，Gmail、163、QQ 的参数都有模板。
2. 准备专用凭证。Gmail 到 myaccount.google.com/apppasswords 生成 16 位 App Password（需先开两步验证）；163 系列在网页设置里开 IMAP/SMTP 并生成授权码；QQ 邮箱同理用授权码。主密码不要填。
3. 先测试收，再测试发。跑 node scripts/imap.js check --limit 5 确认能读到邮件，再跑 node scripts/smtp.js test 给自己发一封测试信。两步都通，链路才算打通。
4. 收紧目录白名单。在 .env 里把 ALLOWED_READ_DIRS 和 ALLOWED_WRITE_DIRS 设成最小集合，比如只开放 ~/Downloads。Agent 下载附件的活动范围就锁死在这里。
5. 加第二个账户。在 .env 里追加 WORK_ 前缀的变量组，用 node scripts/imap.js --account work check 验证切换。确认 list-accounts 能列出全部账户且配置状态完整。
6. 接入自动化并控节奏。把命令交给你的 Agent 或 cron，控制调用频率，避开服务商风控；重要发送动作先在测试收件人上演练一遍。

九、文件构成与安装

为什么这章值得看——16 kB 的包里每个文件是干什么的，看完心里有账。

安装很简单：解压到技能目录，跑 bash setup.sh，配置写入 ~/.config/imap-smtp-email/.env。这个位置是刻意选的——技能升级覆盖目录时，配置文件安然无恙。整个包没有编译环节，五个依赖装完即用；想升级，覆盖源码文件即可，配置不用动。

十、常见问题

163 邮箱一直认证失败怎么办？

九成是用了登录密码。163 必须用授权码：登录网页版，在设置里开启 IMAP/SMTP 服务，生成授权码填进 IMAP_PASS 和 SMTP_PASS。QQ 邮箱同理。

Gmail 报「Invalid credentials」？

Gmail 从不接受账户主密码。先给 Google 账号开启两步验证，再到 myaccount.google.com/apppasswords 生成一个 16 位应用专用密码，用它替换 IMAP_PASS 和 SMTP_PASS。

密码明文存在 .env 里，安全吗？

文件权限是 600，同账户的其他用户读不到，但 root 和能访问你家目录的进程可以。建议：配置目录权限收紧到 700、用授权码而非主密码、定期轮换凭证、不在多人共用的机器上配置。要更高安全性，目前只能等官方接入系统密钥链或 OAuth2。

最多能配几个账户？

没有硬性上限。每个账户就是一组带前缀的环境变量，账户名限字母和数字、大小写不敏感。注意 ALLOWED_READ_DIRS 和 ALLOWED_WRITE_DIRS 始终无前缀，是所有账户共享的白名单。用 node scripts/imap.js list-accounts 可以随时核对。

附件默认下载到哪里？

当前工作目录，可用 --dir 指定。无论指定哪里，目标路径必须在 ALLOWED_WRITE_DIRS 白名单内，否则会被拒绝——这是防路径遍历的关键一环。

发大附件会有问题吗？

当前版本没有附件大小限制，超大附件会占内存且容易被服务商拒收。一般邮箱发信上限在 25-50 MB，建议先压缩，或改用网盘链接形式发正文。

公司自建邮箱能配吗？自签名证书报 TLS 错误呢？

任何标准 IMAP/SMTP 服务器都行，host、端口、TLS 开关都是可配项。自签名证书可以在 .env 里把 IMAP_REJECT_UNAUTHORIZED 或 SMTP_REJECT_UNAUTHORIZED 设为 false，但这会关闭证书校验，只建议在内网环境用。

自动化跑久了会被封号吗？

高频程序化操作确实可能触发 Gmail、163 的安全风控，轻则要求重新验证，重则临时关闭 IMAP 访问。控制调用频率、给轮询加间隔，是长期挂机的前提。

结语

imap-smtp-email 属于那种「一击就中需求」的工具：不搞花活，把收、搜、发、附件、多账户这几件邮件自动化最核心的事用 16 kB 源码做完，还把 Gmail 和 163 这些最容易卡住新手的凭证坑提前写进文档。凭证明文存储和无端到端加密是真实的天花板，但对个人开发机上的自动化场景来说，用专用凭证加目录白名单已经能压住大部分风险。

如果你的 Agent 一直缺一条通往邮箱的路，这个技能包是目前成本最低的搭法——从 node scripts/imap.js check 开始，十分钟内就能看到结果。

通过网盘分享的文件：gzlicanyi-imap-smtp-email-0.0.13.zip
链接: https://pan.baidu.com/s/1XFW36rAGWgwnmgiUVsIfxg?pwd=bbnz 提取码: bbnz 复制这段内容后打开百度网盘手机App，操作更方便哦

技能包邮件自动化IMAPSMTP多账户邮箱效率办公命令行

百度网盘下载：https://pan.baidu.com/s/1XFW36rAGWgwnmgiUVsIfxg?pwd=bbnz（提取码：bbnz）