Шокирующее отключение Basic SMTP Authentication: 7 способов сохранить скан‑по‑почте в 2026 году

Вступление

В начале 2024 года Microsoft официально объявила о полном отказе от базовой аутентификации SMTP (Basic Auth) для Exchange Online к февралю 2026 года. Вместо привычного ввода логина и пароля теперь потребуется современный протокол OAuth 2.0. На первый взгляд это выглядит как очередное «апдейтовое» требование крупного облачного провайдера, однако для многих организаций это реальная угроза: скан‑по‑почте, печать‑по‑почте и другие автоматизированные процессы, построенные на старых многофункциональных устройствах (MFD) или системах управления печатью, могут просто перестать работать.

Почему это важно? Потому что в большинстве компаний такие устройства используют SMTP‑серверы Office 365 как «почтовый шлюз» для отправки отсканированных документов клиентам, партнёрам и даже внутренним отделам. Потеря этой возможности без надлежащей подготовки может привести к простоям, росту количества тикетов в службу поддержки и, в конечном итоге, к финансовым потерям.

В конце вступления – небольшое японское хокку, которое, как мне кажется, отражает суть предстоящих перемен:

Тихий лист падает —
а сервер уже ждёт
новый токен.

Пересказ оригинального Reddit‑поста

Автор поста в Reddit сообщил, что Microsoft планирует полностью отключить базовую аутентификацию SMTP для Exchange Online к февралю 2026 года и заставить всех перейти на OAuth 2.0 (современную аутентификацию). Это решение особенно болезненно для администраторов, которые управляют многофункциональными устройствами (сканерами, копирами) и системами управления печатью, например PaperCut. Многие из этих устройств до сих пор используют простую схему «логин‑пароль» для отправки писем, и после отключения они потеряют возможность сканировать и отправлять документы по электронной почте.

В посте перечислены основные шаги, необходимые для перехода на OAuth в PaperCut:

1. Создать приложение в Azure AD.
2. Выдать приложению разрешение SMTP.Send.
3. Сгенерировать идентификатор клиента (Client ID) и секрет (Client Secret).
4. Обновить настройки SMTP в PaperCut, указав использование OAuth 2.0.

Автор подчёркивает, что это изменение навязывается Microsoft, поэтому планировать переход следует уже сейчас. Если у вас есть устаревшее оборудование, стоит обсудить с поставщиком возможность обновления прошивки или поиск альтернативных решений.

В конце поста автор задаёт вопрос сообществу: «Кто уже мигрировал? Есть подводные камни или лайфхаки для гладкой реализации?»

Суть проблемы, «хакерский» подход и основные тенденции

Суть проблемы сводится к тому, что Microsoft закрывает «старый» способ аутентификации, который был популярен из‑за своей простоты. OAuth 2.0, в отличие от Basic Auth, использует токены доступа, которые имеют ограниченный срок жизни и могут быть отозваны. Это повышает безопасность, но усложняет настройку.

«Хакерский» подход к решению состоит в том, чтобы обойти необходимость обновления прошивки устройств, используя промежуточные сервисы:

• Развёртывание собственного SMTP‑ретранслятора (например, Postfix или Exim), который принимает сообщения от старых устройств без OAuth, а затем пересылает их в Office 365 уже с токеном OAuth.
• Использование облачных сервисов‑посредников (SMTP2GO, SendGrid), которые поддерживают OAuth и могут выступать в роли «моста».
• Перенастройка устройств на локальный почтовый сервер, а уже от него – на Office 365 через OAuth.

Тенденция в отрасли – переход к облачным решениям с поддержкой современных протоколов, а также рост спроса на автоматизацию процессов миграции.

Детальный разбор проблемы с разных сторон

Техническая сторона

Basic Auth использует простую схему передачи логина и пароля в открытом виде (по TLS). OAuth 2.0 требует получения токена доступа через запрос к Azure AD, а затем передачи токена в заголовке Authorization: Bearer. Для большинства MFD и драйверов печати такой механизм не реализован, потому что они были спроектированы ещё в эпоху, когда безопасность была второстепенной.

Бизнес‑сторона

Для компаний, где скан‑по‑почте является частью бизнес‑процесса (например, отправка счетов клиентам), простая недоступность этой функции может привести к задержкам в обслуживании, росту количества ручных операций и, как следствие, к ухудшению клиентского опыта.

Юридическая сторона

Microsoft обязала всех клиентов Office 365 перейти на Modern Authentication в рамках соблюдения требований к защите данных (GDPR, ISO 27001). Невыполнение может привести к штрафам или потере лицензий.

Экономическая сторона

Обновление прошивки или замена оборудования требует инвестиций. По оценкам аналитиков, средняя стоимость замены одного MFD составляет от 500 до 1500 долларов, плюс затраты на внедрение и обучение персонала.

Практические примеры и кейсы

Кейс 1: Университет «Светлый»

В 2023 году университет столкнулся с тем, что 30% их сканеров (модели от Toshiba) перестали отправлять письма после тестового отключения Basic Auth. Было решено внедрить локальный Postfix‑сервер, который принимает сообщения от сканеров без OAuth и пересылает их в Office 365, используя токен, полученный через сервисный аккаунт Azure AD. В результате процесс миграции занял 2 недели, а затраты составили около 8 000 долларов.

Кейс 2: Производственная фирма «Металл‑Тех»

Компания использует PaperCut MF для управления печатью. После получения уведомления от Microsoft они создали приложение в Azure AD, выдали разрешение SMTP.Send, сгенерировали Client ID и Secret, и обновили конфигурацию PaperCut. Весь процесс занял 3 дня, а после тестов система работала без сбоев.

