我正在排除一个(我认为)已经工作了一年或更长时间的过程。此解决方案更新了较新版本的解决方案软件，现在我们的一个IMAP检索过程似乎无法正常工作。(在更新之前，我没有听到任何关于它的抱怨——因此它一定是有效的，对吧?:)但是我没有"更新之前"的任何数据或样本来确切地知道它当时得到了什么样的结果。
该解决方案在FileMaker中编码，使用MBS插件实现cURL函数。这个进程通过IMAP协议连接到GMail帐户，使用cURL命令。此进程每小时运行一次。
一般来说，它工作得很好——没有错误。问题是，它似乎返回了错误的电子邮件。我们使用'SEARCHSINCE 18 oct -2021'功能来限制找到的电子邮件。
如果我在浏览器中登录帐户，我看到收件箱中有6封10/19收到的电子邮件。
当我在Gmail网页界面中进行搜索时:之后:2021/10/18我收到了24封邮件，这些邮件包括10/19收到的新邮件。
- IMAP问题示例:SEARCHSINCE 19-Oct-2021
•实际:11封邮件…•但是——这些邮件是10/18发的，不是>=10/19…这些结果不包括从10月19日开始的任何内容。
- IMAP问题示例:SEARCHSINCE 18-Oct-2021
•实际:38封邮件…
•BUT -其中一些邮件来自10/15，而不是>=10/18;并且这些结果不包括10/19的任何内容。
(我检查了两个搜索的示例电子邮件，源中的'Date'和'ReceivedOn'标头有10/15的日期。)
- 一时兴起，我设置了SearchDate = 20-Oct-2021
•Result = No IDs
这是一个实际的IMAP交换:
Connected to imap.gmail.com (74.125.142.109) port 993 (#0)
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
Server certificate:
subject: CN=imap.gmail.com
start date: Sep 13 03:11:41 2021 GMT
expire date: Nov 20 03:11:40 2021 GMT
issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
old SSL session ID is stale, removing
* OK Gimap ready for requests from <server> <id>
A001 CAPABILITY
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
A001 OK Thats all she wrote! <id>
A002 AUTHENTICATE PLAIN <key>
* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584
A002 OK <email account> authenticated (Success)
A003 SELECT INBOX
* FLAGS (Answered Flagged Draft Deleted Seen $NotPhishing $Phishing)
* OK [PERMANENTFLAGS (Answered Flagged Draft Deleted Seen $NotPhishing $Phishing *)] Flags permitted.
* OK [UIDVALIDITY 1] UIDs valid.
* 5101 EXISTS
* 0 RECENT
* OK [UIDNEXT 5114] Predicted next UID.
* OK [HIGHESTMODSEQ 793152]
A003 OK [READ-WRITE] INBOX selected. (Success)
A004 SEARCH SENTSINCE 19-Oct-2021
* SEARCH 5091 5092 5093 5094 5095 5096 5097 5098 5099 5100 5101
A004 OK SEARCH completed (Success)
Connection #0 to host imap.gmail.com left intact
有谁知道如何让谷歌工作吗?
编辑，10/20:我已经测试了一些额外的东西，但我似乎在使用IMAP时得到了相同的结果，这与我使用GMail网络搜索界面得到的结果不匹配。
这个收件箱里有3封今天(10月20日)的邮件。
找到Gmail的IMAP扩展，并尝试使用它来进行搜索。它使用gmail界面风格的搜索输入。而不是'SEARCH SENTSINCE'，这个扩展看起来像:
SEARCH X-GM-RAW "after:2021/10/19"
结果:没有找到来自10/20的消息
略有不同的形式(这是2021/10/19的Unix epoch #):
SEARCH X-GM-RAW "after:1634626801"
结果:10/20没有电子邮件
直接在Gmail网页界面中搜索:'after:1634626801'= 19个结果，包括10/20(今天)的电子邮件
也试过了:
SEARCH SINCE 2021-10-19
结果:没有10/20的消息(返回10/19的消息)。
因此，IMAP搜索结果至少在不同的搜索方法之间是一致的。但它们不是我需要的结果——它不是找到最新的东西。
我终于想通了。这个过程中我的FMP脚本有一个bug。它不是MBS，不是IMAP，也不是谷歌(该死的)。
具体来说，有两个不同的IMAP命令。SEARCH(就是我在上面展示的，我认为错误就在这里)，然后是RETRIEVE。问题是这两个命令引用了不同的Id: IMAP有两个Id -默认的'Id'和'UID'。它们非常相似——它们都是序列号——但它们不一样。UID更持久。因此，我的搜索返回的是"默认"类型的消息id，而检索引用的是电子邮件的"UID"值。
搜索(不指定UID，因此返回默认ID):
SEARCH SINCE 10-Oct-2021
检索(使用UID)
imaps://<ServerName>/INBOX?UID=...
New Search(返回uid，以便与Retrieve匹配):
UID SEARCH SINCE 10-Oct-2021