— Где мое письмо?
— Нам отправляли, а мы не получали!
— У вас почта не работает, письма пропадают.
Знакомые слова? С проблемой пропажи сообщений сталкивается любой администратор электронной почты. На самом деле письма никуда не пропадают, нужно просто знать, где их искать. Давайте соберем все эти потайные места вместе и составим мини-шпаргалку по их поиску.
Первым делом нужно выяснить, «а был ли мальчик?» На практике часто происходит искажение информации, когда пользователь специально или случайно выдает желаемое за действительное, поэтому первое, что нужно сделать — это собрать максимально точную информацию о пропавшем письме. Она должна включать в себя следующее.
- Источник проблемы. Кто и когда сообщил о проблеме, это часто помогает при расследовании.
- Адрес электронной почты. Часто бывает, что известен только домен или название организации отправителя, например, «подрядчик Связькомстрой отправил нам письмо». Как хочешь, так и ищи. Поэтому лучше узнать домен, в идеале — адрес отправителя.
- Адрес электронной почты получателя. С этим проще, но тоже бывают ситуации, когда реально отправляют на совершенно другой или ошибочный адрес.
- Время отправления сообщения. Понятно, что точное время никто не скажет, но хотя бы временной промежуток отправки для сужения поиска.
- Были ли в письме присоединенные файлы, их размер и тип. Обычно помогает при определении проблем с ограничением на размер. Исполняемые файлы могут быть вырезаны антивирусом или молча помещены в карантин.
Только после получения этих данных можно приступать к решению проблемы. Идеально, если у вас есть все данные. Бывают случаи, когда пользователь знает только следующее: «Подрядчик Связьморстрой отправил на прошлой неделе мне сообщение, а его нет«. Вот как хочешь, так и ищи.
Пропажа сообщения может произойти в трех местах:
- На стороне отправителя. Тогда решением проблемы должен заниматься отправитель, ваша задача сказать своему пользователю причину, а он уже сообщает отправителю, чтобы тот передал своему ИТ отделу. Вы повлиять на доставку никак не можете.
- На сервере получателя. В этом случае ошибку исправляет администратор вашей почтовой системы.
- В почтовой программе получателя. Администратор сообщает, что письмо доставлено в почтовый ящик, и задача поиска целиком ложится на плечи HelpDesk и пользователя. Администратор не должен напрямую общаться с пользователем.
Поэтому крайне важно определить, в каком месте произошла проблема, причины ее возникновения и только потом уже предпринимать действия по ее разрешению. Рассмотрим каждый пункт по отдельности.
Пропажа сообщения на стороне отправителя
- Сообщение вернулось отправителю с ошибкой и было проигнорировано. Это самая гадкая ситуация, когда отправитель послал письмо, оно вернулось с ошибкой доставки и он никаких действий не предпринимает, или удаляет письмо, или утверждает, что ошибка на стороне получателя. Это неправильная позиция. Почтовый сервер получателя — это дверь. В нее можно войти при условии соответствия размерам этой двери. Поэтому, если хочешь, чтобы письмо дошло, придётся подстраиваться под эти размеры.
- Письмо было отправлено не тому получателю или в адресе получателя содержится ошибка. Встречается довольно часто, когда адрес диктуется по телефону, адрес получателя изменился, сотрудник уволился, переименовали домен получателя, а старые адреса не оставили и так далее. Решение проблемы — узнать правильный адрес получателя.
- Превышен размер сообщения на принимающем сервере. По умолчанию ограничение на размер сообщения всегда было 10 МБ, поэтому лучше приучить своих пользователей не пересылать файлы больше 8МБ в одном письме.
- Почтовый ящик получателя переполнен и в данный момент недоступен. Часто встречается на адресах sales@, info@ или перегруженных сотрудников, которые просто ушли в отпуск. В этом случае только звонить адресату и сообщать о проблеме.
- Сбой в DNS, почтовый сервер получателя не может быть найден. Довольно редкая проблема, но встречается, когда DNS сервер отправителя не может разрешить имя почтового сервера получателя. Администратор может узнать IP адреса через сторонние сервисы и временно добавить зону в свой DNS для домена получателя.
- Сбой Интернет-канала, когда от одного провайдера не видно сети другого провайдера. Встречается крайне редко, в основном у небольших провайдеров. Исправляется обращением к провайдеру.
- Сервер получателя обрывает SMTP сессию, т.к. сервер отправителя находится в DNS Block list или просто заблокирован. Бывает, что администраторы сильно затягивают гайки на принимающем сервере, бывает, что все сети провайдера попадают в DNS Block list. Нужно просто обратиться к владельцу DNSBL и они вычеркнут из него, или звонить получателю, чтобы добавили в белые списки.
- Неправильно настроены DNS записи у отправляющего сервера PTR, SPF, отсутствие MX записи. Ситуацию может исправить только администратор отправляющего сервера, хотя администратор принимающего сервера может добавить IP адрес в белый список.
- Отправитель обманывает, сообщение не было отправлено по каким-то причинам. Это очень частая ситуация, особенно во взаимоотношениях подрядчик-заказчик, когда подрядчик не успевает по срокам и таким образом выигрывает себе еще денёк-другой. В данном случае отправляются логи с последним письмом от отправителя.
- Сообщение еще находится в очереди на передачу. Многие люди считают, что почта должна ходить мгновенно. К сожалению, у нас не везде широкие каналы, быстрые серверы, поэтому возможны задержки в очередях.
Пропажа сообщения на почтовом сервере получателя
- Все возвращаемые серверу отправителя ошибки, перечисленные выше.
- Сбой почтового сервера. Многие считают, что почтовые серверы работают всегда, но это далеко не так. Я сталкивался в своей практике с тем, что или серверы, или каналы у довольно известных компаний не работали какое-то время. Причем пока разбираешься с проблемой, видишь, как они вдруг начинают работать.
- Сбой в службе или записях DNS. Иногда это тоже случается, поэтому нужно проверять все дважды.
- Проверка существования отправителя Callback verification и наличие фильтра greylist. Если в организации отправителя используется GreyList, а в вашей системе Callback verification, то ваша система никогда не сможет проверить отправителя и не примет письмо. Я об этом писал в статье: http://www.exchangerus.ru/2008/12/11/vojna-mezhdu-dnsblgreylisting-i-callback-verification-prodolzhaetsya/
- Использование ненадежных поставщиков DNS Block list и ошибочная блокировка. Особенно актуально при обмене с небольшими организациями, чьи серверы попадают в DNS Block list.
- Ложные срабатывания антиспама, когда сообщение отправителя распознается как спам и помещается в карантин. Это стандартная проблема, поэтому контент-фильтры сильно закручивать не стоит.
- Сообщение еще находится в очереди на отправку между серверами. Об этом уже написано выше.
- Настроена пересылка писем без помещения в почтовый ящик.
Пропажа сообщения в почтовом клиенте получателя
- Сообщение попало в Junk email. Фильтр Outlook живет сам по себе и обладает довольно странной логикой. Поэтому нужно всем доверенным отправителям с помощью транспортных правил добавлять флаг «SCL=-1» в заголовок сообщения или политиками распространять белые списки в Outlook
- Отработали правила, переместившие сообщения из входящих в другую папку. Когда правил много и пользователь забывает устанавливать «Stop other rules» в конце правила, то письма залетают в другие папки или удаляются.
- Настроены фильтры в виде Outlook на частичное отображение информации, например, плюсик на Today. Это анекдотичная ситуация, но бывает, когда плюсик на группировке Today в Outlook нажимают и не видят писем за сегодня.
- Существует клиент POP3/IMAP4 на другом компьютере, КПК, телефоне, который выкачивает по времени сообщения с удалением из почтового ящика. Сейчас устройств много, одно из них может высосать всю почту и удалить ее в почтовом ящике.
- Пользователь удаляет сообщения сам по какой-то причине и обманывает. Администратор не знает, в какие политические игры играют сотрудники, и частенько емейл фигурирует в них как аргумент или доказательство для наезда. В этом случае администратор показывает логи, и дальше уже пусть HelpDesk разбирается.
- Отработала Автоархивация и поместила сообщения в pst файл, а pst файл потерялся. Именно поэтому я ее запретил политиками лет десять назад, и теперь, если хочешь архивировать в pst — делай это вручную.
- Поломались индексы в базе и пользователь просто не видит «пропавших» сообщений, хотя они на месте..Необходимо просто починить индексы.
- Случайное перемещение сообщений в другую папку. Особенно смешно, когда структура папок разветвленная и пользователь Drag&dropом перетащил сообщения или папки куда-то и ищет потом.
- Политики архивирования. По умолчанию они за год оставляют сообщения, все остальное в архив. Поэтому нужно точно знать, как они работают.
- Внешние антивирусы на клиенте или антиспам. Зло еще то, возможна некорректная работа.
- Всевозможные плагины для Outlook. Были случаи, когда сообщения пропадали из-за некорректной работы плагинов.
- Первым делом необходимо определить, на чьей стороне произошла ошибка. Поэтому после сбора сведений о пропавшем письме я просматриваю журнал сообщений на предмет «а был ли мальчик».
- Сначала я ищу прием сообщения с определенного домена или адреса с помощью командлета get-messagetrackinglog. Встроенный поиск в EMC я использовал только на курсах по Exchange 2007. Причина проста — мне неудобно.
- Затем ищу все сообщения, отправленные получателю, т.к. бывает, что адрес отправителя, который мне сказали — неправильный или отправили совсем с другого адреса.
- Затем просматриваю SMTP log с помощью TextLogAnalyzer
- Адрес отправителя
- Адрес получателя
- IP адрес сервера отправителя
- На втором этапе уже становится понятно, на какой стороне искать.
- Если сообщения не было, то остается развести руками и сказать, чтобы почтовый администратор прислал логи, что наш сервер принял сообщения. Без этих доказательств не стоит даже начинать разговор.
- Если сообщение найдено, то можно определить причину, по которой оно было отбито.
- Если проблема на стороне клиента, а это определяется по событию STORE в get-messagetrackinglog, что сообщение было помещено в почтовый ящик. После этого проблема передается HelpDesk по поиску сообщения на клиенте. Места поиска описаны выше.
Удачи в поиске.
p.s. Данная статья написана в помощь HelpDesk в качестве инструкции по поиску пропавших сообщений. Вы можете использовать ее как угодно, замечания и предложения приветствуются. Если будете выкладывать на сайты, то не забудьте поставить ссылку на www.exchangeFAQ.ru, а если будете менять текст, то пришлите мне исправления, я, может, их вставлю в оригинальную статью для ее улучшения.