SPF не связан с обратной зоной и будет проходить независимо от PTR.
Но да, проблемы у вас будут. Mail.Ru принимает почту и при отсутствии PTR, но, например AOL принципиально не принмает письма с сервера без PTR записей. Вариантов два — менять провайдера или уносить сервер на хостинг.
Пока вы не опубликуете DMARC-политику для site.ru каких-либо проблем, связанных с DMARC у вас не возникнет.
Чтобы правильно и без проблем внедрить DMARC вам надо сделать следующее:
1. в SPF-запись добавить IP серверов с которых вы шлете письма напрямую + включить SPF-политику яндекса через include:_spf.yandex.ru или redirect=_spf.yandex.ru.
2. на pdd сгенерировать DKIM-ключ для pdd и прописать его в своей зоне. На самом деле он уже сгенерирован и найти его можно запросом
host mail._domainkey.securityvulns.ru dns1.yandex.ru
даже если ваша зона хостится не у Яндекса.
3. Прописать сгенерировать и прописать ключи для всех остальных серверов рассылающих почту от site.ru (следует использовать другие селекторы DKIM)
4. Прописать DMARC-политику, для начала нестрогую.
Мы добавили тот вариант, который чаще поддерживается + расписали рекомендованные варианты для разных почтовых программ. Если есть какая-то популярная программа, которую забыли — напишите, добавим и ее. Боюсь, что если мы добавим в справке оба варианта, путаницы будет не меньше, а больше.
STARTTLS и SSL здесь используются не для обозначения шифрования, т.к. в обоих случаях используется TLS, а для удобства различения двух технологий.
Поэтому протокол не является устаревшим, на самом деле в обоих случаях используется шифрование TLS. Я считаю, что TLS на выделенном порту немного более безопасен, т.к. в нему отсутствует специфичные для STARTTLS pre-TLS атаки, такие как CVE-2011-0411, CVE-2014-3556, CVE-2015-6409, CVE-2011-1575 и т.п.
Это кроме случая, когда домен site.ru публикует DMARC-политику с полем aspf=s, s (strict) требует строгого соответствия домена из SPF и домена из From.
Ну и вообще — если site.ru не публикует DMARC-политику, то беспокоиться о DMARC не надо.
DMARC проверяет align для организационного домена. Организационный домен это например example.org или example.or.uk (т.е. первый поддомен в домене, открытом для регистрации). Список доменов открытых для регистрации обычно берется из http://publicsuffix.org. Т.е. если в SPF сработает mailer.example.org а в From будет example.org — это нормально, т.е. организационный домен в данном случае example.org и он совпадает.
Транзакционные и маркетинговые письма всегда следует слать с разных адресов. Это облегчает пользователю создание фильтров. Иначе ваши транзакционные письма пойдут в папку, в которую пользователь отправляет рассылки и которую в 90% случаев не читает.
В таком случае он нажмет "Не спам". К сожалению, это гораздо более редкий кейс, чем рассыльщики, которые начинают через несколько месяцев опять теребить пользователя. И пользователи очень редко рассматривают разные категории писем от одного сайта как разные рассылки с необходимостью отписываться от каждой отдельно + при необходимости, разные категории писем рассыльщик может слать с разных адресов, мы не возбраняем такое поведение.
При планировании функционала мы исходили из того, что юзер, нажимающий на кнопку "Отписаться" считает полученное сообщение ненужным и не желает в дальнейшем получать сообщения от данного отправителя. Поэтому, помимо обращения к List-Unsubscribe, считаем удобным для пользователя убрать письмо в Спам и перенести туда же дальнейшие письма от данного отправителя. По нашим представлениям, если отправитель правильно обрабатывает List-Unsubscribe, это никак на нем не скажется, т.к. в дальнейшем пользователь от него сообщений не получит. Если же List-Unsubscribe обрабатывается неправильно, то мы действуем исходя из интересов нашего пользователя, а не рассыльщика.
Совет не использовать List-Unsubscribe в любом случае не верен, т.к. в таком случае на полученном письме пользователь будет нажимать "Спам" или просто будет удалять полученные письма не читая, что еще более негативно скажется на репутации отправителя.
Более правильным советом будет помимо List-Unsubscribe в самом письме расположить отписку на видимом месте, чтобы пользователь переходил на отписку по ссылке из письма, а не по кнопке из интерфейса.
Кстати, информация про GMail не соответствует действительности — отписка там так же затрагивает репутацию рассылки и она может быть в результате перенесена в спам.
А что несерьезного с Lua? У Lua своя ниша, где он вне конкуренции — как встроенный язык для скриптинга/автоматизации в различных движках. Вот только работают с ним чаще всего не профессиональные программисты, а администраторы или даже конечные пользователи.
Qrator работает фактически как обратный прокси между вами и внешней сетью и отрезает все, что похоже на флуд, в том числе и request flood к API. Если у вас сервер от одного запроса ложится — тогда да, Qrator вряд ли поможет.
В этой статье подробно разобран механизм группировки. Если тему кто-то меняет руками — считается, что человек хочет создать новый тред, поэтому должна быть создана новая цепочка. Автоматические префиксы не меняют цепочку.
Вот пример: в ближайшем релизе 3proxy (на opensource.mail.ru ссылки на 3proxy пока нет, т.к. я не успел подготовить описание, но он там будет) появится функционал reverse connect, который потребовался для рабочих задач, соответственно написание фунционала шло преимущественно «по ночам», но отлаживался и багфиксился в рабочее время. Это значит работодатель вкладывался или нет?
Другой пример: File API Кости Лебедева используется в «Облаке» и «Почте», входит в скоп bug bounty этих проектов и, так или иначе, над ним работает не только сам автор, но и, например, команды тестирования и продуктовой безопасности.
По собственному опыту, крайне редко пишется личный проект, который никак не связан с работой и чисто в свободное время. Как правило, есть пересечение с работой и по времени и по функционалу.
Привет.
Владимир Дубровин это я, но не директор, а руководитель службы тестирования. Наша команда в Нижегородском офисе Mail.Ru тестирует проекты почты и портала (Почту, облако, календарь и контентные проекты). (А вот pifagor_mc — директор по качеству, не надо нас путать. А еще он читает рэп).
Участие в конкурсе Яндекс.Браузера к корпоративной войне не имеет никакого отношения, просто так получилось, что безопасностью я начал интересоваться задолго до Яндекса и Mail.Ru и свой первый эксплоит на выполнение кода в браузере написал еще в 2002м году. Иногда к этой теме возвращаюсь. Поэтому так получилось, что я поучаствовал в конкурсе и так получилось, что я его выиграл, что было почти полной неожиданностью, так как делаю я это крайне редко и специалистом по безопасности себя не считаю.
А с командой Яндекса я дружу уже более десяти лет.
Cпасибо всем за поздравления, Яндексу за щедрые призы и организаторам ZeroNights за замечательную конференцию.
Но да, проблемы у вас будут. Mail.Ru принимает почту и при отсутствии PTR, но, например AOL принципиально не принмает письма с сервера без PTR записей. Вариантов два — менять провайдера или уносить сервер на хостинг.
Чтобы правильно и без проблем внедрить DMARC вам надо сделать следующее:
1. в SPF-запись добавить IP серверов с которых вы шлете письма напрямую + включить SPF-политику яндекса через include:_spf.yandex.ru или redirect=_spf.yandex.ru.
2. на pdd сгенерировать DKIM-ключ для pdd и прописать его в своей зоне. На самом деле он уже сгенерирован и найти его можно запросом
host mail._domainkey.securityvulns.ru dns1.yandex.ru
даже если ваша зона хостится не у Яндекса.
3. Прописать сгенерировать и прописать ключи для всех остальных серверов рассылающих почту от site.ru (следует использовать другие селекторы DKIM)
4. Прописать DMARC-политику, для начала нестрогую.
Поэтому протокол не является устаревшим, на самом деле в обоих случаях используется шифрование TLS. Я считаю, что TLS на выделенном порту немного более безопасен, т.к. в нему отсутствует специфичные для STARTTLS pre-TLS атаки, такие как CVE-2011-0411, CVE-2014-3556, CVE-2015-6409, CVE-2011-1575 и т.п.
P.S. Mail.Ru поддерживает и то и другое.
Ну и вообще — если site.ru не публикует DMARC-политику, то беспокоиться о DMARC не надо.
Совет не использовать List-Unsubscribe в любом случае не верен, т.к. в таком случае на полученном письме пользователь будет нажимать "Спам" или просто будет удалять полученные письма не читая, что еще более негативно скажется на репутации отправителя.
Более правильным советом будет помимо List-Unsubscribe в самом письме расположить отписку на видимом месте, чтобы пользователь переходил на отписку по ссылке из письма, а не по кнопке из интерфейса.
Кстати, информация про GMail не соответствует действительности — отписка там так же затрагивает репутацию рассылки и она может быть в результате перенесена в спам.
Другой пример: File API Кости Лебедева используется в «Облаке» и «Почте», входит в скоп bug bounty этих проектов и, так или иначе, над ним работает не только сам автор, но и, например, команды тестирования и продуктовой безопасности.
То же самое и по остальным проектам.
Владимир Дубровин это я, но не директор, а руководитель службы тестирования. Наша команда в Нижегородском офисе Mail.Ru тестирует проекты почты и портала (Почту, облако, календарь и контентные проекты). (А вот pifagor_mc — директор по качеству, не надо нас путать. А еще он читает рэп).
Участие в конкурсе Яндекс.Браузера к корпоративной войне не имеет никакого отношения, просто так получилось, что безопасностью я начал интересоваться задолго до Яндекса и Mail.Ru и свой первый эксплоит на выполнение кода в браузере написал еще в 2002м году. Иногда к этой теме возвращаюсь. Поэтому так получилось, что я поучаствовал в конкурсе и так получилось, что я его выиграл, что было почти полной неожиданностью, так как делаю я это крайне редко и специалистом по безопасности себя не считаю.
А с командой Яндекса я дружу уже более десяти лет.
Cпасибо всем за поздравления, Яндексу за щедрые призы и организаторам ZeroNights за замечательную конференцию.
P.S. а еще мы тоже платим за баги, приходите.
P.P.S. И да, в нашем Bug Bounty участвуют ребята из Яндекс (и не только) и находят у нас крутые баги.