DKIM проверяется по статистическим данным за предыдущий день и будет показываться только при наличии переписки с ящиками на Mail.Ru в предшествующий день или ранее.
Reindexer вы тестировали как in-app библиотеку, а все прочие — как внешний сервер BD и сами ниже пишете, что использование Reindexer'а как внешнего сервера сильно влияет на производительность, т.е. такое сравнение очевидно не корректно.
Не пробовали сравнить по производительности конечного приложения tarantool+lua с go+reindexer?
Кстати, на днях опубликовали вот такой драфт по Lenient DKIM: www.ietf.org/id/draft-vanrein-dkim-lenient-00.txt
Мысль гораздо правильней чем ARC, она позволяет отследить какие изменения были внесены в подписанное письмо. Но боюсь, что в реальности ARC будет принят, а Lenient DKIM нет, т.к. за ARC'ом стоят бородатые стандартописатели.
Если у спамера нет задачи реально доставить письма — то поможет все что угодно. Мы по статистике DMARC до сих пор видим миллионные рассылки, которые реально доходят только до единичных ящиков, на которых вообще нет спам-фильтров, потому что DMARC в отличие от SPF дает возможность строго фильтровать поддельные письма.
Против качественного спама грейлистинг сам по себе не спасет, вы просто получите спам на несколько минут позднее, если вы не умеете выделять рассылки, их классифицировать и накапливать репутацию по отдельным рассылкам. Грейлистинг используется чтобы накопить информацию о рассылке и ее классифицировать.
То что вы не видите «качественного» спама скорей всего означает, что на вас его еще не таргетировали, и вы просто неуловимый Джо.
Потому что сейчас стоимость регистрации какого-нибудь домена $0, домена в приличной зоне — $2-3. Стоимость хостинга DNS $0. Поэтому в спаме все чаще используются не подменные адреса, а свежие домены с нулевой историей, которые регистрируются под одну рассылку, причем рассылки проводятся очень быстро (за время порядка 5 минут) с высокой интенсивностью. На таких рассылках может быть и SPF и DKIM и DMARC.
С точки зрения современных антиспам-систем это одно и то же — что на письмах с отсутствующей авторизацией, что на письмах с доменов без истории нельзя использовать репутацию домена и работают другие классификаторы и как правило эти рассылки не создают проблем. А вот для фильтров по SPF, DNSBL, простых сигнатурных антиспам-систем и т.п. такие рассылки часто «невидимы».
Да, такая проблема есть. По стандартам, для этих целей должен быть работающий адрес postmaster@ или abuse@, вы можете попробоваться связаться по ним. Ответ сервера 5xx так же может содержать информацию (например URI) с контактами для решения проблемы. Но, к сожалению, на практике postmaster@ часто не работает или работает, но никем не читается.
Вообще любая автоматическая фильтрация почты это зло, но реальность такова, что спам составляет более 90% писем. Отказываться от автоматической фильтрации значит перекладывать фильтрацию на пользователя, и это не вариант, т.к. пользователь ошибается нисколько не реже (может удалить или засунуть в папку спама нужное письмо). Кроме того, 15 минут рабочего времени в день, потраченные на разбор спама это итоговые потери, сравнимые с потерями по больничным листам. Поэтому надеяться, что кто-то откажется от спам-фильтрации, не стоит.
Есть лайфхак: как правило, банки (и не только) очень внимательно мониторят соц. сети, вы можете попробовать донести информацию там, добавив правильные теги. Но не забывайте, что ваша задача решить конкретную проблему, а не обидеться или высказать претензию :) совместное решение проблемы будет позитивным откликом и для вас и для банка.
Так работают вайлдкарды в большинстве DNS-серверов — вайлдкард возвращается только если нет записи с таким именем любого типа. Если не сделать отдельную экранирующую запись для www, то запрос TXT-записи www.example.com. вернет 0 записей данного типа даже при наличии вайлдкарда, потому что есть A-запись www.example.com.
Для mail.example.com нужна разрешающая запись, которая разрешит серверу mail.example.com использовать это имя в команде HELO.
Все еще сложнее. В идеале, если у вас есть зона, например: example.com. IN MX 10 mail.example.com.
example.com. IN A 1.2.3.4
mail.example.com. IN A 1.2.3.5
www.example.com. IN A 1.2.3.4
Сервер mail.example.com имеет каноническое имя mail.example.com и сконфигурирован использовать его в команде HELO. Тогда нужны следующие записи:
; основная SPF-запись
example.com. IN TXT "v=spf1 mx a ~all"
; SPF-запись для HELO
mail.example.com. IN TXT "v=spf1 a -all"
; SPF-запись экранирующая www.example.com (при условии что это имя не каноническое и не используется в HELO)
www.example.com. IN TXT "v=spf1 -all"
; экранирующий SPF-wildcard
*.example.com. IN TXT "v=spf1 -all"
совсем в идеале вместо
example.com. IN TXT "v=spf1 mx a ~all"
лучше использовать
example.com. IN TXT "v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 ~all"
В статистике Postmaster@ отображаются только письма, имеющие DKIM-авторизацию вашего домена, независимо от того, с какого адреса они были отправлены, возможно, что не принимаемые письма не имеют DKIM подписи или она некорректна, это же может быть и причиной их классификации как спама.
Но лучше отправить информацию, включая логи на адрес postmaster@corp.mail.ru.
ARC еще не принят в качестве стандарта и мы активно участвуем в его обсуждении и разработке в рамках M3AAWG и IETF. Пока наша позиция в основном критическая — дело в том, что ARC фактически является заменой вайтлистов по DKIM, при этом он критикуется за избыточное использование криптографии (там где она бесполезна или не требуется для решения задач).
Если кратко — основные проблемы ARC в том, что
1. он требует установления доверия ко всей подписывающей цепочке. Каких-либо способов установления такого доверия сам стандарт не дает. Это планируется решать за счет включения модерируемого списка «доверенных» форвардеров в основные продукты, поддерживающие ARC. По этой причине ARC мало кому помогает и не является полноценной замной используемых сейчас списков доверенных форвардеров и совсем никак не помогает администраторам небольшого списка рассылки, например — т.к. алгоритм попадания в публикуемые списки не известен, а без него ARC бесполезен.
2. Используемый алгоритм цепочки подписей в ARC бесполезен, т.к. нужен для транзитивного доверия (как в цепочке сертификатов, например), которого в ARC нет, поэтому вся эта цепочка не имеет смысла, было бы достаточно только подписи последнего
хоста в цепочке.
3. ARC добавляет очень много информации к заголовкам сообщений. Это может привести к проблемам во многих MTA, где есть ограничения на размер заголовка.
Но, разумеется, если ARC будет внедрен и будет поддерживаться основными MTA/менеджерами списков рассылки, мы так же реализуем его поддержку.
Да, но, к сожалению, очень много скриптов имеют те или иные ошибки, даже у очень крупных компаний. Например, нам приходилось связываться с разработчиками iCloud по поводу некорректного формирования писем в их сервисе. Так что строгого соответствия стандартам сразу начать требовать нельзя. Правильно сформировать письмо не так просто, как кажется. А вот многие спамеры наоборот о почте знают больше чем большинство разработчиков приложений, решивших написать генерацию письма. Пока с такой сигнатурой идет нормальный трафик и не идет спам — он пропускается. Если с такой сигнатурой пойдет спам — она будет может быть блокирована или отправлена в спам.
Различие адреса конверта и From не является чем-то запрещенным, тем более нарушением стандарта. А вот такая блокировка это не просто нарушение стандарта, она зарежет все не личные письма, т.к. во всех автоматических письмах (включая письма о восстановлениях эккаунтах и т.п.) адрес конверта устанавливается как правило в какой-нибудь специальный обработчик, т.к. на него падают сообщения о невозможности доставки, и адрес конверта и From не просто отличается, но зачастую вообще из другого домена.
Дополню — аналогичная проблема у DKIM.
DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
в SMTP нет аутентификации и соответственно авторизации. Совсем. Есть расширение SMTP для аутентификаци (RFC 4954), SMTP с аутентификацией обычно называется Submission. Но между двумя почтовыми серверами (например Yandex и Mail.Ru) почта по SMTP ходит по обычному SMTP без аутентификации.
SPF изначально предназначался для другого: чтобы забыть про репутации IP-адресов, черные списки, проверки PTR-записей и т.д. и т.п. и вместо них авторизовать по SPF домен почтового сервера и хранить репутацию по почтовым доменам вместо IP, а от всяких странных IP-адресов почту не принимать в принципе, и соответственно избавиться от спама. Этого не случилось, т.к. для этого необходимо чтобы SPF реализовали все.
Соответственно, SPF не защищает письма от подделки. Совсем. SPF это протокол аутентификации почтового сервера на уровне транспорта (SMTP), он вобще не смотрит в содержимое письма и в поле From: в частности. Например, домен bob.com имеет строгую SPF-политику. У атакующего есть домен alice.org, который он контролирует. Атакующий может отправить письмо EHLO alice.org
MAIL FROM: <m@alice.org>
RCPT TO: <some@example.com>
DATA
From: <g@bob.com>
Subject: hello
hello
.
и письмо успешно пройдет SPF-аутентификацию, т.к. SPF проверяет адрес конверта (m@alice.org), но получатель увидит содержимое From:, т.е. g@bob.com.
Это вам так кажется. Яндекс запрещает конкретную комбинацию символов ">>", что никак не связано с безопасностью и не мешает обойти DMARC через другие варианты «неправильного» From, вот в таком случае, например, даже сообщения о подделке нет:
Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.
Не пробовали сравнить по производительности конечного приложения tarantool+lua с go+reindexer?
www.ietf.org/id/draft-vanrein-dkim-lenient-00.txt
Мысль гораздо правильней чем ARC, она позволяет отследить какие изменения были внесены в подписанное письмо. Но боюсь, что в реальности ARC будет принят, а Lenient DKIM нет, т.к. за ARC'ом стоят бородатые стандартописатели.
Против качественного спама грейлистинг сам по себе не спасет, вы просто получите спам на несколько минут позднее, если вы не умеете выделять рассылки, их классифицировать и накапливать репутацию по отдельным рассылкам. Грейлистинг используется чтобы накопить информацию о рассылке и ее классифицировать.
То что вы не видите «качественного» спама скорей всего означает, что на вас его еще не таргетировали, и вы просто неуловимый Джо.
С точки зрения современных антиспам-систем это одно и то же — что на письмах с отсутствующей авторизацией, что на письмах с доменов без истории нельзя использовать репутацию домена и работают другие классификаторы и как правило эти рассылки не создают проблем. А вот для фильтров по SPF, DNSBL, простых сигнатурных антиспам-систем и т.п. такие рассылки часто «невидимы».
Вообще любая автоматическая фильтрация почты это зло, но реальность такова, что спам составляет более 90% писем. Отказываться от автоматической фильтрации значит перекладывать фильтрацию на пользователя, и это не вариант, т.к. пользователь ошибается нисколько не реже (может удалить или засунуть в папку спама нужное письмо). Кроме того, 15 минут рабочего времени в день, потраченные на разбор спама это итоговые потери, сравнимые с потерями по больничным листам. Поэтому надеяться, что кто-то откажется от спам-фильтрации, не стоит.
Есть лайфхак: как правило, банки (и не только) очень внимательно мониторят соц. сети, вы можете попробовать донести информацию там, добавив правильные теги. Но не забывайте, что ваша задача решить конкретную проблему, а не обидеться или высказать претензию :) совместное решение проблемы будет позитивным откликом и для вас и для банка.
Для mail.example.com нужна разрешающая запись, которая разрешит серверу mail.example.com использовать это имя в команде HELO.
example.com. IN MX 10 mail.example.com.example.com. IN A 1.2.3.4
mail.example.com. IN A 1.2.3.5
www.example.com. IN A 1.2.3.4
Сервер mail.example.com имеет каноническое имя mail.example.com и сконфигурирован использовать его в команде HELO. Тогда нужны следующие записи:
; основная SPF-запись
example.com. IN TXT "v=spf1 mx a ~all"
; SPF-запись для HELO
mail.example.com. IN TXT "v=spf1 a -all"
; SPF-запись экранирующая www.example.com (при условии что это имя не каноническое и не используется в HELO)
www.example.com. IN TXT "v=spf1 -all"
; экранирующий SPF-wildcard
*.example.com. IN TXT "v=spf1 -all"
совсем в идеале вместо
example.com. IN TXT "v=spf1 mx a ~all"лучше использовать
example.com. IN TXT "v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 ~all"Но лучше отправить информацию, включая логи на адрес postmaster@corp.mail.ru.
Если кратко — основные проблемы ARC в том, что
1. он требует установления доверия ко всей подписывающей цепочке. Каких-либо способов установления такого доверия сам стандарт не дает. Это планируется решать за счет включения модерируемого списка «доверенных» форвардеров в основные продукты, поддерживающие ARC. По этой причине ARC мало кому помогает и не является полноценной замной используемых сейчас списков доверенных форвардеров и совсем никак не помогает администраторам небольшого списка рассылки, например — т.к. алгоритм попадания в публикуемые списки не известен, а без него ARC бесполезен.
2. Используемый алгоритм цепочки подписей в ARC бесполезен, т.к. нужен для транзитивного доверия (как в цепочке сертификатов, например), которого в ARC нет, поэтому вся эта цепочка не имеет смысла, было бы достаточно только подписи последнего
хоста в цепочке.
3. ARC добавляет очень много информации к заголовкам сообщений. Это может привести к проблемам во многих MTA, где есть ограничения на размер заголовка.
Но, разумеется, если ARC будет внедрен и будет поддерживаться основными MTA/менеджерами списков рассылки, мы так же реализуем его поддержку.
DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
Соответственно, SPF не защищает письма от подделки. Совсем. SPF это протокол аутентификации почтового сервера на уровне транспорта (SMTP), он вобще не смотрит в содержимое письма и в поле From: в частности. Например, домен bob.com имеет строгую SPF-политику. У атакующего есть домен alice.org, который он контролирует. Атакующий может отправить письмо
EHLO alice.org
MAIL FROM: <m@alice.org>
RCPT TO: <some@example.com>
DATA
From: <g@bob.com>
Subject: hello
hello
.
и письмо успешно пройдет SPF-аутентификацию, т.к. SPF проверяет адрес конверта (m@alice.org), но получатель увидит содержимое From:, т.е. g@bob.com.
Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.