Моей компании необходимо обновить приложение для интеграции двустороннего протокола OAuth 2.0 для POP3. Я тестирую онлайн-аккаунт Outlook и пытаюсь пройти аутентификацию на outlook.office365.com (я также пробовал pop3.live.com).
Я зарегистрировался для получения пробной версии Exchange Online, используя свою тестовую учетную запись Outlook.
Я зарегистрировал свое приложение в Azure и включил разрешения для приложений API для MS Graph (Mail.ReadWrite, Mail.Send) и Exchange (full_access_as_app). Та же учетная запись Outlook, которую я использовал для регистрации Exchange, является глобальным администратором клиента Azure.
Я могу запросить действительный токен OAuth как из конечных точек Graph, так и из Exchange. Однако, когда я использую токен и пытаюсь войти на сервер POP, я получаю следующую ошибку:
<PopCmdSent>AUTH XOAUTH2 [token]</PopCmdSent>
<PopCmdResp>-ERR Protocol error. Connection is closed. 10</PopCmdResp>
С последующим:
<error>POP3 authentication failed</error>
Я не уверен, что означает эта ошибка. Нужно ли настраивать мой почтовый компонент для использования другого протокола (не уверен, возможно ли это)? Может ли это быть проблемой в способе регистрации / аутентификации моего приложения или в настройках безопасности Exchange?
Логин работает нормально, если я использую Basic Auth вместо OAuth.
Как я могу решить эту проблему?
Редактировать
Недавно я наткнулся на статью Microsoft, в которой упоминается та же ошибка, но она связана с Exchange Server 2007. В статье говорится, что решение состоит в том, чтобы увеличить параметр MaxCommandSize на сервере Exchange с 40 КБ по умолчанию.
Это буквально единственное другое место, где я видел ссылку на эту ошибку в Интернете:
Интересно, актуально ли это для Exchange Online / Outlook? Я не могу найти аналогичный параметр в своей пробной версии Exchange Online или в настройках почты Outlook
Редактировать 2
Я обменялся электронной почтой с разработчиком почтового компонента, который я использую (Chilkat Mailman). Очевидно, он несколько месяцев застрял на одной и той же проблеме. Он говорит, что правильные протоколы для XOAUTH2 реализованы в компоненте и должны работать одинаково для любого почтового сервера.
Однако у него также возникают проблемы с привязкой регистрации приложения Azure к определенной учетной записи O365 и получением правильной области / разрешений для проверки подлинности учетной записи.
Приятно слышать, что я не единственный, кто борется с этим, и что мне не хватает какой-то очевидной части. Но также вызывает беспокойство то, что разработчик популярного почтового компонента испытывает проблемы с воспроизведением того, что раньше было невероятно простым процессом.
Он написал статью о своем нынешнем понимании (не уверен, что это актуально):