Я заметил, что я не получаю в Gmail и Яндекс.Почте определенные письма, пересылаемые через системы UNIX (без SRS - не слишком уверены, что схема перезаписи отправителя по-прежнему является лучшей практикой? Потому что с DMARC, я думаю, его также нужно будет применить к фактическим From: заголовок в самом письме.) от отправителей с поддержкой DMARC.
Я не могу понять, что происходит - письма, которые всегда проходят, включают PayPal.com, тогда как Microsoft.com и некоторые другие отклоняются (доставляются только локально в системы, которые не реализуют DMARC на принимающей стороне).
% echo _dmarc.{microsoft.com,paypal.com} | xargs -n1 dig -t txt | fgrep v=D
_dmarc.microsoft.com. 3302 IN TXT "v=DMARC1\; p=reject\; pct=100\; rua=mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com\; fo=1"
_dmarc.paypal.com. 3311 IN TXT "v=DMARC1\; p=reject\; rua=mailto:d@rua.agari.com\; ruf=mailto:d@ruf.agari.com"
%
Когда оба домена имеют одинаковые reject политика - и Google даже особо отмечает, что у PayPal есть четкая политика отказа. - Я не совсем уверен, что что-то не так в моей собственной настройке или виновата отправляющая сторона. Любые идеи?
Это просто из-за сбоя SPF по сравнению с softfail, или это еще не все?
% echo {microsoft.com,paypal.com} | xargs -n1 dig -t txt | fgrep v= | sed 's#[^[:space:]]*:[^[:space:]]*#:#g'
microsoft.com. 3332 IN TXT "v=spf1 : : : : : : : : : : -all"
paypal.com. 300 IN TXT "v=spf1 : : : : : : ~all"
%
Вот что Gmail сообщает для писем PayPal, которые действительно доставляются через пересылку:
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@mail.paypal.com header.s=pp-epsilon1 header.b=K96c6GUZ;
spf=fail (google.com: domain of bounce@mail.paypal.com does not designate 2001:470:7240:: as permitted sender) smtp.mailfrom=bounce@mail.paypal.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=paypal.com
Return-Path: <bounce@mail.paypal.com>
Мне кажется, что причиной мог быть «полный провал» Microsoft SPF. Если в принимающей системе есть механизм для принудительного применения ОБЕИХ SPF и DMARC, то «жесткий сбой» SPF приведет к сбою этого сообщения, даже если DMARC передаст его из-за прохода DKIM. Помните, что SPF - это отдельная вещь, которая существовала до DMARC. Однако одна из проблем с его использованием заключалась в том, что не существовало стандарта для принимающих систем в том, как интерпретировать «мягкий сбой» и «жесткий сбой». Итак, получатели были сами по себе, чтобы решить, что делать с обоими. Microsoft может по-прежнему использовать SPF для входящей почты и может отбрасывать сообщения, которые оцениваются как «полный сбой». Paypal использует «мягкий сбой», который можно интерпретировать как недостаточно важный для блокировки с помощью механизма SPF. Оба могут быть оценены DMARC, но проверка SPF может уничтожить сообщения до того, как DMARC сможет их передать.
Политика DMARC защищает домен, используемый в From: заголовок: чтобы пройти проверку DMARC, необходимо выровнять либо с DKIM, либо с SPF. Для SPF это требует соответствия отправитель конверта (т.е. Return-Path т.е. адрес, используемый в SMTP MAIL FROM команда) с пройденным тестом SPF.
В DMARC пересылка почты (без ведома конечного сервера) в любом случае вызовет проблемы:
From: адрес больше.Пример сообщения от PayPal успешно проходит тест DMARC, потому что он имеет действительную подпись DKIM, которая также соответствует From заголовок. Поскольку ошибка для других доменов была стандартным отклонением DMARC, мы можем предположить, что в сообщениях либо отсутствует действительная подпись DKIM, либо она не согласована с From заголовок.
Единственный выход - это доверять тому, что сервер пересылки уже проверил SPF, DKIM и DMARC, и слепо принимать каждое сообщение, приходящее с этого сервера. Вот как это делается в стандартной конфигурации первичного / вторичного MX для сообщений, поступающих через вторичный сервер, и как это должно быть сделано в любом сценарии пересылки, принятом с обеих сторон.
К сожалению, на основании обсуждения в Справочном сообществе Gmail "Могу я отключить DMARC", Gmail не позволяет добавлять исключения для тестов DMARC. Вывод: не пересылать на Gmail.
На самом деле здесь действуют 2 правила. Один из них - это политика жесткого отказа для Microsoft SPF, и поскольку вы не меняете envelope.from адрес, Gmail может просто отказаться от него на основе SPF.
Чтобы решить эту проблему, было бы разумно переписать envelope.from a.k.a return-path. Однако это нарушает выравнивание, необходимое для прохождения DMARC на основе SPF. Итак, вам остается DKIM, чтобы получить этот ПРОПУСК.
В сценариях пересылки такая ситуация иногда упоминается как "DKIM Выживание", поскольку соответствие DMARC основано на том, насколько хорошо DKIM-подпись сохраняется при пересылке. Выжившие серверы пересылки во многом зависят от того, какие поля заголовка изменяет сервер пересылки или удаляет ли он исходную подпись (и при необходимости заменяет ее собственной).
В вашем случае подпись DKIM сообщения PayPal остается в силе при пересылке. В другом месте в заголовках этого электронного письма вы можете найти информацию о самой подписи DKIM и, в частности, о полях, которые были подписаны. В зависимости от типа электронного письма, которое вы получаете от Microsoft (маркетинг, опрос и т. Д.), Это, скорее всего, подписанные поля заголовка: h=From:To:Subject:Date:MIME-Version:Reply-To:List-ID:Message-ID:Content-Type; Важно понимать, каких полей ваша система затрагивает при пересылке сообщений. Вот ссылка на RFC для DKIM, который рекомендует, какие заголовки на самом деле подписывать: https://tools.ietf.org/html/rfc4871#section-5.5
И еще есть ARC (для цепочки подтвержденных полученных данных). Он все еще находится на стадии черновика, но обычно крупные провайдеры почтовых ящиков, такие как Google, довольно быстро внедряют это новое руководство. У DMARC Analyzer есть хорошее описание того, что он делает: https://www.dmarcanalyzer.com/arc-is-here/
Я надеюсь, это поможет вам.