Comments 76
Спасибо.
Про некоторые DNS записи не знал — просветили. Пиши еще!
Про некоторые DNS записи не знал — просветили. Пиши еще!
про SMTP я писал раньше… seriyps.habrahabr.ru/blog/51772/
Так что надо как-то это скоординировать))
Так что надо как-то это скоординировать))
Переносите в блог, а я тогда не буду уже про SMTP писать ;)
Сделано. habrahabr.ru/blogs/email/51772/
Заголовок оформил в вашем стиле
Заголовок оформил в вашем стиле
Интересно. Такие подробности хорошо было бы узнать не только о почте.
Недавно тут натыкался на очередную фишку — первый MX сервер должен быть фейковый(например все время возвращать ошибку), ибо спамботы не факт что пойдут долбится по всем серверам, а нормальные почтовые сервера спокойно доставят почту по другому MX.
Не факт, что всегда так будет. Некоторые спам-боты специально начинают долбиться на МХ с меньшим приоритетом.
Тогда два ложных сервера, с наименьшим и с наибольшим приоритетами.
Ну, это уже изврат :)
Если это поможет хоть как-то от спама, то почему бы и нет?
НУ а ресурсы? Если только на одной машине организовывать, но как делить и т.д.?
Я тут никак не разорюсь на бэкапный MX для своих проектов, сервер есть, но лень пока что перебороть не могу :)
Я тут никак не разорюсь на бэкапный MX для своих проектов, сервер есть, но лень пока что перебороть не могу :)
В общем, когда я соберусь это реализовать у себя, то напишу статью как это сделать на основе Postfix'а.
Кстати, вот если гуглануть то можно найти уже готовый сервис
www.fakemx.org/
который предоставляет фейковый МХ что возвращает 451 Try again later.
Всё оказалось еще проще :)
www.fakemx.org/
который предоставляет фейковый МХ что возвращает 451 Try again later.
Всё оказалось еще проще :)
Фейковый mx — это способ снизить нагрузку на сервера для бедных, если нет ресурсов обрабатывать все входящие соединения от многочисленных спамботов и рассказывать им что они в блэклисте. А количество спама это IMHO уменьшает только если не используется никаких других мер защиты от спама. Более того при исправно работающем приоритетном MX-е на запасной ходят преимущественно спамботы (но иногда туда почему то идут и хорошие сервера, типа mail.ru). А письма от нормальных почтовых серверов будут доставляться с задержкой, как и при использовании грейлистинга (который защищает от спама эффективнее fake mx).
Сервера для бедных? А сервера для «богатых» это как? Не надо тут народ делить.
Если вам нужно всё быстро надежно и практически без спама — пользуйтесь коммерческими продуктами например — Спамообороной от Яндекса или Спамтестом от Касперского — решение для богатых, ага.
Мне например ненужно чтобы мой почтовый сервер долбили лишние боты, и каждому явно говорить что он бот — не очень хочется, если за меня это может сделать сторонний сервис который для этого предназначен. Тем более я рассматриваю эту технологию защиты не как единственно возможную и оправданную, а как одну из, потенциально в совокупности с остальными методами снижающую нагрузку на сервер и количество пропускаемого спама.
Если вам нужно всё быстро надежно и практически без спама — пользуйтесь коммерческими продуктами например — Спамообороной от Яндекса или Спамтестом от Касперского — решение для богатых, ага.
Мне например ненужно чтобы мой почтовый сервер долбили лишние боты, и каждому явно говорить что он бот — не очень хочется, если за меня это может сделать сторонний сервис который для этого предназначен. Тем более я рассматриваю эту технологию защиты не как единственно возможную и оправданную, а как одну из, потенциально в совокупности с остальными методами снижающую нагрузку на сервер и количество пропускаемого спама.
для богатых это поставить нужно число серверов, которые в состоянии обработать все входящие соединения, а затем отсеивать спамеров по признакам более надежным, чем отправка на первичный MX — начиная от RBL и проверки helo, заканчивая фильтрацией по содержимому письма.
если использовать адекватные RBL и правила для проверки helo то это отсеет примерно то же количество спамботов, что и fake mx, но без негативного эффекта в виде задержки при приеме почты с хороших серверов.
если использовать адекватные RBL и правила для проверки helo то это отсеет примерно то же количество спамботов, что и fake mx, но без негативного эффекта в виде задержки при приеме почты с хороших серверов.
RBL грозит не меньшими задержками\потерей почты. Случаи, когда из-за одного мудака в blacklist уезжал весь хостер\ISP — совсем не редкость (особенно в интерпретации спамхауса, банящего подсетями).
Я не зря выше написал «адекватные 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.
У того же спамхауса есть несколько разных 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.
У меня вопрос, толком нигде не читал про это, но в чем различие между -all и ~all?
~all — они это называют «soft policy», мягкая политика. Т.е. адрес отправителя может быть не из доверенных, и письмо пройдет, хотя и рекомендовано его пометить «подозрительным» и отправить на доп. проверки (например — по RBL) или загрейлистить. А -all — это жестко reject всего, что не из списка.
А если у меня указано так:
TXT «v=spf1 a mx -all»
но и у A записей и у MX записей может резолвиться много IP адресов — по идее же так можно?
TXT «v=spf1 a mx -all»
но и у A записей и у MX записей может резолвиться много IP адресов — по идее же так можно?
По идее — да.
Но надежнее, имхо, прописать ip4:subnet/shortmask, как например у мыла.ру сделано.
Но надежнее, имхо, прописать ip4:subnet/shortmask, как например у мыла.ру сделано.
Просто у меня адреса не в одной подсети, а прописывать каждый айпишник отдельно — длинно будет.
А ограничение на длину TXT записи есть? И еще назрел вопрос:
вот у гугла так рекомендуют подключать gmail на свой домен:
TXT «v=spf1 include:aspmx.googlemail.com ~all»
но в манах разных версий про «include» как-то не пишут… — это типа, что и ip4, только для имени хоста? Просто не понятно, что в моей ситуации лучше указать…
А ограничение на длину TXT записи есть? И еще назрел вопрос:
вот у гугла так рекомендуют подключать gmail на свой домен:
TXT «v=spf1 include:aspmx.googlemail.com ~all»
но в манах разных версий про «include» как-то не пишут… — это типа, что и ip4, только для имени хоста? Просто не понятно, что в моей ситуации лучше указать…
Это инклюд 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»
«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»
По идее — да.
Но надежнее, имхо, прописать ip4:subnet/shortmask, как например у мыла.ру сделано.
Но надежнее, имхо, прописать ip4:subnet/shortmask, как например у мыла.ру сделано.
Спасибо, оч познавательно.
Стоит добавить заметку, как напрочь выключить почту на домене в DNS. Где-то проскакивало, что нужно в MX прописать поддомен «not-mail.»
Хм, не сталкивался. А по-подробнее можно?
Вот я не хочу на домен принимать почту. Удаляю MX вообще. Спам всё-равно сыпится на A-записи. Куда курить?
Отключить на почтовом сервере, по IP А-записи прием почты для нужного домена. А как еще? И главное — зачем?
На хостинг направлены тысячи доменов, почта для них не нужна. Для остальных нужна. Как разделять их?
Правильно настроенный почтовый сервер не примет почту для доменов, не перечисленных ему как обслуживаемые им.
Правильно настроенный сервер принимает все соединения и шлет отлупы на каждый запрос принять почту. По нашим логам на один домен в день идет 5-9 соединений на стандартные ящики — с надежной что почта пройдет. Домены тысячи, трафика мегабайты.
Перенастройте так, чтобы при попытке доставки на несуществующий домен сбрасывалось соединение. Это, имхо, простейщий путь.
Это не выход. Самый простейший путь — не доводить до соединения вообще.
Если ваш сервер принимает все для всех доменов — очень легко начать долбить его ботом и нагнать вам трафика. Зачем создавать себе проблемы?
Это не релей, не путайте. Я выше писал, что соединения на 25 порту принимаются все, а дальше в процессе диалога решается — что и куда. Так вот тысячи спамных соединений на домены, на которые почта не нужна вовсе (удалены mx), всё-равно долбятся на сервер и хотят отправить почту. В процессе общения они, естественно, получают отказ, но им же не скажешь «перестаньте присылать спам».
указать в MX несуществующий сервер, например fuckyouspammers.local
SPF ещё не так сильно как хотелось бы распространена.
К сожалению, да. Хотя популярные бесплатные почтовики ее уже используют — уже легче.
У 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 использовать нежелательно.
есть домен @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 использовать нежелательно.
Стоит добавить что MX запись должна указывать именно на A-запись.
Писать в mx записи непосредственно IP или CNAME неправильно.
Например так делать нельзя:
example.com. IN MX 10 192.168.1.1
и так тоже не надо:
example.com. IN MX 10 mail
mail IN CNAME superserver
Писать в mx записи непосредственно IP или CNAME неправильно.
Например так делать нельзя:
example.com. IN MX 10 192.168.1.1
и так тоже не надо:
example.com. IN MX 10 mail
mail IN CNAME superserver
Добавил, спасибо. :)
Интересно, а те, кто минусят не хотят прокомментировать?
Интересно, а те, кто минусят не хотят прокомментировать?
> Стоит добавить что MX запись должна указывать именно на A-запись.
> Писать в mx записи непосредственно IP или CNAME неправильно.
Это с чего вдруг?
> Писать в mx записи непосредственно IP или CNAME неправильно.
Это с чего вдруг?
сорри, попутал, citrin, ты прав.
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.
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.
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.
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.
Я тут еще вот так извращался: я.блоги
Я бы с интересом почитал о правильной организации легальной рассылки — как контролировать доставку и обрабатывать отказы сервера принимать почту и т.п., какие подводные камни могут быть у политики 'отправил и забыл', какие проблемы можно получить с абузом, если что-то не так настроил или куда-то неправильно отослал, и т.п.
> A
> MX
> PTR
> TXT
> Второй — обязательный, без него почта в 99% случаев не будет ходить вообще.
Наоборот, в 99.9% случаев будет ходить на А.
> MX
> PTR
> TXT
> Второй — обязательный, без него почта в 99% случаев не будет ходить вообще.
Наоборот, в 99.9% случаев будет ходить на А.
По-английски «Address» пишется с двумя «d».
только в пятницу перекопал весь инет в поисках подобной инфы — и вот вам пожалуста — она сама к тебе сваливается, когда уже итак всё знаешь…
Почту править спешит Айболит
И три слова он громко кричит:
DNS, PTR, SPF!
И три слова он громко кричит:
DNS, PTR, SPF!
Да! Отличное начало. Про реверс только надо так, чтобы в глаза било, а то у вас к сожалению не описано, что будет, если реверс не будет прописан. То есть что почту никто не примет без реверса, и с реверсом вида ppp-12-23-34-45.provider.net то же. Последнее конечно не обязательное требование, но я фильтрую — много срезает трафика от спамбот-сетей.
Еще не забывайте что бывает SPF запись на EHLO имя.
dig mail.example.com txt
mail.example.com. 86400 IN TXT «v=spf1 a -all»
чтобы под вашим EHLO в чужие домены не представлялись.
dig mail.example.com txt
mail.example.com. 86400 IN TXT «v=spf1 a -all»
чтобы под вашим EHLO в чужие домены не представлялись.
Критика:
«Второй [MX] — обязательный, без него почта в 99% случаев не будет ходить вообще.»
Это почему? Если нет записи MX, а есть запись A, то по RFC нужно долбиться на A, и нормальные сервера все держат такую функциональность.
«Для корректной работы почты требуется A-запись сервера почты (mail.example.com).»
Это почему? Записи MX достаточно: если она есть, то запись A не нужна.
«Второй [MX] — обязательный, без него почта в 99% случаев не будет ходить вообще.»
Это почему? Если нет записи MX, а есть запись A, то по RFC нужно долбиться на A, и нормальные сервера все держат такую функциональность.
«Для корректной работы почты требуется A-запись сервера почты (mail.example.com).»
Это почему? Записи MX достаточно: если она есть, то запись A не нужна.
Статью можно обновить, DKIM добавить.
Весьма понравилось объяснение, поечему нужно иметь запись SPF. Она не входит в стандарт почтового протокола. И ни один здоровый админ не будет считать вас спамером, если у вас настроена MX-запись, A-запись, PTR-запись. Более того, если у вас всё в порядки с этими пунктами но нет SPF и ему шлют всякие дикобразы письма от вашего домена и он вас считает спамером, то этот админ долбан!
К тому же не однократно уже освещались проблемы неверной записи SPF, или устаревшей записи SPF, которую пропустили, или праят банальным дописыванием, боясь сломать то, что в ней уже описано. И получается только лишняя точка с боя.
Глобальная идея протокола SMTP состоит в том, что внешние почтовые шлюзы принимают и отправляют почту от MX серверов. А если вы на столько глупы, чтобы разрешить слать на свой сервер сторонним PHP-скриптовым тачкам, то вы весьма недалёкий человек.
Хотя яндекс именно так и делает. И не встречает критики своих действий.
К тому же не однократно уже освещались проблемы неверной записи SPF, или устаревшей записи SPF, которую пропустили, или праят банальным дописыванием, боясь сломать то, что в ней уже описано. И получается только лишняя точка с боя.
Глобальная идея протокола SMTP состоит в том, что внешние почтовые шлюзы принимают и отправляют почту от MX серверов. А если вы на столько глупы, чтобы разрешить слать на свой сервер сторонним PHP-скриптовым тачкам, то вы весьма недалёкий человек.
Хотя яндекс именно так и делает. И не встречает критики своих действий.
Sign up to leave a comment.
Почтовая кухня #1: DNS