Підключення поштової скриньки
Система заявок збирає вхідну пошту через IMAP і надсилає відповіді через SMTP. У більшості постачальників достатньо імені користувача та пароля. Microsoft 365 — виняток: нижче про те, чому так і як розв'язати це приблизно за десять хвилин.
Що має підтримувати ваш постачальник
Знайдіть свого постачальника нижче. Два випадки з трьох не потребують жодної додаткової роботи.
| Постачальник | Що вам потрібно | Підключається напряму |
|---|---|---|
| Власний поштовий сервер, вебхостинги (all-inkl, Strato, IONOS, Mailbox.org …), локальний Exchange | Ім'я користувача та пароль поштової скриньки. | так |
| Google Workspace / Gmail | Пароль застосунку. Google відхиляє звичайний пароль облікового запису. Для облікового запису має бути ввімкнений двоетапний вхід — без нього Google не пропонує паролів застосунків. | так |
| Microsoft 365 / Outlook.com | Напряму неможливо. Microsoft вимкнула вхід за іменем користувача та паролем для IMAP, а паролі застосунків не допомагають, бо працюють через той самий механізм. Обхідний шлях — окрема поштова скринька служби підтримки з переспрямуванням (посібник нижче). | ні |
Чому Microsoft 365 не підключається напряму
Microsoft вимкнула «базову перевірку» для IMAP в Exchange Online. Це стосується кожної програми, яка читає скриньку Microsoft 365 напряму, а не лише нашої. Наступник — OAuth2, який потребує реєстрації власного застосунку у вашому каталозі Azure та надання йому доступу. OAuth2 ми поки що не підтримуємо — це заплановано, але дати ми навмисно не називаємо. Для багатьох клієнтів шлях нижче однаково кращий: він не потребує ні адміністратора каталогу, ні дозволів, які спливають.
Входу це не стосується: Microsoft Entra ID можна підключити як постачальника SSO — як і будь-якого іншого, що говорить OIDC або SAML 2.0. Лише читання пошти через IMAP потребує в Microsoft OAuth2, і саме його ми поки що не пропонуємо.
Розв'язання: окрема поштова скринька служби підтримки з переспрямуванням
Ви створюєте окрему скриньку в постачальника, який приймає ім'я користувача та пароль, — зазвичай вона входить у ваш пакет вебхостингу. Адресу, яку знають ваші клієнти, переспрямовують на неї. Система заявок читає лише цю одну скриньку.
Що це вам дає
- Система заявок ніколи не отримує доступу до вашої корпоративної скриньки, а лише до листів, переспрямованих на неї.
- Жодної реєстрації застосунку, жодної згоди адміністратора каталогу, жодних дозволів, які спливають через 90 днів.
- Працює однаково в кожного постачальника — зокрема й після зміни поштового постачальника.
- Служби підтримки в хмарі типово працюють саме так. Різниця: тут скринька ваша, і дані залишаються на вашому сервері.
Крок за кроком
Створіть скриньку служби підтримки
У вашого вебхостера або будь-якого постачальника, який дозволяє IMAP з іменем користувача та паролем. ⚠️ Адреса не може бути на вашому головному домені, якщо пошту цього домену вже веде Microsoft 365, — візьміть піддомен або домен хостера. Запишіть сервер і порт IMAP (зазвичай 993 з SSL) та сервер і порт SMTP (зазвичай 465 з SSL або 587 зі STARTTLS).
Налаштуйте переспрямування в Microsoft 365
У центрі адміністрування Microsoft 365 переспрямуйте адресу, на яку пишуть ваші клієнти, на нову скриньку. ⚠️ Microsoft типово блокує автоматичне переспрямування на зовнішні адреси — ваш адміністратор має явно дозволити його в політиці фільтра вихідного спаму. Інакше нічого не надходить, і скринька теж не показує помилки.
Внесіть у систему заявок
Settings → E-mail: укажіть сервер, порт і SSL для IMAP, а потім для кожної команди скриньку з її іменем користувача та паролем. Цільову теку для опрацьованих листів набирати не треба — «Read from server» отримує справжній список тек, бо назви тек у кожного постачальника мають інакший вигляд.
Задайте адресу відправника
Під SMTP ви вирішуєте, яку адресу ваші клієнти бачитимуть як відправника ваших відповідей. Зазвичай правильна та, яку вони вже знають. Надсилання має йти через сервер, що дозволяє цю адресу відправника, — зазвичай через того самого постачальника, що й скринька служби підтримки.
Перевірте
Надішліть лист на свою адресу для клієнтів. За хвилину заявка вже в системі, а підтвердження дійшло до відправника. Якщо нічого не надходить, спершу подивіться в теці спаму скриньки служби підтримки.
На що варто зважати
Переспрямований лист може потрапити в спам
У скриньці-отримувачі сервер переспрямування вже не збігається з відправником листа. У перші дні перевіряйте теку спаму й додайте джерело переспрямування до списку дозволених.
Надсилання — це друга половина
Microsoft обмежує й надсилання через SMTP з іменем користувача та паролем і планує його вимкнути. Плануйте надсилання через того самого постачальника, що й скринька служби підтримки, від самого початку.
Жодної автовідповіді про відсутність на скриньці служби підтримки
Автоматичні відповіді з обох боків можуть відбиватися одна від одної без кінця. Підтвердження вашим клієнтам надсилає сама система заявок — скриньці воно не потрібне.
Одна скринька на команду
Система заявок читає рівно одну скриньку на команду. Для кількох напрямів — скажімо, ІТ та бухгалтерії — створіть по одній скриньці та по одному правилу переспрямування.
Короткий посібник для Google Workspace і Gmail
Тут переспрямування не потрібне. Скринька підключається напряму, щойно у вас є пароль застосунку.
- 1.Увімкніть двоетапний вхід для облікового запису Google. Без нього Google не пропонує паролів застосунків.
- 2.Створіть пароль застосунку в налаштуваннях безпеки облікового запису й запишіть його — його показують лише один раз.
- 3.Внесіть його в систему заявок: IMAP imap.gmail.com, порт 993 з SSL; SMTP smtp.gmail.com, порт 465 з SSL. Беріть пароль застосунку, а не пароль облікового запису.
- 4.Не набирайте назв тек: Gmail тримає свої системні теки під назвами на кшталт «[Gmail]/…». Скористайтеся «Read from server» у системі заявок і оберіть теку зі списку.
Не певні, що стосується вашого постачальника? Напишіть нам, яким ви користуєтеся, і ми назвемо найкоротший шлях.
Запитати нас