Пользователь
0,0
рейтинг
12 мая 2009 в 21:33

Почтовая кухня #1: DNS

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



Для простоты и сокращения количества букв мы рассмотрим простейшую (и наиболее распространенную) ситуацию:

1 доменное имя (example.com).
1 почтовый домен (* example.com).
1 почтовый сервер (mail.example.com).
1 IP-адрес (127.127.127.127).

Касательно почты, в DNS нас интересует четыре типа записей.

  • A
  • MX
  • PTR
  • TXT


Второй — обязательный, без него почта в 99% случаев не будет ходить вообще. Без остальных, в принципе, можно обойтись, но шансы, что ваше письмо будет отвергнуто как спам возрастают в разы — тот же mail.ru отбрасывает практически всю почту, чьи IP-адреса не имеют PTR, либо PTR относится к dial-up провайдерам. И это правильно.

A-запись



A (Address) — запись, указывающая IP-адрес нужного нам доменного имени. Для корректной работы почты требуется A-запись сервера почты (mail.example.com). Выглядеть, в нашем случае, она будет так:

mail IN A 127.127.127.127

Где:
mail — домен.
IN A — тип записи.
127.127.127.127 — IP нашего почтового сервера.

MX-записи.



MX (Mail eXchange) — основная DNS-запись для электопочты. Она указывает, какими серверами обрабатывается почта для нашего домена.

У нас есть один почтовый домен — example.com. И один почтовый сервер — mail.example.com. Соответственно, запись будет выглядеть так:

example.com. IN MX 10 mail.example.com


Где:
example.com — домен, для которого обробатывается почта.
IN MX — тип записи.
10 — приоритет записи (Подробнее — ниже).
mail.example.com — A-имя почтового сервера.

MX-запись должна указывать именно на A-запись почтового сервера. Ставить MX указателем на IP или CNAME — не правильно.

Приоритет MX-записи нужен тогда, когда существует больше одного почтового сервера для одного домена (например у Google Mail их шесть). Он указывает, к какому серверу идет обращение в первую очередь, во вторую и так далее (если первый (второй, десятый) сервер недоступен или перегружен или по другим причинам не может принять письмо). Логика простая — приоритетнее тот, цифра которого меньше. Порядок цифр — не ограничен, хоть 10-20-30, хоть 1000-2000-3000.

Если у домена нет ни одной MX-записи, либо ни один из MX-серверов не доступен, сервер отправителя попытается доставить почту на IP, указанный в A-записи домена. Это назвается А-доставкой, но в принципе не кошерно и не используется многими серверами — нужно указывать MX, даже если он всего один.

PTR-запись.



PTR (PoinTeR) — так называемая «обратная запись». Она позволяет обратное разрешение (reverse resolving) IP-адреса в FQDN-хост.

Наш IP в виде reverse будет выглядеть так: 127.127.127.127.in-addr.arpa. В данном примере видно плохо, но адрес инвертируется в обратной зоне. Т.е. IP 192.168.0.1 будет выглядеть как 1.0.168.192.in-addr.arpa.

Для корректного распознования хоста, запись IP-адреса, с которого отправляется должна соответсовать hostname почтового сервера, отправляемому в HELO\EHLO.

PTR-запись в нашем случае, соответственно:

127.127.127.127.in-addr.arpa IN PTR mail.example.com.

Прописать эту запись может владелец блока IP-адресов (Читайте мою статью про распределение адресного пространства). Если вы таковым не являетесь и получили адреса от провайдера — обращайтесь к вашему провайдеру или дата-центру, чтобы запись установил он.

TXT-запись и SPF.



TXT (TeXT) — текстовая запись DNS. Нам она интересна только тем, что может (и в современном мире — должна) содержать в себе SPF.

SPF (Sender Policy Framework) — запись, позволяющая вам указать, какие сервера имеют право отправлять почту от имени вашего домена (представившись вашим сервером, либо с обратным адресом в вашем домене).

Если этой записи нет, и кто-то пытается отправить письмо (как правило, спам) с обратным адресом в вашем домене — оно будет отклонено большинством серверов. Или не будет, и вы получите большие проблемы со своим дата-центром или провайдером и репутацию спамера :)

SPF-запись выглядит так:

