Как-то так сложилось, что мы с самой даты запуска электронной почты в корпоративном домене работали исключительно со своими партнерами, но никогда не содержали собственных серверов обмена корреспонденцией. Собственные сервера — это, все-таки, весьма сложная штука, которая требует более детального изучения и надзора, поскольку такие сервера частенько взламываются, атакуются, да и просто попадают в черные списки, после чего почта с них перестает попадать получателям во «Входящие». Мы никогда не хотели иметь собственных почтовых серверов, да и ныне не планируем. Тем не менее, нам пришлось прекратить работу с почтовыми сервисами нашего хостинг-партнера — ukraine.com.ua. Причин этому было немало, основные я постараюсь описать в следующем абзаце.

Для начала, нас уже давно раздражала доступность веб-клиента электронной почты по принципу «через раз». Нет, чаще всего, конечно, сервера были доступны, но перебои я бы не рискнул назвать редкими. По статистике серверов хостинга, конечно же, этого не видно: по сводкам поставщиков сервера работают без перебоев даже в те дни, когда на форуме появляется десяток сообщений о недоступности. Последней каплей стал DDoS почтовой инфраструктуры на прошлой неделе: во время переписки с крупным клиентом мы просто потеряли доступ к электронной почте. Потом доступ возобновился, но страницы почтового клиента грузились по пять минут. Прямо во время этих перебоев мы и приняли решение о приостановлении сотрудничества. Но это, конечно же, не единственная причина нашей миграции. Я никогда не мог понять логики подсчета отправленных сервером писем: когда скрипт отправлял по SMTP письмо и его копию отдельным сеансом, в статистике почему-то было видно только одно отправленное письмо. Каждый раз после рассылок я сталкивался с мыслью о том, что не уверен в отправке писем всем адресатам. Немаловажной для нас была также и защита от спама. Между уровнями защиты «отсутствует» и «максимальная», честно говоря, я так и не увидел разницы. На обоих уровнях спам исправно приходил прямо во «входящие», создавая дополнительную ручную работу по их перемещению. После последнего обновления почтовых сервисов спам продолжил приходить во «входящие», а вот нормальные письма от деловых партнеров мы стали находить среди явного мусора. Все просьбы учитывать перемещаемые в «спам» письма при фильтрации отправлялись администраторами в /dev/null, после чего особенно ядовитые сотрудники (которых на сегодняшний день нанимать стало трендом) советовали использовать программные клиенты с ручной настройкой фильтров. Мы почти так и поступили.

Перенести корпоративную почту на Mail.Ru, как выяснилось, совершенно не сложно. После подтверждения права на владение доменным именем нужно только прописать в доменной зоне MX-сервера почтовой службы, после чего, следуя рекомендациям мастера переноса, добавить SPF-политику и DKIM-подпись. Последние два пункта не обязательны и влияют только на исходящую почту, существенно повышая вероятность доставки ее именно туда, куда она была отправлена. Наша электронная почта заработала уже через час после переноса. Но это еще не все. После того, как мы создали такие же ящики, как у нас были прежде, встал вопрос: как перенести уже принятую корреспонденцию, ведь она тоже нужна для работы. Оказалось, очень просто: нужно просто дать Mail.Ru логин и пароль от старого почтового ящика, откуда все письма будут мгновенно скопированы на новый. Немаловажно, что копируется и содержимое папки «спам», что в нашем случае спасло несколько десятков неправильно отфильтрованных предыдущим сервисом писем.

Каждый из созданных аккаунтов (почтовых ящиков сотрудников, а не доменных аккаунтов в целом) является, по сути дела, обыкновенным пользователем Mail.Ru со всеми вытекающими. То есть, каждому сотруднику дается облачное хранилище на 25Гб, календарь, безлимитный почтовый ящик, мессенджер и т.д. Облако, конечно, — это круто (говорю как старый пользователь, зарегистрировавшийся в первый день после открытия). Администратору при регистрации домена дается возможность объединить мессенджеры и адресную книгу для все сотрудников, или же сделать их полностью автономными. Также предлагается дать пользователю возможность менять и восстанавливать пароль. Для защиты от взлома, конечно же, я бы рекомендовал восстановление пароля запретить и оставить за ответственным сотрудником. У предыдущего провайдера была возможность видеть несколько ящиков одновременно и не открывая знать, есть ли там новая почта. Что же на Mail.Ru? Если у вас более одного корпоративного почтового ящика за одним человеком, то он модет войти одновременно в два и больше, а затем переключаться через меню, которое будет указывать на наличие новых писем. По-моему, круто. Еще круче то, что разнообразные служебные ящики типа admin, hostmaster и postmaster можно создать и настроить сбор почты с них на какой-нибудь основной служебный. Ах, да! Еще и SMS-уведомления можно настроить о приходе новых писем. Что еще нужно для счастья?

Ну конечно же отправка почты с сайта по SMTP! Тем более, что на фирменном бланке у нас только так и можно создать электронное письма. У Mail.Ru с этим никаких проблем, но перед тем, как подключаться к почтовому ящику скриптами нужно войти в него через веб-интерфейс и ввести имя с фамилией. Без этого сервер отказывает в отправке. Там же можно задать аватар для электронного адреса, который будут видеть в своих постовых ящиках пользователи Mail.Ru. Также Mail.Ru в настоящий момент не поддерживает отправку писем по SMTP по незащищенному подключению, что от нас потребовало немного модернизировать свой почтовик, но это было не так и трудно: просто добавить перед названием SMTP-сервера «ssl://» да указать корректный порт из справки Mail.Ru.

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