На самом деле смысла много, даже с p=none, просто проблемы надо решать, если они появляются. И способов много:
Во-первых использовать на постороннем сервере ваш домен без вашего ведома — в общем-то это именно то, с чем борется DMARC. Поэтому я и пишу, что в первую очередь, надо работать с community, чтобы сообщество понимало, что так делать не надо.
Во-вторых, имея IP адрес, вы почти всегда можете отследить всю необходимую информацию по собственным логам (если кто-то настроил отправку с вашего домена и не шлет на ваши адреса — это немного странно). Настроить у себя проверку DMARC не сложно, помимо «референсного» OpenDMARC могу порекомендовать еще очень неплохой, хотя и малоизвестный проект yenma.
В-третьих, в DMARC кроме аггрегированных отчетов есть еще forensic (включаются через fo= и ruf= в _dmarc-записи), правда большая часть мейлбокс-провайдеров пока не шлет форенсик-отчеты из соображений безопасности. Ситуация может измениться, когда DMARC будет окончательно принят как стандарт. Сейчас из крупных сервисов forensic-отчеты шлют Microsoft и Linkedin. Forensic-отчет включает в себя практически полный набор заголовков, а иногда и текст письма.
В-четвертых, mail.ru на таких письмах будет показывать предупреждение о возможной подмене отправителя. А mail.ru это примерно половина всех русскоязычных получателей и это лишний повод для «Кто-то (из пользователей)» так не делать.
В-пятых, на уровне крупных организаций, можно воспользоваться услугами специализирующихся на безопасности и доставляемости электронной почты компаний, таких как ReturnPath и Agari. Последняя практически полностью специализируется на DMARC. Они «умеют» получать forensic-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.
p=reject используется пока только на технологических и рассылочных доменах, технически мы уже готовы к ее включению на доменах с ящиками пользователей, но необходима предварительная работа с community чтобы избежать потенциального «шока» от включения, чем мы и планируем заняться.
Прямо сейчас мы не просто поддерживаем DMARC, но и начинаем показывать уведомления на тех письмах, которые пока проходят проверку из-за p=none, но могут попасть под более строгие фильтры в будущем. Это должно сподвигнуть администраторов почтовых серверов и рассылок исправить потенциальные проблемы. Когда закончим внедрение этой фичи напишем статью о том, как все это работает и какие планы на ближайшее будущее.
Редиректы будут работать, т.к. редиректы не меняют заголовков письма и не бьют DKIM-подпись (исключения были, например до недавнего времени Рамблер менял To:). Так же нормально будут работать списки рассылки, которые не меняют содержимое, тему письма и другие подписанные заголовки. Крупные списки рассылки, например Google Groups уже ведут себя корректно по отношению к DMARC, и в From: подставляют свой адрес при изменении содержимого писем, а не адрес оригинального отправителя и переподписывают письмо своим DKIM.
Вообще строгий DMARC будут вводить все крупные провайдеры, и довольно скоро, так что владельцам списков рассылки уже надо быть к этому готовыми.
К сожалению, от статьи действительно может быть больше вреда чем пользы. Есть такие аспекты:
На доменах с «живыми» пользователями нельзя использовать потитику -all
существуют списки рассылки и редиректоры (например перенаправления с одного ящика в другой), которые не меняют адрес в SMTP-конверте. Ваши пользователи на смогут писать пользователям на адреса-редиректоры и в списки рассылки, т.к. SPF будет биться.
Политику -all можно использовать только на «тразакционных» доменах, в которых находятся только ролевые адреса.
Для «живых» получателей нельзя реджектить письма по результатам только SPF проверки
по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
По этим двум причинам ни один Mailbox Provider не устанавливает политику -all для своих доменов и не реджектит письмо только на основании SPF. Так что ваш эксперимент с письмам от microsoft на google в общем-то был ошибочен, SPF так не работает.
При установке SPF "-all" для поддоменов скорей всего отломается хождение NDR (отчетов о доставке письма от Mailer Daemon).
Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
DMARC это не шифрование
это политика, в которой вы можете в явном виде указать, как следует поступать с письмами от вашего домена, которые не проходят аутентификацию. Я бы настоятельно рекомендовал вам до включения "-all" в SPF вместо "~all" сделать запись DMARC для получения отчетов. По этим отчетам вы сможете понять, какое количество валидных писем вы можете потенциально потерять.
SPF не принесет вам профита. Внедрение SPF для вашего домена не дает вам никакой пользы.
SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
SPF защищает только адрес конверта, который не видим получателю. Об этом выше сказали. Точно так же, сам по себе не работает DKIM. Поэтому имеет смысл использовать SPF только как один из механизмов аутентификации отправителя письма в рамках политики DMARC.
К сожалению, тут есть проблемы, но они потенциально решаемые.
В настоящее время стандартом де-факто Oauth 2.0 в IMAP и SMTP является расширение SASL XOAUTH2 предложенное Google. Это расширение во-первых не стандартизовано, во-вторых не позволяет полноценного получения токена и не отвечает на вопрос где и как его получать. Т.е. Почтовая программа должна как-то самостоятельно определять где и как получать токен по HTTP. С версии 38.0.1 в Thunderbird вшита поддержка Oauth но только для серверов GMail. Как будет обстоять поддержка с OAuth других почтовых служб (Outlook.com, mail.ru) пока не ясно.
Имеется черновой стандарт draft-ietf-kitten-sasl-oauth продвигаемый Microsoft, над которым в настоящее время идет работа. Этот стандарт хорош тем, что не зависит от почтовой службы, клиентскому приложению достаточно будет реализовать его. Когда стандарт более-менее устаканится, можно будет реализовывать его поддержку как со стороны серверов, так и со стороны клиентов. Пока он не реализован даже самим Microsoft.
Пересылка может быть несовместима с некоторыми стандартами, например с SPF аутентификацией в DMARC, из-за чего возрастает вероятность, что пересланное письмо попадет под спам-фильтр + пересылка хороша в том случае, если адрес с которого она установлена не используется. OAuth позволяет производить аутентификацию не только получения, но и отправку почты от имени пользователя, не нарушая SPF/DKIM/DMARC. Cборщик почты в таком случае работает как полноценный почтовый клиент.
По умолчанию во многих системах telnet использует переводы строк LF, почтовые протоколы требуют CRLF. Поэтому примеры могут работать не правильно. Кроме того, telnet может заменять часть символов, например с кодом 255. Лучше использовать nc с ключиком -C.
Простое решение — иметь почтовую машину вне ДЦ и вне боевой подсети, которая будет работать почтовым релеем и отрезать весь «Received», что у неё есть.
Даже при перечисленных мерах, IP утечет в DNS-запросе при разрешении имени почтового домена. И вообще IP не обязательно утекает через письмо, это может быть любая server side активность, например запрос аватарки по урлу.
Чтобы подобного избежать, необходимо идентифицировать и перенаправить весь трафик, который создается сервером, не только письма.
Там вся легенда прописана — это именно карта по числу пользователей, при этом в России число коммитов на пользователя почти вдвое больше, чем в среднем по гитхабу, так что по коммитам все еще «краснее». Статистика по коммитам и по пользователям идет по краю карты.
Я наблюдаю совсем другую картину — наши люди коммитят в ядра Linux и FreeBSD, создают nginx и продукты конкурирующие с теми, что вы используете. Или посмотрите, например, кто коммитит в MySQL.
Не согласен с таким подходом: взять один проект, да еще выросший из внутренней разработки Berkley. Почему бы не посмотреть статистику? Россия на 8м месте по числу коммитов в Github, что весьма неплохо.
P.S. А вы, уважаемый автор, куда коммитите, если не секрет?
DHCP опция 252 скорее всего не решает проблемы, фактически она вообща мало на что влияет. Настройки WPAD не получаются одновременно с получением IP. В старых версиях Windows настройки WPAD запрашивались в Internet Explorer отдельным запросом DHCPINFORM при старте браузера, причем только если у пользователя были права администратора, в современных не уверен, что какой-либо браузер вообще ее поддерживает, хотя не проверял и могу ошибаться.
значит, портальное меню должно быть разделено как минимум на три части: стили, скрипт и базовый HTML. HTML должен вставляться в нужное место на странице, рисующееся при загрузке; далее скрипт будет интегрировать туда различные элементы.
А значит, если нет скрипта — будет показываться базовый HTML, который показывается при загрузке.
А еще проще было бы работать всем на одном, фреймворке. Но на практике многие проекты уже приходят готовыми, например в результате слияний или поглощений. Где-то mail.ru выступает в качестве издателя, локализатора или партнера.
Ограничение 40 символов, но прямой зависимости между длиной пароля и его надежностью нет. На практике, 6-символьный пароль из случайных символов не брутфорсится даже в заказных взломах, если только вы не политик или celebrity на которых может идти постоянная направленная атака. А вот пароль из имени, фамилии и даты рождения в любом написании легко будет взломан, несмотря на большое количество символов.
Во-первых использовать на постороннем сервере ваш домен без вашего ведома — в общем-то это именно то, с чем борется DMARC. Поэтому я и пишу, что в первую очередь, надо работать с community, чтобы сообщество понимало, что так делать не надо.
Во-вторых, имея IP адрес, вы почти всегда можете отследить всю необходимую информацию по собственным логам (если кто-то настроил отправку с вашего домена и не шлет на ваши адреса — это немного странно). Настроить у себя проверку DMARC не сложно, помимо «референсного» OpenDMARC могу порекомендовать еще очень неплохой, хотя и малоизвестный проект yenma.
В-третьих, в DMARC кроме аггрегированных отчетов есть еще forensic (включаются через fo= и ruf= в _dmarc-записи), правда большая часть мейлбокс-провайдеров пока не шлет форенсик-отчеты из соображений безопасности. Ситуация может измениться, когда DMARC будет окончательно принят как стандарт. Сейчас из крупных сервисов forensic-отчеты шлют Microsoft и Linkedin. Forensic-отчет включает в себя практически полный набор заголовков, а иногда и текст письма.
В-четвертых, mail.ru на таких письмах будет показывать предупреждение о возможной подмене отправителя. А mail.ru это примерно половина всех русскоязычных получателей и это лишний повод для «Кто-то (из пользователей)» так не делать.
В-пятых, на уровне крупных организаций, можно воспользоваться услугами специализирующихся на безопасности и доставляемости электронной почты компаний, таких как ReturnPath и Agari. Последняя практически полностью специализируется на DMARC. Они «умеют» получать forensic-информацию даже от тех провайдеров, которые не дадут ее вам напрямую.
Прямо сейчас мы не просто поддерживаем DMARC, но и начинаем показывать уведомления на тех письмах, которые пока проходят проверку из-за p=none, но могут попасть под более строгие фильтры в будущем. Это должно сподвигнуть администраторов почтовых серверов и рассылок исправить потенциальные проблемы. Когда закончим внедрение этой фичи напишем статью о том, как все это работает и какие планы на ближайшее будущее.
Вообще строгий DMARC будут вводить все крупные провайдеры, и довольно скоро, так что владельцам списков рассылки уже надо быть к этому готовыми.
существуют списки рассылки и редиректоры (например перенаправления с одного ящика в другой), которые не меняют адрес в SMTP-конверте. Ваши пользователи на смогут писать пользователям на адреса-редиректоры и в списки рассылки, т.к. SPF будет биться.
Политику -all можно использовать только на «тразакционных» доменах, в которых находятся только ролевые адреса.
по тем же самым причинам — они не смогут устанавливать редиректы на свой ящик и получать письма из списков рассылки. Поэтому строго следовать результатам SPF так же можно только на «ролевых» ящиках.
По этим двум причинам ни один Mailbox Provider не устанавливает политику -all для своих доменов и не реджектит письмо только на основании SPF. Так что ваш эксперимент с письмам от microsoft на google в общем-то был ошибочен, SPF так не работает.
Письма от Mailer Daemon (отчеты о доставке) идут с пустым MAIL FROM:. По RFC 7208 в таком случае проверяется имя из HELO сервера. Как минимум для этого имени (или имен) необходима дополнительная SPF-запись. Если вы поставите "-all" для всех поддоменов, то получите проблемы.
это политика, в которой вы можете в явном виде указать, как следует поступать с письмами от вашего домена, которые не проходят аутентификацию. Я бы настоятельно рекомендовал вам до включения "-all" в SPF вместо "~all" сделать запись DMARC для получения отчетов. По этим отчетам вы сможете понять, какое количество валидных писем вы можете потенциально потерять.
SPF никак не повлияет ни на количество входящего спама ни на возможность подделать ваш адрес.
SPF защищает только адрес конверта, который не видим получателю. Об этом выше сказали. Точно так же, сам по себе не работает DKIM. Поэтому имеет смысл использовать SPF только как один из механизмов аутентификации отправителя письма в рамках политики DMARC.
В настоящее время стандартом де-факто Oauth 2.0 в IMAP и SMTP является расширение SASL XOAUTH2 предложенное Google. Это расширение во-первых не стандартизовано, во-вторых не позволяет полноценного получения токена и не отвечает на вопрос где и как его получать. Т.е. Почтовая программа должна как-то самостоятельно определять где и как получать токен по HTTP. С версии 38.0.1 в Thunderbird вшита поддержка Oauth но только для серверов GMail. Как будет обстоять поддержка с OAuth других почтовых служб (Outlook.com, mail.ru) пока не ясно.
Имеется черновой стандарт draft-ietf-kitten-sasl-oauth продвигаемый Microsoft, над которым в настоящее время идет работа. Этот стандарт хорош тем, что не зависит от почтовой службы, клиентскому приложению достаточно будет реализовать его. Когда стандарт более-менее устаканится, можно будет реализовывать его поддержку как со стороны серверов, так и со стороны клиентов. Пока он не реализован даже самим Microsoft.
Даже при перечисленных мерах, IP утечет в DNS-запросе при разрешении имени почтового домена. И вообще IP не обязательно утекает через письмо, это может быть любая server side активность, например запрос аватарки по урлу.
Чтобы подобного избежать, необходимо идентифицировать и перенаправить весь трафик, который создается сервером, не только письма.
Я наблюдаю совсем другую картину — наши люди коммитят в ядра Linux и FreeBSD, создают nginx и продукты конкурирующие с теми, что вы используете. Или посмотрите, например, кто коммитит в MySQL.
P.S. А вы, уважаемый автор, куда коммитите, если не секрет?
А значит, если нет скрипта — будет показываться базовый HTML, который показывается при загрузке.