POP3 协议是否允许您指定要下载的电子邮件子集？
我正在编写一个 POP3 邮件客户端。 我想将消息留在服务器上，但我不想每次重新连接时都重新下载所有消息。
如果我今天下载所有消息，并明天重新连接，该协议是否支持仅下载过去 24 小时或某个连续 ID 中的消息的功能？ 或者我必须重新下载所有邮件吗？
我知道唯一标识列表功能，但根据 http://www.faqs.org /rfcs/rfc1939.html 原始规范中不支持它。 大多数邮件服务器都支持此功能吗？
是的，我的客户端也支持 IMAP，但这个问题是专门针对 POP 服务器的。
I am writing a POP3 mail client. I want to leave the messages on the server, but I don't want to have to redownload all messages every time I reconnect.
If I download all the messages today, and reconnect tomorrow does the protocol support the ability to only download the messages from the last 24 hours or from a certain sequential ID? Or will I have to redownload all of the messages again?
I am aware of the Unique IDentification Listing feature, but according to http://www.faqs.org/rfcs/rfc1939.html it's not supported in the original specification. Do most mail servers support this feature?
Yes, my client supports IMAP too, but this question is specifically for the POP servers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您考虑过使用 IMAP 吗？
Have you considered using IMAP?
我已经做到了。
您必须重新阅读所有标题，但您可以决定下载哪些邮件。
然而，我不记得标题中的任何内容可以为您提供万无一失的时间戳。 如果不记录您已经看到的内容，我认为您的解决方案是不可能的。
（就我而言，我不在乎——我只是在寻找标头中具有某些识别特征的消息——这些消息被下载、处理和杀死，其他一切都没有受到影响。）
我还想知道您是否误解了协议。 仅仅因为您下载了邮件并不意味着它已从服务器中删除。 仅当您给出明确的命令来终止该消息时，它才会从服务器中删除。 （当一条消息包含如此多的附件时，系统在您正确注销之前超时，因此您的kill命令被丢弃，您将被逼上绝路！）（这是设计中的一个疏忽。最初的逻辑是附加一个超过 100k 的文件，或者尽可能多的文件总数低于 100k 的文件。 另一项任务失败了，并生成了数千个文件，每个文件大约 100 字节，虽然这是一封完全合法的文件，但没有任何电子邮件能够杀死它。 ！）
因此，如果我正在编写一个邮件客户端，我只需下载本地尚未拥有的任何内容。 如果它应该保留在服务器上，好吧，只是不要发出终止命令。
I've done it.
You'll have to reread all the headers but you can decide which messages to download.
I don't recall anything in the header that will give you a foolproof timestamp, however. I don't believe your solution is possible without keeping a record of what you have already seen.
(In my case I didn't care--I was simply looking for messages with certain identifying features in the header--those messages were downloaded, processed and killed, everything else was untouched.)
I also wonder if you're misunderstanding the protocol. Just because you download a message doesn't mean it's removed from the server. It's only removed from the server if you give an explicit command to kill the message. (And when a message contains so many attachments that the system time-outs before you properly log off and thus your kill command is discarded you'll be driven up the wall!) (It was an oversight in the design. The original logic was attach one file over 100k, or as many as possible whose total was under 100k. Another task barfed and generated thousands of files of around 100 bytes each. While it was a perfectly legit, albeit extreme, e-mail nothing was able to kill it!)
Thus if I were writing a mail client I would simply download anything I didn't already have locally. If it's supposed to remain on the server, fine, just don't give the kill command.
我过去看到的处理方式是根据客户的情况进行处理。 例如，如果我使用 Scribe 在一台计算机上获取电子邮件而不删除，然后移动到另一台计算机，则所有电子邮件都会重新下载，尽管我以前见过它们。 在内部，我想象客户端有一个表来存储以前是否已下载电子邮件。
据我所知，协议中没有任何内容允许这样做。
The way I have seen that handled in the past is on a client-by-client basis. For example, if I use Scribe to get e-mail on one machine without deleting, then move to another machine, all e-mails are downloaded again despite the fact that I've seen them before. Internally, I imagine the client has a table that stores whether or not an e-mail has been downloaded previously.
There's nothing in the protocol that I'm aware of that would allow for that.
有点。 您可以下载单个消息，但无法将状态存储在远程服务器上。
请参阅 http://www.faqs.org/rfcs/rfc1939.html。
Sort-of. You can download individual messages, but you can't store state on the remote server.
See the RETR command at http://www.faqs.org/rfcs/rfc1939.html.