jinlongprosper

@AutumnVerse 这不是技术问题, 而是个工程问题. IDLE 理论可行, 但不完美. 为了解决一个不完美的点, 需要引入另一个东西, 可能层层外延. 所以 飞书/阿里云企业邮箱/gmail/Outlook 会推出自己的 邮箱通知 api.

@Rache1 多谢了, cloudflare 还有这功能 我先了解下.
smtp 发信还好, 用 100 个邮箱, 每天发出 400 封邮件, 控制下频率和并发, 应该问题不大.
主要是两个人邮箱对话(一个跟进, 用多个发件箱发出), 必须得先知道对方讲了什么, 自己才好回复, 就导致 imap 需求非常大.

@jackOff 理论上实时最好, 晚个十几分钟 半小时应该也行.

主要是两个人邮箱对话, 或者任何微信对话, 都必须得先知道 对方讲了什么, 自己才好回复.

@jackOff 大部分付费企业邮箱, Gmail API Pub/Sub, Outlook Graph Change Notifications.

都有自己的 API 通知/推送新邮件的方案.

看来 只能使用付费 API 方案了.

@jackOff
现在有 100 个发件邮箱, 都维护 imap IDLE 感觉也挺复杂.

IDLE 的优点
- 回复到达后可以较快发现，通常不需要等待下一次轮询。
- 减少频繁登录、反复建立连接。
- 对少量需要实时响应的邮箱比较合适。

IDLE 的代价
- 每个邮箱通常需要一个独立的认证连接，不能用一个连接监控所有腾讯企业邮箱。
- 需要处理断线、服务器超时、进程重启、网络变化。
- 会占用长期连接、文件描述符和并发连接额度。
- IDLE 也不是永久连接，RFC 2177 建议大约 29 分钟内重新建立或刷新一次连接。
- 它不一定绕过服务商限制，只是把“频繁登录”变成了“长期保持连接”

@Rache1

在考虑 IDLE

@ldy619354397 理论上可行, 实际操作起来很麻烦. 如果自建邮局的服务器 IP 不干净, 或者经常被主流邮箱识别为 span, 再或者别的因素. 进垃圾邮件箱概率 可能高达 80%.

邮件到达不了对方的收件箱, 一切就没意义了. 也是现在 gmail/outlook/付费企业邮的最大优势.

@lyxxxh2 是的, 各类企业邮箱, Gmail API Pub/Sub, Outlook Graph Change Notifications. 都有自己的 API 通知/推送新邮件的方案