想及时知道对方有没有回复邮件, 但又要避免频繁 imap 导致的限制? ?

没做过回复检测,不晓得。
我做的只是发送,每天至少 1.2 封邮件。
或许可以考虑付费方案。

@lyxxxh2 1.2k

现在通用的服务商每 30s 一次 pull 应该是没问题的吧...

用 capabilities 看看支持不支持 idle ，如果支持就用 idle 挂着，如果不支持的话，就只有轮询了。

只建议 idle,轮询太频繁搞不好被运营商搞，实在不行你写个邮件客户端给你和客户使用，里面内置一个自定义的 idle 服务接口，自己部署一个 idle 服务器，这样子随便刷自己服务器的接口请求是没有问题的

@qwx 不同邮件的 imap 封禁策略 都没有公开. 大概的安全区间是 是 3-15 分钟.

要不自建邮局？

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

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

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

@Rache1

在考虑 IDLE

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

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

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

@jinlongprosper 反正这玩意你白嫖邮箱厂家的话只有 idle 死循环监听，其他方式都是需要额外花钱搭服务的，毕竟都是白嫖别人家的邮箱服务也的确不好意思再多要求人家给什么实时同步了，那样子岂不是成了即时通讯？那不就是微信的发家路吗？

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

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

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

@jinlongprosper 这是一个问题，如果你是付费，不如问下平台客服有没有规避的限制的方案

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

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

你要是这些邮箱都是自己可以控制的域名，那可以考虑 cloudflare 来收，然后利用 worker 转发，这样就不花钱了。

然后再去找一个发信便宜的去专门发信。

或者你也可以就用 cloudflare 的发信，每月免费 3000 封，超出的 $0.35/1000 封。

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

IDLE 每个邮箱需要独立的认证连接，这有什么问题吗？ 100 邮箱不就是连接吗，你电脑连 100 个连接都维持不了？

需要处理断线、服务器超时、进程重启、网络变化，你干嘛要关心这些，但凡是你在 github 上面能搜出来的 imap 协议实现包，我不信哪个包是没有处理这些的，除非你自己手搓。你如果都自己手搓协议了，这些基础异常还能不处理吗。

占用长连接就更离谱了，100 个连接都不够？

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