Email как канал приёма заявок в helpdesk: типичные грабли и как их обойти

Bounce и auto-reply — создают тикеты-мусор

Самая частая проблема свежеподключённого email-канала: на второй день в helpdesk появляются тикеты с темой «Mail Delivery Failed» и от отправителя «Mail Delivery System». Это bounce — уведомление почтового сервера о том, что какое-то ваше письмо не доставилось. Парсер видит «новое письмо в support@» — заводит тикет.

Хуже того: пользователь ушёл в отпуск и поставил автоответ. Вы отправляете ему «ваша заявка принята №12345». Его автоответчик отвечает «я в отпуске». Парсер видит новое письмо — заводит ВТОРОЙ тикет. Вы отвечаете на него «принято». Цикл. За ночь в helpdesk сотни одинаковых тикетов.

Как фильтровать (универсально):

• Заголовок Auto-Submitted ≠ no — RFC 3834, признак автогенерации
• Content-Type: multipart/report — RFC 6522, формат DSN
• From содержит mailer-daemon / postmaster / no-reply / noreply / bounce / delivery
• Subject содержит «mail delivery failed», «undelivered mail», «delivery status», «возврат сообщения», «не доставлено»

Любое совпадение → пропустить, не создавать тикет, пометить как прочитанное в IMAP. В TIQQET этот фильтр включён по умолчанию и закрывает 99% случаев.

Threading — потерянные ответы

Пользователь создал тикет #1234, через 2 часа отвечает на письмо «ваша заявка зарегистрирована». Helpdesk должен понять, что это ответ к тикету 1234, и подцепить как комментарий. Если не понял — заведёт НОВЫЙ тикет 1235, и оператор видит два тикета на одну проблему, не связанные между собой.

Стандартный механизм — заголовки In-Reply-To и References. При исходящем письме helpdesk генерирует уникальный Message-ID для тикета 1234. Когда пользователь отвечает — его почтовый клиент копирует Message-ID в In-Reply-To. Helpdesk при приёме парсит этот заголовок и находит тикет.

Когда threading ломается:

• Outlook режет References — особенно через Exchange, на 4-5-м звене переписки заголовки теряются
• Пользователь нажал «Новое письмо» вместо «Ответить» — заголовков нет
• Пересылка через коллегу — все Message-ID меняются

Запасной механизм: номер тикета в теме письма. Helpdesk пишет [ServiceDesk] Заявка #1234: текст темы. Если In-Reply-To не сработал, парсер ищет в Subject регулярку #(\d+) и привязывает к тикету. В TIQQET это второй уровень threading: сначала Message-ID, потом #N в теме, потом — новый тикет.

Кодировки и проблемы с кириллицей

Тема письма закодирована по RFC 2047: Subject: =?UTF-8?B?0J/RgNC40LLQtdGCINC80LjRgA==?=. Если парсер не декодирует — в helpdesk видна каша из вопросительных знаков.

Имена вложений — отдельная история. Старые версии Outlook (до 2016) кодируют имя файла по RFC 2047 нестандартно. iOS Mail вообще шлёт без кодировки, в latin1, и пишет «Отчёт.docx» как «Î¢Ï‡ç‘Ñ‚.docx». Когда такое имя сохраняется на диск — файл вообще нечитаем.

Решение, которое работает в большинстве случаев:

1. При декодировании subject — пробуйте сначала UTF-8, потом windows-1251, потом koi8-r
2. Имя файла декодируйте через библиотеку (в Node — mailparser делает это автоматически правильно). Если получили «battlecharacters» — попробуйте latin1→utf8 reinterpret
3. Если декодирование не удалось — сохраняйте файл с сгенерированным именем (UUID + расширение) и в карточке вложения показывайте оригинальное имя из заголовка

Вложения — что фильтровать

Email — основной вектор фишинга. Если бесконтрольно принимать все вложения — это вопрос времени, когда кто-то пришлёт macro-enabled Excel или подменённый PDF с эксплоитом.

Базовая защита:

• Blacklist расширений: .exe, .bat, .cmd, .scr, .vbs, .ps1, .msi, .jar, .com — не сохранять
• Размер: > 25 МБ часто отрезают сами почтовые серверы; > 50 МБ — точно отказывать
• MIME-type проверка: не доверять расширению, смотреть «магические байты» (PDF начинается с %PDF-, ZIP с PK, etc)
• Антивирус-проверка: для критичных установок — ClamAV в pipeline сохранения

Что часто забывают: имена файлов с traversal-патернами. Файл с именем ../../etc/passwd при сохранении на диск может выйти за пределы каталога attachments. Защита: regex [^a-zA-Z0-9._-] заменять на _, плюс отдельно проверять, что итоговый путь начинается с allowed-каталога.

Спам в support@

Любой публичный support-адрес через 2-3 месяца попадает в базы рассыльщиков. Объём спама может достигать 200-500 писем в день, что засоряет очередь оператора и снижает доверие к системе.

Многоуровневая защита:

1. SPF + DKIM + DMARC на стороне почтового провайдера — 80% спама отсеивается до парсера
2. Blacklist отправителей в helpdesk — если домен/email прислал 5 раз подряд явный спам, добавить в чёрный список одним кликом
3. Whitelist для известных доменов — корпоративные адреса своих клиентов автоматически проходят без триажа
4. Регистрационные ворота — для «новых» отправителей создавать не тикет, а заявку на регистрацию (одобряет оператор). Защищает от спама и от случайных писем не по адресу

В TIQQET все четыре уровня — встроенный функционал, настраиваются за 10 минут в админке.