问题分析:
我们分别收取了正常的POP3下载和您的pst文件的POP3下载的日志,在Pop3日志和etl 日志中对比了双方的行为,有唯一区别的是当再次点击下载后:
正常的行为是:
1. 等下载最后一封信下载完毕,会标记所有下载过的邮件为“已读”
2. 然后退出这个对话
3. 再次重新开启对话
4. 用户身份验证登录
5. 邮箱状态检查,这里会列出所有的邮件数量和总的大小
6. 然后服务器会响应所有邮件的UID, 这个UID就是邮件的特有标记。这个时候客户端会在本地对这些UID进行对比,如果都重合,那么就不再下载
7. 服务器还会列出所有邮件的ID号
8. 最后客户端发现都已经下载,就发送退出的指令
而在重现问题的时候,我们发现唯一不同的地方是第8点,客户端没有发送退出指令,而是直接发送了RETR指令,也就是下载邮件的指令。
没有任何的报错,甚至系统也不认为这是个错误行为。
因此,有以下几点是值得怀疑的:
1. POP3需要在单一目录中需要下载的邮件数量超出了最大的限制
2. 这个跟第一点类似,POP3的每个指令的等待响应时间是有限制的,是否在最后的检查邮件是否已下载的过程中,得不到服务器或者客户端本身自己的及时响应,因为要检查的数量太过于庞大。
针对这两点,微软做了一些测试:
1. 把POP3服务器的响应时间调大到5分钟,但是问题还是一样
2