none
Переход со стороннего сервиса на Exchange RRS feed

  • Вопрос

  • Есть Exchange развернутый, все здорово. Нужно поменять сторонний сервис на Exchange.

    Вопрос скорее не к Exchange, а вообще в принципе о доступе к почте снаружи:

    Меняю MX-записи во внешнем DNS, на свой IP, провайдер делает PTR в обратной зоне на этот IP.

    Какие еще записи нужны? SPF, TXT и т.д.?

Ответы

  • С точки зрения "технической корректности" работы SMTP на отправку, не нужно вообще ничего. Всё остальное нужно для снижения вероятности отказа в приёме Ваших сообщений средствами борьбы со спамом.

    PTR - практически необходима (RFC), большинство "солидных" сервисов откажут в приёме при её отсутствии. Желательно совпадение домена прямой и обратной записей, а также совпадение с доменом, отправляемым в EHLO/HELO. Антиспам-проверки встречаются весьма изощрённые, вплоть до строгого совпадения домена из обратного адреса отправителя с доменом из PTR (что отсекает почту с мультидоменных систем, ну, значит таким настройщикам почта оттуда не нужна).

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

    Для корректного приёма, теоретически необходима только A-запись. Однако, удавалось встретить mta, которые при наличии только А-записи и отсутствии МХ, отказывались отправлять почту, заявляя о несуществующем домене. Основные назначения МХ-записей - отказоустойчивость и балансировка нагрузки. Дополнительные удобства - возможность ссылаться на МХ, например в той же SPF-записи. А ещё, доводилось встречать вариант проверки принадлежности IP отправителя к МХ домена адреса отправителя, и маркировке сообщения как надёжного, при совпадении :).

    То есть: A, PTR, MX, SPF (как Вы изначально и писали).

    Дополнительно, желательно проверить полученные от провайдера IP на попадание в популярные DNSBL. Наличие провайдерского пула в списках какого-нибудь uceprotect может быть неприятным.

    Есть ещё вариант озаботиться включением своих IP в какие-либо белые списки, но на сегодняшний день, реальная отдача от такой заботы исчезающе мала, по сравнению с уже перечисленным.


    S.A.

  • А запись нужна. А уж MX будет ссылаться на это имя. Для чего так делать? В случае изменения внешнего IP вам надо будет поменять только А запись.

    Do not multiply entities beyond what is necessary

  • Я бы SPF еще добавил для пущщей надежности. Работы на 3 мин...

    Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Предложить как ответ" или "Проголосовать за полезное сообщение"

Все ответы

  • Если вам нужен будет еще и внешний доступ, то гораздо больше необходимо менять. Посмотрите, например, здесь

    Do not multiply entities beyond what is necessary

  • Да, наверное, я неправильно поступил не сказав самого главного:

    Спереди в качестве Edge будет Mdaemon. То есть будем считать что это обычный почтовый сервер, без autodiscover и т.д.

  • Наверное в качестве SMTP Relay? Edge это роль Exchange Server все-таки.

    Do not multiply entities beyond what is necessary

  • "... обычный почтовый сервер" на периметре, как правило, это "отправка/получение", mta (mail transfer agent). Ему и не нужны "autodiscover и т.д.", вне зависимости от того, Exchange это, или что угодно ещё.

    И всё, что было для старого сервиса, нужно повторить (перенастроить) для нового сервиса.

    А вот пользовательский доступ к п/я, это несколько другое. И если он Вам снаружи нужен, будут "autodiscover и т.д." :).


    S.A.

  • Да Relay.

    Ладно, давайте обстрагируемся от Exchange.

    Есть почтовый сервер, какие внешние DNS-записи нужны кроме MX и PTR для корректной работы сервиса?

  • А запись нужна. А уж MX будет ссылаться на это имя. Для чего так делать? В случае изменения внешнего IP вам надо будет поменять только А запись.

    Do not multiply entities beyond what is necessary

  • Я бы SPF еще добавил для пущщей надежности. Работы на 3 мин...

    Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку "Предложить как ответ" или "Проголосовать за полезное сообщение"

  • Все? Больше ничего не забыли?

    Просто spf например у стороннего сервера не сделан, а сделать хочется по правильному.

    А сделаю. Спасибо.

  • С точки зрения "технической корректности" работы SMTP на отправку, не нужно вообще ничего. Всё остальное нужно для снижения вероятности отказа в приёме Ваших сообщений средствами борьбы со спамом.

    PTR - практически необходима (RFC), большинство "солидных" сервисов откажут в приёме при её отсутствии. Желательно совпадение домена прямой и обратной записей, а также совпадение с доменом, отправляемым в EHLO/HELO. Антиспам-проверки встречаются весьма изощрённые, вплоть до строгого совпадения домена из обратного адреса отправителя с доменом из PTR (что отсекает почту с мультидоменных систем, ну, значит таким настройщикам почта оттуда не нужна).

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

    Для корректного приёма, теоретически необходима только A-запись. Однако, удавалось встретить mta, которые при наличии только А-записи и отсутствии МХ, отказывались отправлять почту, заявляя о несуществующем домене. Основные назначения МХ-записей - отказоустойчивость и балансировка нагрузки. Дополнительные удобства - возможность ссылаться на МХ, например в той же SPF-записи. А ещё, доводилось встречать вариант проверки принадлежности IP отправителя к МХ домена адреса отправителя, и маркировке сообщения как надёжного, при совпадении :).

    То есть: A, PTR, MX, SPF (как Вы изначально и писали).

    Дополнительно, желательно проверить полученные от провайдера IP на попадание в популярные DNSBL. Наличие провайдерского пула в списках какого-нибудь uceprotect может быть неприятным.

    Есть ещё вариант озаботиться включением своих IP в какие-либо белые списки, но на сегодняшний день, реальная отдача от такой заботы исчезающе мала, по сравнению с уже перечисленным.


    S.A.

  • Спасибо за помощь :)
    7 июля 2015 г. 10:15