Add an EWS connector type: on-premises Exchange mailboxes

オープン
  • 何か問題がありますか？
#1,650 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
15/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
authentication, backend

調査の方向性

Start by reading how the EMAIL and ODATA connector types are wired: the ConnectorType enum, the migration 20261030100000_add_email_connector_type, and the engine that dispatches on type. Then check how fast-xml-parser and the outbound SSRF guard (SSRF_ALLOWED_HOSTS) are used. This is design work with an NTLMv2 implementation, so agree the scope with maintainers first. Done means an EWS type with the listed tools, passing the NTLM test vectors and the in-process EWS server tests.

索引モデルが issue の本文から書いたものです。

説明

Problem

The catalog cannot reach a mailbox on an on-premises Exchange server. The Outlook connector uses Microsoft Graph, which only exists for Microsoft 365 and Outlook.com. The Email (IMAP/SMTP) connector needs IMAP and SMTP to be enabled and reachable, cannot attach files to outgoing mail (so it cannot really forward), and on AnythingMCP Cloud its SMTP ports are blocked by the hosting network. Companies that run Exchange 2016, 2019 or Subscription Edition themselves, without Microsoft 365, have nothing to install.

Exchange Web Services (EWS) is on by default on those servers, because Outlook uses it. It runs over HTTPS on port 443, replies and forwards on the server (with the original's attachments), files sent mail itself and gives access to calendars and contacts later.

Microsoft is retiring EWS in Exchange Online (off by default since 1 October 2026, permanently on 1 April 2027) but not in Exchange Server. This connector is for on-premises Exchange; Exchange Online stays on the Outlook (Graph) connector.

Proposal

A new connector type EWS with its own engine and a fixed tool set, as the EMAIL and ODATA types have. The generic SOAP engine is not a fit: a WSDL import would make the model write nested EWS XML, and it has no NTLM.

Schema change
  • ConnectorType gains the value EWS.
  • Migration: ALTER TYPE "ConnectorType" ADD VALUE 'EWS'; in a new timestamped folder, same shape as 20261030100000_add_email_connector_type.
  • No new tables or columns, and no new AuthType. Non-secret settings live in connector.config.ews (server, auth method, domain, shared mailbox, certificate options); the username and password live in the encrypted authConfig (BASIC_AUTH).
Built-in tools

Prefixed per connector: list folders, search messages, get message, get attachment, set flags (read/unread, flagged), set categories, move messages, delete (to Deleted Items, never a hard delete), save draft (new, reply, reply all or forward), send message and send draft. Reads are annotated read-only, delete is destructive, the two sending tools are open-world. Delete and both sending tools are created switched off, and results that carry mail content say that it is untrusted text from the sender, as on the Email connector.

Authentication
  • NTLMv2 (what the EWS virtual directory offers by default) and Basic (only when an administrator enabled it), chosen from the server's WWW-Authenticate answer or fixed in the settings. Kerberos and OAuth are out of scope.
  • NTLM is implemented in the backend, with the message integrity code and the TLS channel binding that Extended Protection asks for. No maintained npm NTLM client supports channel binding, and Node's crypto no longer offers MD4.
  • No new runtime dependency: SOAP requests are templates, answers are parsed with the existing fast-xml-parser.
Behaviour in both deployment modes
  • Cloud: HTTPS only, the outbound SSRF guard applies (private, loopback and link-local addresses refused), the certificate must be valid. The Exchange server has to be reachable from the internet; the connector page shows the outbound address to allow.
  • Self-hosted: the same guard with the admin allowlist (SSRF_ALLOWED_HOSTS / Admin → Settings) for an internal server, and an opt-in "accept self-signed certificate" switch for an internal certificate authority.
  • One HTTPS connection per tool call, closed afterwards; connect and response timeouts and a response size cap. Credentials never reach a log line or an error message.
Tests

Unit tests against the published NTLM test vectors, request XML validated against Microsoft's EWS schemas, and an in-process EWS server (HTTPS, NTLM and Basic, in-memory mailbox) for the tool flows inside Jest. A live spec, gated behind RUN_EWS_LIVE=1, checks a real server read-only.

Catalog and docs

A catalog adapter "Exchange (EWS)" in category email with a setup guide (service account, shared mailbox rights, auth method, firewall), and docs/connectors/ews.md.

Later

Calendar (availability, events), contacts, Autodiscover.

主要言語
TypeScript
スター
856
フォーク
82
平均マージ
4時間 32分
マージ済み PR（30日）
468

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

HelpCode-ai/anythingmcp のほかの issue

HelpCode-ai/anythingmcp の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。