问题标签 [microsoft-graph-mail]

我正在使用 Microsoft Graph 来获取邮件，我最近注意到当电子邮件有.eml附件时，有两种情况：

1. 如果发件人通过给作曲者下药的电子邮件将该电子邮件附加到作曲家，则该附件将是项目附件类型。<-- 我可以处理这个案子

2. 如果发件人.eml通过单击“附加文件”附加文件，则该附件将是一种文件附件。到目前为止，我认为作为文件附件很好。但是当我尝试获取该附件时，附件内容类型application/octet-stream是错误的。不应该message/rfc822吗？使用application/octet-stream，我无法从我们的服务器创建该附件。

我使用此请求来获取消息中的所有更改：

然后使用@odata.deltaLink 跟踪下一次更改

但是有一个奇怪的地方：

如果我只更改消息的 isRead 字段，则 delta API 仅返回几个字段：

但 delta API 通常会返回所有字段，如subject, bodyPreview, importance, parentFolderId,conversationId等。

它是设计使然还是错误？

我能够使用以下 API 调用获取带有附件的邮件对象

我需要为.eml将上传到我们内部 CRM 的邮件（即）保存原始 MIME。

我知道可以.eml以以下方式制作一个简单的文件，但我想知道是否有更简单的替代方法可以直接从 API 获取它。

所以我从graph API得到的skip token是一个数字，根据我的理解（我可能错了），它表示需要跳过多少封电子邮件。

在我们的应用程序中，我们将该跳过令牌存储在我们的 db/memory 中，以便我们可以获取下一页电子邮件。因此，如果说用户当前的跳过令牌是 100，并且在我们使用跳过令牌 100 向服务器发送请求之前，该用户删除了 10 封电子邮件，那么如果仍然使用那 100 个跳过令牌会发生什么？

由于我不确定如何处理这种用户删除电子邮件的情况，我们的应用程序的工作方式是：我们总是对跳过令牌（如 -10）做一个减号，并检查我们是否可以找到任何电子邮件或时间戳重叠在当前响应和之前的响应之间，如果没有重叠，我们对跳过标记再做一次减法。这有点像倒退。我们停止做减法，直到找到重叠。

是否有意义？到目前为止，我注意到一些跳过令牌的响应将 nextLink 设为 null，而用户的收件箱中仍有新电子邮件。此外，我们错过了大约半年的几封电子邮件（这意味着电子邮件在用户的收件箱中，但我们的应用程序没有获取到）。

在我的应用程序中，我通过

使用代码

与application/x-www-form-urlencoded：grant_type=authorization_code&redirect_uri=https%3A%2F%2Fgraphresponse%2F&client_id=<CLIENT_ID>&scope=user.read+mail.send+mail.readwrite&client_secret=<CLIENT_SECRET>&code=<CODE>

到目前为止一切顺利，我收到了这样的不记名令牌（为便于阅读而格式化）：

我可以使用以下端点

但我收到以下错误

我是否错过了明确读取当前用户收件箱所需的任何配置，或者是否需要任何管理员配置？

我正在使用 Microsoft Graph 从邮箱中提取电子邮件数据。当我获得内容时，我发现嵌入的图像内容如下：

当该属性hasAttachments为真时，我会寻找匹配并替换内容的图像，并且效果很好。问题是我在错误的消息中看到这样的嵌入图像标签hasAttachments。

我在哪里可以获得图像数据图表显示消息没有附件但显然有嵌入图像？

请注意，图像在 Outlook 网页版中呈现，带有如下标记：

我正在从 Outlook 帐户检索邮件。我正在尝试从这些消息中获取内联文件和附件。

此代码为 $msg->getHasAttachments(); 返回“null”；我希望它返回真或假。

我从这个文件夹下载的邮件既有内联附件也有邮件附件，所以我正在寻找两者的解决方案。

（非常感谢指向 MS Graph PHP SDK 文档中特定点的响应。）

我的应用程序使用 Microsoft Graph 发送电子邮件。我们遵循了文档，这按预期工作了将近一年：

自 2019 年 3 月 8 日以来，PROD 中的相同代码sendmailAPI 开始失败，并出现HTTP 400 - Bad Request：

作为调查的一部分，我们发现示例中使用的 SendMail 文档的 URL 与 API 帮助部分不同。调用此 URL 时我们成功了：

问题：

1. 显然，2019 年 3 月 8 日左右，Graph API 发生了一些更新，导致早期 URL 无法正常工作

2. 文档有 2 个具有误导性/混淆性的 URL：一个是 API 帮助部分，一个是示例。截至目前，帮助部分中的 API URL 不再有效。这应该使用正确的 URL 来解决。

3. 为什么会引入这样的重大更改导致我们的应用程序出现 PROD 中断？

4. 获取这些更改的官方渠道是什么？

我正在尝试使用 MS Graph API 从特定邮箱读取电子邮件。

我从这里获取的用户那里获得了所有正确的数据，但用户mailFolders属性是null.

为什么是这样？

我们想要扫描特定邮箱中的电子邮件并处理这些电子邮件和附件。我认为这可能是做到这一点的正确方法。但我坚持上述做法，MS Graph 上的文档，尤其是 .NET API 的文档是如此。

是不是权限的事情，我能不能通过某种方式增加我们AD应用注册的权限来获得这个权限？

还是这里发生了其他事情？

我正在创建一个可以与 Ms Graph Api 通信以访问 Office36 邮件的应用程序。为此，我是否需要强制向 AZURE 门户注册我的应用程序