我的第一个 Microsoft Graph 应用程序：Update-MarkAsToBeSweptRule

两个小发现：Invoke-RestMethod 真的很好用；微软大法好！好吧，其实前一个也是“微软大法好”的一部分。

太长不看 直达 GitHub 仓库。

随着我升入博士研究生，我又增加了一个 Microsoft 助力的邮件——UCSB 邮件。我十分喜欢 Exchange 提供的一套服务，它可以说是惟一的好的邮件、联系人、日历解决方案了。当然这里重点不是这个，我们进入主题。

去年开始我开始收集“非人类发邮件”的邮箱地址，比如各种社交网络的 digest，各种 newsletter 等。我希望保持收件箱清爽，会定期删除非人类发送的邮件。然而我对 AI/ML 的结果很不放心，所以目前是基于发件地址进行标记，然后定期删除；无论是否有标记我基本上都会看一眼，误标记的会被取消标记。

做这件事情的方法是在 Outlook.com 的邮箱里设置一个收件箱规则，自动加标记。当然，这个方法也适用于 Office 365，或者说 Exchange Online。另一种方法是在 Outlook 2016 里面设置一个收件箱规则。相比之下，在 Outlook Web Access 里面设置规则的好处是规则保存在云上，且由服务器运行；而在 Outlook 2016 里面设置的规则必须在 Outlook 2016 运行的时候才得以执行。

在 Outlook 2016 里面设置规则也有好处：Outlook 对象模型 的接口十分健全，在我的哲学里，Outlook 的 GUI 其实是它的 COM 的图形版，而不是把 COM 理解为 GUI 的编程版；当然，有了 COM 就可以很方便地自动化规则设置。另一个自然的好处是，可以同步所有的账户的这个规则。并且同步规则本身需要使用 Outlook 2016 并不算是过分。

不过不能利用服务器执行规则是一个很大的缺点。为此，可以使用 Microsoft Graph API 来访问 Microsoft 提供的一整套数字化生活、工作和学习服务。今天要用到的只是冰山一角，不过管中窥豹，可见一斑。

我今天用 PowerShell 写了一个 程序 来做同步工作。它的工作流程大概是这样的：

1. 分析用户指定的 listing 文件，整理出来所有需要自动标记的电子邮件地址；
2. 启动浏览器，让用户选择账户登录，然后请求访问邮件设置的读写权；这里用户可以登录自己的 Microsoft 账户（“个人账户”）或者 Azure AD 账户（所谓“机构账户”“学校或工作账户”）；
3. 用户完成后，会被重定向到 Microsoft 提供的一个返回地址，是一个空白页面，授权信息在地址栏里；
4. 用户把地址复制到命令提示里，程序去兑换访问令牌；
5. 检查目前的收件箱规则，如果有一个对应的规则，则更新规则，否则建立一个新的规则。

Microsoft Graph API 是 RESTful 的，我就尝试了一下 Invoke-RestMethod cmdlet，发现特别好用！它可以自动解析 XML 或 JSON，举一个最简单的例子吧：

Invoke-RestMethod https://geelaw.blog/rss.xml -UseBasicParsing |
    Select-Object pubDate, title, category, description |
    Out-GridView

这段代码直接打开一个窗口显示我 blog 的文章日期、标题、分类和摘要。用 Invoke-RestMethod 访问 Microsoft Graph 非常轻松，具体可以看代码。写好之后我迅速同步了这个规则到 Outlook.com 和 UCSB 的邮箱上，整个流程就是这样的：