v=spf1 ip4:1.1.1.1 +a +mx -all (пример).

Где:

v=spf1 — версия протокола.
(+\-)a — разрешение или запрет отправки почты с IP, соответствующего A-записи домена.
(+\-)mx — разрешение или запрет отправки почты с IP, соответствующего MX-записи домена.
ip4:IP — явное указание IP, с которого можно принимать почту от имени домена.
(~\-all) — отвергать или принимать почту от IP, не перечисленных в списке и не указанных явно.

В нашем случае TXT SPF запись будет такой:

example.com. IN TXT "v=spf1 +mx +a -all"

Таким образом, мы разрешили прием почты от имени домена с IP, соотвествующих A или MX записям и запретили прием от других адресов — никто не сможет наспамить прикинувшись нами или обмануть наших пользователей, отправив фишинговую ссылку от имени тех. поддержки.

Буду рад комментариям, готов ответить на вопросы.
В следующих статьях я напишу об SMTP, Greylisting-е и RBL.
А еще вы можете вступить в блог и тоже о чем-то рассказать.
Никита @differentlocal
карма
55,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (75)

  • +3
    Спасибо.
    Про некоторые DNS записи не знал — просветили. Пиши еще!
  • 0
    про SMTP я писал раньше… seriyps.habrahabr.ru/blog/51772/
    Так что надо как-то это скоординировать))
    • 0
      Переносите в блог, а я тогда не буду уже про SMTP писать ;)
  • +2
    Интересно. Такие подробности хорошо было бы узнать не только о почте.
  • 0
    Недавно тут натыкался на очередную фишку — первый MX сервер должен быть фейковый(например все время возвращать ошибку), ибо спамботы не факт что пойдут долбится по всем серверам, а нормальные почтовые сервера спокойно доставят почту по другому MX.
    • 0
      Не факт, что всегда так будет. Некоторые спам-боты специально начинают долбиться на МХ с меньшим приоритетом.
      • 0
        Тогда два ложных сервера, с наименьшим и с наибольшим приоритетами.
        • 0
          Ну, это уже изврат :)
          • 0
            Если это поможет хоть как-то от спама, то почему бы и нет?
            • +1
              НУ а ресурсы? Если только на одной машине организовывать, но как делить и т.д.?
              Я тут никак не разорюсь на бэкапный MX для своих проектов, сервер есть, но лень пока что перебороть не могу :)
              • 0
                В общем, когда я соберусь это реализовать у себя, то напишу статью как это сделать на основе Postfix'а.
              • +4
                Кстати, вот если гуглануть то можно найти уже готовый сервис
                www.fakemx.org/
                который предоставляет фейковый МХ что возвращает 451 Try again later.
                Всё оказалось еще проще :)
    • 0
      Фейковый mx — это способ снизить нагрузку на сервера для бедных, если нет ресурсов обрабатывать все входящие соединения от многочисленных спамботов и рассказывать им что они в блэклисте. А количество спама это IMHO уменьшает только если не используется никаких других мер защиты от спама. Более того при исправно работающем приоритетном MX-е на запасной ходят преимущественно спамботы (но иногда туда почему то идут и хорошие сервера, типа mail.ru). А письма от нормальных почтовых серверов будут доставляться с задержкой, как и при использовании грейлистинга (который защищает от спама эффективнее fake mx).
      • 0
        Сервера для бедных? А сервера для «богатых» это как? Не надо тут народ делить.
        Если вам нужно всё быстро надежно и практически без спама — пользуйтесь коммерческими продуктами например — Спамообороной от Яндекса или Спамтестом от Касперского — решение для богатых, ага.

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

        • +1
          для богатых это поставить нужно число серверов, которые в состоянии обработать все входящие соединения, а затем отсеивать спамеров по признакам более надежным, чем отправка на первичный MX — начиная от RBL и проверки helo, заканчивая фильтрацией по содержимому письма.

          если использовать адекватные RBL и правила для проверки helo то это отсеет примерно то же количество спамботов, что и fake mx, но без негативного эффекта в виде задержки при приеме почты с хороших серверов.
          • 0
            RBL грозит не меньшими задержками\потерей почты. Случаи, когда из-за одного мудака в blacklist уезжал весь хостер\ISP — совсем не редкость (особенно в интерпретации спамхауса, банящего подсетями).
            • +3
              Я не зря выше написал «адекватные RBL». Если вы берете первый попавшийся RBL не узнав о нем ничего, то ложным срабатываниям удивляться не стоит.

              У того же спамхауса есть несколько разных RBL с разным уровнем ложных срабатываний:

              SBL — сюда заносятся сети используемые спамеров, или сети провайдеров, помогающим спамеров. Например в SBL попадали сети РТКомм и Ди-Нет (msm.ru), когда они размещали в своих сетях сервера спамеров и отказывались прекращать их хостинг. Этот RBL использовать в общем случае не стоит, потому что когда банится целая сетка, велика вероятность что пострадают невиновные клиенты этих ISP.

              PBL — сюда тоже попадают целые сетки, но не предназначенные для размещения почтовые серверов — пулы динамических клиентских IP адресов. Несмотря на то, что заносятся целые сетки ложных срабатываний относительно мало. Например вероятность того, что вам нужно будет принять письмо из сетки 59.50.0.0/15 (адреса *.dynamic.163data.com.cn) крайне низка а спама оттуда идет много. Так что PBL вполне можно использовать, возможно не как единственный критерий, а в комплексе с чем то еще.

              XBL — в него попадают отдельные IP затрояненных машин. Ложных срабатываний очень мало. Проблемы с использованием XBL я встречал только такого вида — на сервере один и тот же IP используется для почтового сервера и для NAT-а затрояненных виндовых рабочих станций. Т. е. с одной стороны оттуда сыплется спам, с другой стороны с почтового сервера на этом же IP может прийти нужное письмо. Но бывает это редко и в целом я рекомендую XBL для использования.

              ZEN — включает в себя XBL, PBL, SBL — не рекомендую использовать по той причине что содержит SBL.
  • +1
    У меня вопрос, толком нигде не читал про это, но в чем различие между -all и ~all?
    • 0
      ~all — они это называют «soft policy», мягкая политика. Т.е. адрес отправителя может быть не из доверенных, и письмо пройдет, хотя и рекомендовано его пометить «подозрительным» и отправить на доп. проверки (например — по RBL) или загрейлистить. А -all — это жестко reject всего, что не из списка.
      • 0
        Пойду поставлю у себя «минусик» :) Я почему-то читал рекомендации с "~"… а по логу постфикса фижу много софт-фейлов, но не совсем понятно, что там и как, вроде как они не проходят через грейлист.
        • 0
          Да, тоже читал.

          Вопрос в том, чего мы хотим. С ~all больше шансов, что почта дойдет до цели, например если сменится IP сервера или лягут DNS. А с -all больше шансов, что никто не сможет наспамить от нашего имени. :)

          От задач зависит. Я обычно ставлю "-all".
  • 0
    А если у меня указано так:
    TXT «v=spf1 a mx -all»
    но и у A записей и у MX записей может резолвиться много IP адресов — по идее же так можно?
    • 0
      По идее — да.

      Но надежнее, имхо, прописать ip4:subnet/shortmask, как например у мыла.ру сделано.
      • +1
        Просто у меня адреса не в одной подсети, а прописывать каждый айпишник отдельно — длинно будет.
        А ограничение на длину TXT записи есть? И еще назрел вопрос:
        вот у гугла так рекомендуют подключать gmail на свой домен:
        TXT «v=spf1 include:aspmx.googlemail.com ~all»
        но в манах разных версий про «include» как-то не пишут… — это типа, что и ip4, только для имени хоста? Просто не понятно, что в моей ситуации лучше указать…
        • +1
          Это инклюд SPF с aspmx.googlemail.com. А там, в свою очередь, идет redirect на _spf.google.com. А вот уже там — километровая SPF с подсетями гугла:

          «v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all»
          • 0
            Ага, вот оно что. Спасибо :) Тоже надо по аналогии сделать :)
    • 0
      По идее — да.

      Но надежнее, имхо, прописать ip4:subnet/shortmask, как например у мыла.ру сделано.
      • 0
        у мыла.ру в spf указано ip4:subnet/shortmask потому что входящие сервера (указанные в mx-записи) и исходящие (указанные в spf) имеют разные IP адреса. Для домена, где все живет на одном сервере можно указать mx
        • 0
          В условии alexxxst-а как минимум не один сервер. :)
  • 0
    Спасибо, оч познавательно.
  • 0
    • +1
      Мне кажется, системные администраторы это итак знают. Во всяком случае — должны :)
      • 0
        тогда какую целевую аудиторию Вы учитывали, публикуя данный материал и рассчитывая писать цикл статей?
        • +1
          Пользователи сети, которым интересно разобарться, как она работает. :)
  • +2
    Стоит добавить заметку, как напрочь выключить почту на домене в DNS. Где-то проскакивало, что нужно в MX прописать поддомен «not-mail.»
    • 0
      Хм, не сталкивался. А по-подробнее можно?
      • 0
        Вот я не хочу на домен принимать почту. Удаляю MX вообще. Спам всё-равно сыпится на A-записи. Куда курить?
        • 0
          Отключить на почтовом сервере, по IP А-записи прием почты для нужного домена. А как еще? И главное — зачем?
          • 0
            На хостинг направлены тысячи доменов, почта для них не нужна. Для остальных нужна. Как разделять их?
            • 0
              Правильно настроенный почтовый сервер не примет почту для доменов, не перечисленных ему как обслуживаемые им.
              • 0
                Правильно настроенный сервер принимает все соединения и шлет отлупы на каждый запрос принять почту. По нашим логам на один домен в день идет 5-9 соединений на стандартные ящики — с надежной что почта пройдет. Домены тысячи, трафика мегабайты.
                • 0
                  Перенастройте так, чтобы при попытке доставки на несуществующий домен сбрасывалось соединение. Это, имхо, простейщий путь.
                  • 0
                    Это не выход. Самый простейший путь — не доводить до соединения вообще.
                    • 0
                      Если ваш сервер принимает все для всех доменов — очень легко начать долбить его ботом и нагнать вам трафика. Зачем создавать себе проблемы?
                      • 0
                        Это не релей, не путайте. Я выше писал, что соединения на 25 порту принимаются все, а дальше в процессе диалога решается — что и куда. Так вот тысячи спамных соединений на домены, на которые почта не нужна вовсе (удалены mx), всё-равно долбятся на сервер и хотят отправить почту. В процессе общения они, естественно, получают отказ, но им же не скажешь «перестаньте присылать спам».
        • 0
          указать в MX несуществующий сервер, например fuckyouspammers.local
  • 0
    SPF ещё не так сильно как хотелось бы распространена.
    • 0
      К сожалению, да. Хотя популярные бесплатные почтовики ее уже используют — уже легче.
    • 0
      У spf есть как минимум одна серьезная проблема — редиректы писем. Например:
      есть домен @foo.ru у которого в spf записи написано что письма из этого домена могут отправляться только с IP 10.10.10.10
      пользователь sender@foo.ru отправляет письмо но some@mail.ru
      с ящика some@mail.ru стоит редирект на some@firma.ru
      почтовый сервер firma.ru видит письмо из домена @foo.ru но не с адреса 10.10.10.10 и не принимает такое письмо.
      отправитель получает баунс.

      Так что -all в SPF использовать нежелательно.
  • 0
    Стоит добавить что MX запись должна указывать именно на A-запись.
    Писать в mx записи непосредственно IP или CNAME неправильно.

    Например так делать нельзя:
    example.com. IN MX 10 192.168.1.1

    и так тоже не надо:
    example.com. IN MX 10 mail
    mail IN CNAME superserver
    • 0
      Добавил, спасибо. :)

      Интересно, а те, кто минусят не хотят прокомментировать?
      • 0
        Минусят конкретно этот коммент? Я не минусил, но, подозреваю, потому, что citrin просто бредит.

        В MX _можно_ указывать как просто ip, так и CNAME.
        • 0
          сорри, попутал, citrin прав.

          стоит только добавить, что можно не только A, но и AAAA.
    • 0
      > Стоит добавить что MX запись должна указывать именно на A-запись.
      > Писать в mx записи непосредственно IP или CNAME неправильно.

      Это с чего вдруг?
      • 0
        сорри, попутал, citrin, ты прав.
      • 0
        RFC 2181

        10.3. MX and NS records

        The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.
      • 0
        RFC 1912

        2.4 CNAME records

        Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged:

        podunk.xx. IN MX mailhost
        mailhost IN CNAME mary
        mary IN A 1.2.3.4

        [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME.
  • +1
    Я тут еще вот так извращался: я.блоги
    • 0
      ** От спамеров
  • 0
    Я бы с интересом почитал о правильной организации легальной рассылки — как контролировать доставку и обрабатывать отказы сервера принимать почту и т.п., какие подводные камни могут быть у политики 'отправил и забыл', какие проблемы можно получить с абузом, если что-то не так настроил или куда-то неправильно отослал, и т.п.
  • 0
    > A
    > MX
    > PTR
    > TXT
    > Второй — обязательный, без него почта в 99% случаев не будет ходить вообще.

    Наоборот, в 99.9% случаев будет ходить на А.

    • 0
      Я как бы о том, что очень часто почтовый и web серверы разнесены по адресам\машинам.
      • 0
        Ну так и надо так написать.

        Написав «без MX-записи почта в 99% случаев не будет ходить вообще», вы просто ошибаетесь сами и вводите в заблуждение других.
  • +1
    По-английски «Address» пишется с двумя «d».
    • 0
      Спасибо, опечатался.
  • 0
    только в пятницу перекопал весь инет в поисках подобной инфы — и вот вам пожалуста — она сама к тебе сваливается, когда уже итак всё знаешь…
  • +2
    Официальный сайт SPF — www.openspf.org/
    Сайт сервисов для проверки записей MX — www.mxtoolbox.com/
    а также — dnsstuff.fastnext.ru/index.php
    Более подробно «разжевано» про записи PTR — info.nic.ru/st/8/out_264.shtml

    При настройке DNS для почтового сервера рекомендуется соблюдать следующие правила:

    1. Сервер исходящей почты должен представляться в команде HELO/EHLO своим внешним FQDN (т.е., например, не mail.firma.local, а mail.firma.ru)
    2. FQDN сервера исходящей почты должно однозначно разрешаться записью A во внешний IP-адрес сервера исходящей почты.
    3. Внешний IP-адрес сервера исходящей почты должен однозначно разрешаться записью PTR во внешний FQDN сервера исходящей почты (т.е. A, PTR и HELO/EHLO должны однозначно соответствовать друг другу).
    4. Сервер исходящей почты должен быть указан в записях SPF всех доменов, для которых он является авторизованным для отправки или пересылки почты.
    5. Запись MX должна существовать и указывать на FQDN сервера входящей почты.
    Отсюда — forum.ixbt.com/topic.cgi?id=7:26978:20#0

    Вот собственно чуть чуть полезной информации, то что мне помогло на начальной поре настроить почтовый сервер…
  • +3
    Почту править спешит Айболит
    И три слова он громко кричит:
    DNS, PTR, SPF!
  • 0
    Да! Отличное начало. Про реверс только надо так, чтобы в глаза било, а то у вас к сожалению не описано, что будет, если реверс не будет прописан. То есть что почту никто не примет без реверса, и с реверсом вида ppp-12-23-34-45.provider.net то же. Последнее конечно не обязательное требование, но я фильтрую — много срезает трафика от спамбот-сетей.
  • 0
    Еще не забывайте что бывает SPF запись на EHLO имя.
    dig mail.example.com txt
    mail.example.com. 86400 IN TXT «v=spf1 a -all»
    чтобы под вашим EHLO в чужие домены не представлялись.
  • 0
    Критика:

    «Второй [MX] — обязательный, без него почта в 99% случаев не будет ходить вообще.»

    Это почему? Если нет записи MX, а есть запись A, то по RFC нужно долбиться на A, и нормальные сервера все держат такую функциональность.

    «Для корректной работы почты требуется A-запись сервера почты (mail.example.com).»

    Это почему? Записи MX достаточно: если она есть, то запись A не нужна.
    • 0
      1) Уже отвечал выше где-то.

      Суть в том, что довольно часто IP A web-домена != IP почтовика.

      2) Я видел неадекватную реакцию почтовиков на IP в MX. Чем это вызвано — не разбирался, если честно. Выше об этом тоже писали.
  • 0
    Статью можно обновить, DKIM добавить.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.