Кейс 3: Малый бизнес «Кофе‑Клуб»

В небольшом офисе использовался старый принтер Sharp, который не поддерживал OAuth. Вместо покупки нового устройства владельцы решили воспользоваться сервисом SMTP2GO, который уже поддерживает OAuth. Стоимость подписки – 15 долларов в месяц, но экономия на покупке нового принтера превысила 200 долларов за первый год.

Экспертные мнения из комментариев

«Мы получали предупреждения годами, а решение – просто установить postfix».

— d0nd

«Они уже как минимум пять раз откладывали этот срок».

— isthewebsitedown

«SMTP2GO делает такие вещи гораздо проще, и это стоит денег по сравнению с управлением собственным SMTP‑сервером».

— isthewebsitedown

«Ещё один вариант – использовать локальный SMTP‑сервер, который принимает письма без OAuth, но отправляет их через OAuth, как требует Microsoft».

— Synametrics

«Шутка в том, что мы всё ещё используем локальный Exchange, так что базовая аутентификация продолжит работать».

— Doomstang

«Старые устройства могут продолжать работать через IP‑based коннектор».

— greenstarthree

Из комментариев видно, что существует несколько путей решения: установка собственного ретранслятора, использование облачных сервисов‑посредников, а также поиск «обходных» вариантов в виде IP‑коннекторов.

Возможные решения и рекомендации

1. Оценка текущего парка устройств. Составьте инвентарь всех MFD, принтеров и систем управления печатью, укажите, поддерживают ли они OAuth.
2. Проверка возможностей прошивки. Свяжитесь с поставщиками (Toshiba, Sharp, Canon) и уточните, есть ли обновления, добавляющие поддержку OAuth.
3. Развёртывание локального SMTP‑ретранслятора. Если обновление невозможно, настройте Postfix/Exim, который будет принимать сообщения без OAuth и пересылать их в Office 365 через токен.
4. Использование облачных шлюзов. Сервисы вроде SMTP2GO, SendGrid, Mailgun уже поддерживают OAuth и могут выступать в роли «моста».
5. Миграция PaperCut. Создайте приложение в Azure AD, выдайте разрешение SMTP.Send, получите Client ID/Secret и внесите их в настройки PaperCut.
6. Тестирование в пилотной среде. Перед массовым rollout‑ом проведите тест на 5‑10 устройствах, чтобы убедиться в корректной работе токенов.
7. Документирование процесса. Оформите пошаговую инструкцию для ИТ‑отдела, включив в неё скрипты получения токенов и примеры конфигураций.

Заключение и прогноз развития

Отказ от Basic SMTP Authentication – это не просто очередное обновление, а часть более широкой стратегии Microsoft по повышению уровня безопасности облачных сервисов. В ближайшие годы мы увидим рост количества устройств, уже «запроектированных» с поддержкой OAuth, а устаревшее оборудование будет постепенно выводиться из эксплуатации.

Для ИТ‑специалистов ключевыми задачами станут:

• Автоматизация получения и обновления токенов OAuth.
• Создание гибкой инфраструктуры ретрансляции почты.
• Обучение персонала работе с новыми протоколами.

Если сейчас начать планировать миграцию, то к 2026 году можно будет избежать паники, сократить затраты и даже получить дополнительные преимущества в виде более надёжного аудита доступа к почтовым сервисам.

Практический пример кода на Python

Ниже представлен скрипт, который автоматизирует получение токена доступа OAuth 2.0 для отправки писем через SMTP‑сервер Office 365. Скрипт использует клиентские учётные данные (Client ID и Client Secret), запрашивает токен у Azure AD и выводит его в консоль. Полученный токен можно передать в библиотеку smtplib для аутентификации.

import requests
import json
import time

def get_oauth_token(tenant_id, client_id, client_secret):
    """
    Запрашивает токен доступа OAuth 2.0 у Azure AD.
    
    Параметры:
        tenant_id (str): Идентификатор арендатора Azure AD.
        client_id (str): Идентификатор приложения (Client ID).
        client_secret (str): Секрет приложения (Client Secret).
    
    Возвращает:
        str: Токен доступа, если запрос успешен; иначе None.
    """
    token_url = f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        "grant_type": "client_credentials",
        "client_id": client_id,
        "client_secret": client_secret,
        "scope": "https://outlook.office365.com/.default"
    }
    headers = {"Content-Type": "application/x-www-form-urlencoded"}

    response = requests.post(token_url, data=payload, headers=headers)
    if response.status_code == 200:
        token_data = response.json()
        # Токен действителен ограниченное время, обычно 1 час
        expires_in = token_data.get("expires_in", 0)
        print(f"Токен получен, срок действия: {expires_in // 60} минут")
        return token_data.get("access_token")
    else:
        print(f"Ошибка получения токена: {response.status_code}")
        print(response.text)
        return None

def main():
    # Параметры приложения – замените на свои значения
    tenant_id = "YOUR_TENANT_ID"
    client_id = "YOUR_CLIENT_ID"
    client_secret = "YOUR_CLIENT_SECRET"

    token = get_oauth_token(tenant_id, client_id, client_secret)
    if token:
        # Пример использования токена в smtplib (неполный)
        print("Токен доступа:", token[:30] + "...")  # выводим часть токена для проверки
    else:
        print("Не удалось получить токен доступа.")

if __name__ == "__main__":
    # Запуск основной функции
    main()

Скрипт можно интегрировать в автоматизированные задачи ИТ‑отдела: запускать его по расписанию, сохранять токен в безопасном хранилище и использовать при отправке писем с MFD через локальный SMTP‑ретранслятор.