~10^-28 вероятность что произойдет хотя бы одна коллизия между любыми файлами. 10^-38 это коллизия для конкретного файла. Какого либо заметного влияния birthday paradox здесь нет.
Она не работает при такой большой разности множеств (2^34 vs 2^160). В статье о парадоксе есть табличка. Там к сожалению нет значений подохящих для SHA-1 (160 бит), на 128 битном хеше на 26 миллиардах файлов вероятность коллизии 10^-18.
Для 160-битного хэша и 12 миллиардов файлов можно оценить вероятность коллизии сверху примерно как 10^-38.
На самом деле на текущий момент нет известных публично вычисленных примеров коллизии самого SHA-1, есть примеры коллизии для инициализирующих векторов на функцию компресии (SHA-1 freestart collision). Вероятность что на 12млрд файлах произойдет случайная коллизия менее 10^-38.
sha-1 имеет длину 160 бит. При наличии 12 000 000 000 файлов, чтобы случайным перебором наткнуться на файл, надо перебрать порядка 10^38 (2^120) комбинаций.
На самом деле то же самое происходит и в почте, хотя и не настолько очевидно. Yahoo и AOL дали толчок DMARCу, без них он остался бы мертвым стандартом, а Google и Microsoft сейчас сильно завинчивают гайки для писем без аутентификации отправителя.
Это совсем не так. W3C занимается стандартизацией HTML и связанных стандартов. Стандартизацией почтовых протоколов и стандартов занимается IETF, где есть несколько рабочих групп. Например, прямо сейчас идет очень активная работа в рабочих группах ietf-dkim/ietf-dmarc, где обсуждается расширение DKIM для защиты от replay-атак и внедрение ARC а в рабочей группе ietf-dane, например, обсуждается SMTP STS.
Во-первых, почему это XML утратил актуальность? XML тяжеловесный стандарт, поэтому для AJAX может быть и выгодней JSON, но у JSON есть проблемы реализаций из-за недостаточно четких стандартов и отсутствует язык описания схем, у YAML или BSON вообще нет стандартизации какой-либо признанной организацией. У XML есть язык описания схемы и он разрабатывается W3C, что позволяет его использовать в стандартах. Мне XML на текущий момент кажется единственным возможным вариантом.
Во-вторых спецификация DMARC позволяет расширять форматы и добавить другие методы при необходимости.
В статье есть немного рекомендаций по этому поводу.
Для отдельных отчетов можно использовать https://dmarcian.com/dmarc-xml/
для организации процесса обработки в целом удобно использовать либо сервис, который тот же Dmarcian представляет по подписке (есть бесплатные подписки для небольших объемов почты) либо его аналоги. Мы пользуемся услугами Agari.
Бесплатных готовых инструментов пока не встречалось.
А накопительное обновление 6 стоит? Если да, то покажите полный текст сообщения о невозможности доставки (с заголовками исходного сообщения), можно в личку.
Это немного неправильные впечатления. E-mail очень активно активно развивается и пользоваться им вполне можно. Текущая версия SMTP (RFC 5321) и формата письма (RFC 5322) — 2008й год, DKIM — 2011й год (RFC 5376), DMARC (RFC 7489) — 2015й год и крупные операторы не просто не стоят в стороне, они как раз и участвуют в разработках этих стандартов. DMARC в той или иной степени, хотя бы в режиме none есть у всех почтовых сервисов.
Проблема в другом. Очень мало кто из администраторов знаком с новыми технологиями почты. 100% администраторов с которыми приходилось общаться уверены, что SPF должен защищать почту от подделок (что абсолютно не соответствует действительности). Как заставить, например, крупные российские банки внедрить SPF, DKIM и DMARC, которых там как правило нет, при том что в штатах DMARC есть практически у всех крупных финансовых организаций? Мы на себя взяли задачу — продвинуть технологию среди администраторов. И уже есть определенные успехи.
Пересылка обычно работает без проблем при наличии DKIM-подписи в письме. Проблемы встречаются, например в Hotmail/Outlook т.к. на части пересылаемых писем бьется DKIM, что приводит к нарушению DMARC, Microsoft обещает эту проблему устранить. Аналогичная проблема есть в устаревших и уже не поддерживаемых версиях Exchange.
Со списками рассылки действительно бывают проблемы, но большая часть крупных списков уже умеют обнаруживать домены с DMARC и делать для них замену From. Строгий DMARC уже есть у yahoo.com, aol.com, mail.ru, Microsoft обещал внедрить на outlook/hotmail до конца года, GMail так же анонсировал внедрение, поэтому списки рассылки вынуждены адаптироваться. Если это действительно необходимо, можно выделить отдельный поддомен с более мягкой политикой специально для постинга в списки рассылки.
У пользователя выразившего нежелание получать рассылку она несомненно будет попадать в спам. Пользователь ожидает что при отказе от подписки он не будет больше получать писем. Но это не затронет прохождение рассылки другим пользователям, пока показатели рассылки остаются в пределах нормы.
Само по себе нажатие на unsubscribe, даже неоднократное, не приведет к попаданию хорошей рассылки в спам. Если у вас большой процент «контрагентов» получил рассылку, которую не хочет получать, то очевидно, что утверждение «среди которых незаинтересованных людей нет» неверно.
1. Учитывается результат проверки при условии соответствия доменов. Т.е. если во From домен example.com, то SPF или DKIM для домена example.org не будет учитываться в DMARC, т.к. это разные организационные домены.
2. Совершенно верно, но при условии выполнения п.1
3. Да, сравнивается домен из d= или i=
4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
Мне кажется, ответ очевиден: эскалировать проблему непосредственному руководству. На самом деле, администратор уже совершил серьезную ошибку, т.к. должен был это сделать, как только такая ситуация стала вероятной. А еще раньше ошибку допустил CTO, т.к. очевидно отсутствуют регламенты по действиям в аварийных ситуациях и отсустствуют правила эскалации проблемы (обычно если проблема, серьезно влияющая на бизнес-процессы не решается в течении какого-либо времени, она эскалируется на следующую ступень технического, а затем исполнительного руководства).
Мы часто на собеседовании тестировщикам (!) задаем такой вопрос: вы задержались в офисе после работы, когда остальные сотрудники уже ушли и ваш рабочий день тоже кончился. Вы случайно обнаруживаете «в бою» серьезную ошибку, которая делает использование сервиса невозможной для пользователей. Каковы ваши действия?
Очень многие кандидаты в тестировщики бросаются грудью на амбразуру разбирать и править код, кто-то отвечает что раз рабочий день кончился — надо ждать до завтра, кто-то бросается документировать ошибку. Позвонить непосредственному руководителю, даже после намеков догадывается менее половины кандидатов.
В моей истории это был совсем не юный парень, наоборот специалист с еще советской закалкой. Или вы о Владимире Габриеляне? Он успешно преодолел, мне кажется.
Это была небольшая компания, без какой-либо внутренней бюрократии, а склад был просто физическим помещением куда надо сходить и взять (спросив у коллег где лежит).
Странные у вас менеджеры, мне такие не попадались. Но если с вами всегда так поступают, может быть проблема все-таки в вас?
Для 160-битного хэша и 12 миллиардов файлов можно оценить вероятность коллизии сверху примерно как 10^-38.
Во-вторых спецификация DMARC позволяет расширять форматы и добавить другие методы при необходимости.
Для отдельных отчетов можно использовать https://dmarcian.com/dmarc-xml/
для организации процесса обработки в целом удобно использовать либо сервис, который тот же Dmarcian представляет по подписке (есть бесплатные подписки для небольших объемов почты) либо его аналоги. Мы пользуемся услугами Agari.
Бесплатных готовых инструментов пока не встречалось.
Проблема в другом. Очень мало кто из администраторов знаком с новыми технологиями почты. 100% администраторов с которыми приходилось общаться уверены, что SPF должен защищать почту от подделок (что абсолютно не соответствует действительности). Как заставить, например, крупные российские банки внедрить SPF, DKIM и DMARC, которых там как правило нет, при том что в штатах DMARC есть практически у всех крупных финансовых организаций? Мы на себя взяли задачу — продвинуть технологию среди администраторов. И уже есть определенные успехи.
Со списками рассылки действительно бывают проблемы, но большая часть крупных списков уже умеют обнаруживать домены с DMARC и делать для них замену From. Строгий DMARC уже есть у yahoo.com, aol.com, mail.ru, Microsoft обещал внедрить на outlook/hotmail до конца года, GMail так же анонсировал внедрение, поэтому списки рассылки вынуждены адаптироваться. Если это действительно необходимо, можно выделить отдельный поддомен с более мягкой политикой специально для постинга в списки рассылки.
2. Совершенно верно, но при условии выполнения п.1
3. Да, сравнивается домен из d= или i=
4. Да, сравнивается домен из RFC5321.From (при пустом From используется домен из RFC5321.Helo). Return-Path не совсем то же самое, это заголовок который добавляется в сообщение при доставке в ящик конечного пользователя, как правило (но не обязательно) он так же содержит RFC5321.From.
5. Достаточно чтобы была хотя бы одна валидная DKIM-сигнатура соответствующая домену из RFC5322.From. Сигнатуры от других доменов и невалидные сигнатуры никак не влияют. Правда бывают ошибки реализации, например мы засабмитили такой патч в exim (можно за него проголосовать).
Мы часто на собеседовании тестировщикам (!) задаем такой вопрос: вы задержались в офисе после работы, когда остальные сотрудники уже ушли и ваш рабочий день тоже кончился. Вы случайно обнаруживаете «в бою» серьезную ошибку, которая делает использование сервиса невозможной для пользователей. Каковы ваши действия?
Очень многие кандидаты в тестировщики бросаются грудью на амбразуру разбирать и править код, кто-то отвечает что раз рабочий день кончился — надо ждать до завтра, кто-то бросается документировать ошибку. Позвонить непосредственному руководителю, даже после намеков догадывается менее половины кандидатов.
Странные у вас менеджеры, мне такие не попадались. Но если с вами всегда так поступают, может быть проблема все-таки в вас?