|
|
Здравствуйте.
Попытаюсь привести пример решения типовой проблемы:
> Здравствуйте!! у одного пользователя домена письма от другово пользователя попадают в папку "нежелательная почта" правил перемещения я не обнаружил не в настройка пользователя ни правилах Outlook 2013.
> последний по всей вероятности не причем так как даже пр отключеном почтовом клиенте письма всеравно перемещаются в "нежелательную пачту" как решить проблему без пересоздания учетной записи??
Во-первых, правила сортировки спама могут быть включены и на уровне настроек домена - проверьте.
Вторым этапом надо определить, попало ли письмо в папку со спамом во время доставки или же было перенесено почтовым клиентом. Историю доставки письма (включающую в себя применённые правила) можно довольно просто получить из логов сервера, зная его Queue ID. Он содержится в самом верхнем заголовке Received письма, например, в этом письме:
Received: by mail.communigate.ru (CommuniGate Pro PIPE 6.3.6t)
with PIPE id 59210462; Tue, 04 May 2021 08:27:33 +0300
Queue ID равен 59210462, в логах он часто заключён в квадратные скобки. Отметка времени из этого заголовка поможет сузить временной интервал при поиске записей в логах. Отфильтруем лог по [59210462] на уровне Проблемы:
08:27:33.001 2 PIPE [59210462] received in {Submitted/tm394.sub}, 2663 bytes
08:27:33.008 2 QUEUE([59210462]) from <original@return.path>, 2663 bytes (<f725a63d-f228-06a6-ac27-c3ca8f0a6cf3@domain>)
08:27:33.009 2 QUEUE([59210462]) enqueued
Обнаруживаем попутно, что какой-то "добрый" человек включил правило Vacation для аккаунта support:
08:27:33.013 2 LOCALRULES(support) [59210462] rule(#Vacation) Reply -> [59210485]
Видно, как правило создало автоматический ответ - его Queue ID 59210485 - не верьте ему, в полном составе поддержка в отпуск не уходит никогда.
Нам важна эта запись:
08:27:33.017 2 MAILBOX(support/INBOX) [59210462] stored as {389440}
Она означает, что во время доставки письмо было помещено в папку INBOX (а не в какую-либо другую) с UID (уникальный идентификатор для этой папки) 389440. Он, как мы видим, в логах фигурирует заключённым в фигурные скобки.
Если бы письмо было помещено в папку Спам во время доставки, то похожая запись об этом была бы в логе.
Но письма всё-таки оказываются в этой папке, и если не во время доставки, то остаётся только их перемещение с помощью клиентов по протоколам IMAP, WebUser, XIMSS, AictiveSync. Как мы видим, сервер записывает в лог факт сохранения письма в папку, используя UID письма в этой папке. Проще всего узнать UID, открыв письмо в классическом WebUser интерфейсе (вы ведь знаете, что администратор с нужными правами может открыть письмо в папке другого аккаунта): в адресной строке браузера UID будет содержаться в виде параметра MSG=38515. Попробуем пофильтровать лог по операциям с папкой Junk в аккаунте support с письмом UID=38515. Фильтровать будем по MAILBOX(support/Junk) на уровне Проблемы и искать {38515}. (Если бы аккаунт support был не в главном, а другом домене, то надо было бы указать и имя домена MAILBOX(support@other.domain/Junk)). Искать придётся во временном промежутке от момента доставки письма на сервер (в верхнем заголовке Received) до момента сохранения письма в папку (IMAP клиенты и WebUser показывают это время как время "Получено"). Кое-что нашли:
09:25:12.180 2 MAILBOX(support/Junk) {38515} appended @0: 58+3220 bytes
Теперь мы знаем точное время сохранения этой копии письма в папку Junk. Где-то рядом должны быть записи протокола, использованного для перемещения письма. В окне просмотра логов в WebAdmin ограничиваем время просмотра тремя-пятью секундами до момента сохранения и парой секунд после, фильтруем по UID 38515 на уровне Всё:
09:25:12.180 2 MAILBOX(support/Junk) {38515} appended @0: 58+3220 bytes
09:25:12.180 5 IMAP-001300([00.22.52.00]:22293) s-out: 167 OK [COPYUID 304785910 237001 38515] COPY completed\r\n
Вторая строчка - это ответ сервера по протоколу IMAP на команду UID COPY и он в качестве ркзультата содержит UID нашего письма. Если отфильтровать лог по IMAP-001300, то видно и саму команду
09:25:12.176 5 IMAP-001300([00.22.52.00]:22293) s-inp: 167 uid copy 237001 "Junk"
И можно найти ответственный за операцию аккаунт. Конечно, повезло, что на сервере уровень лога IMAP был установлен на уровень Всё.
В сухом остатке: некоторые IMAP клиенты (Thunderbird, например) могут самостоятельно перемещать письма в папку Спам, опираясь исключительно на свои внутренние (не контролируемые сервером) критерии.
On 2021-04-29 13:55 , Alexey Maximov alexm@communigate.ru wrote:
Дорогие подписчики!
Наше руководство поставило задачу распространять в массы накопленный в техподдержке опыт. Обещают даже какие-то курсы.
В связи с этим, просим вас поделиться описанием наиболее часто встречающихся проблем.
/Например:/ "не отправляется письмо", "не приходит почта", "не получается войти", "клиент ругается на неверный пароль, хотя пароль вводят правильный" и т.п.
Мы попробуем здесь, в этом списке, изложить основные методики сбора данных и первичного анализа.
На базе этого обсуждения планируется отдельный курс.
Также, расскажите, встречаете ли вы неудобства в логах и мониторах сервера. Мы передадим разработчикам.
Спасибо!
-- Best regards,
Alexey Maximov
--
Best regards,
Dmitry Akindinov
|
|