вторник, июля 20, 2010

Что делать если сервер получателя не хочет принимать почту от вашего сервера?

Как-то давным давно я рассказывал о том, что иногда возникает ситуация, когда ваш почтовый сервер не может доставить сообщение по каким-либо причинам. При расследовании выясняется, что сервер не хочет принимать почту именно от вашего сервера. Что же делать? Ведь письмо должно быть доставлено, да и получатель по телефону утверждает, что его сервер работает и он получают сообщения с других серверов.

  

Ситуация и правда неприятная. Возникает она по следующим причинам:

               1. на сервере получателя настроена слишком жесткая политика безопасности. Например проверяется наличие MX или  делается проверка работоспособности вашего сервера Callback, а записей в их DNS о вашем сервере нет

               2. проблема с конфигурацией DNS у вашего провайдера

               3. проблема с конфигурацией сети вашего провайдера, сети  с сервером получателя просто нет

Из перечисленного списка явно видно, что проблемы у провайдера или на сервере получателя. Можно написать им письма, позвонить. Пока они подключат инженеров, пока разберутся пройдет время. А письмо нужно отправить срочно. Что делать? Все просто, вам нужен релей — почтовый сервер у другого провайдера, который открыт только для вашего сервера. Назревает вопрос, а где его взять? Все просто, есть несколько способов:

               1. в больших и распределенных по городам компаниях всегда можно отправить почту в определенный домен или на определенный сервер через ваш почтовый сервер в другом городе

               2. купить дешевый VDS на Linux у какого-нибудь провайдера и запускать почту через него для проблемных доменов. Я пользуюсь хостингом TinyVDS, цена вопроса 9$ в месяц.  Учитывая то, что на сервере можно хранить ваш вебсайт, файлы, проводить независимые тесты с командной строки. 

               3. договориться с кем-нибудь из знакомых админов и разрешить релеи для ваших серверов для отправки почты в проблемные домены.

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

Здесь можно оставить свои комментарии. Выпуск подготовленплагином wordpress для subscribe.ru

среда, июля 14, 2010

Практическое использование транспортных правил в Microsoft Exchange Server 2007/2010

Транспортные правила в Exchange Server 2007Появление транспортных правил в Microsoft Exchange Server 2007 внесло существенное облегчение в жизнь почтовых администраторов. Задачи по централизованной обработке почты, реализация спецефических сценариев стала намного проще. Я конечно же использую транспортные правила в Exchange Server, но возможно я знаю не все сценарии их применения. Поэтому я спросил в нашей Exchange группе о сценариях использования транспортных правил и вот какой веселенький список у нас получился.

 

 

  1. Создание копий всех входящие и исходящие сообщения с определенного домена/адреса в специальный ящик:
    1. Начальник хочет просматривать получаемую или отправляемую корреспонденцию
    2. Ведение архива переписки опреленного отдела в компании
  2. Запрет прима сообщений от определенных доменов/адресов
    1. Удаление сообщений от сервисов, запрещенных в компании – одноклассников, в контакте или ненужных рассылок
    2. Блокировка спама от компаний, у которых email постоянный, но IP адреса серверов меняются
  3. Удаление сообщений извне, содержащих нецензурные выражения
    1. Очень часто приходят сообщения, содержащие от 3 до 5 нецензурных слов и ссылку
  4. Установка SCL для сообщений
    1. Например, KAS на postfix или ORF метия спам в заголовке и если транспортное правило поставит SCL -7, то сообщение попадет в Junk email в Outlook
    2. Есть белые сервисы, которые отправляют нужные сообщения и Outlook их постоянно помещает в Junk, чтобы этого не было, нужно SCL присвоить значение "-1"
  5. Копирование исходящих сообщений в общий ящик, когда нжуно чтобы отправляемое от имени общего ящика, копировалось в папку отправленные общего ящика. Это часть решения по реализации общего ящика.
  6. Установка кастомных хедеров для дальнейшей обработке клиентскими правилами в Outlook

 

Наверняка существуют и другие сценарии использования, расскажите о них в комментариях.

p.s. у транспортных правил есть один очень серьезный минус, который расстраивает меня очень сильно — убогость регулярных выражений. К сожалению они очень простые и приходится создавать множество записей, вместо одной :-(

Здесь можно оставить свои комментарии. Выпуск подготовленплагином wordpress для subscribe.ru