Вопросы Теги

Пересылка в Gmail не работает для писем от Microsoft.com из-за DMARC, но работает для PayPal.com

Я заметил, что я не получаю определенные электронные письма в моем 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"
%

Когда оба домена имеют sam e отклонить политику - и Google даже специально упоминает, что PayPal действительно имеет окончательную политику отклонения - я не совсем уверен, что-то не так в моей собственной настройке или это отправка партия виновата. Есть идеи?

Это просто из-за сбоя SPF или программного сбоя, или есть еще кое-что? 

% 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>
2
задан 15 September 2019 в 23:08
3 ответа

Политика DMARC защищает домен, используемый в заголовке From: : для прохождения проверки DMARC он должен согласовать либо с DKIM, либо с SPF. Для SPF требуется соответствующий отправитель конверта (то есть Return-Path , то есть адрес, используемый в команде SMTP MAIL FROM ) с пройденным тестом SPF.

В DMARC пересылка почты (без ведома конечного сервера) вызовет проблемы в любом случае:

  • Если вы не измените отправителя конверта , вы не передадите Проверка SPF и
  • , если вы его измените, он больше не будет соответствовать адресу From: .

Пример сообщения от PayPal успешно проходит тест DMARC, поскольку он имеет действительный Подпись DKIM, которая также соответствует заголовку From . Поскольку ошибкой для других доменов было стандартное отклонение DMARC, мы можем предположить, что в сообщениях либо отсутствует действительная подпись DKIM, либо она не согласована с заголовком From .

Единственным выходом будет доверие. что сервер пересылки уже проверил SPF, DKIM и DMARC и слепо принимает каждое сообщение, приходящее с этого сервера. Вот как это делается в стандартной конфигурации первичного / вторичного MX для сообщений, поступающих через вторичный сервер - и как это должно быть сделано в любом сценарии пересылки, принятом с обеих сторон.

К сожалению, на основе обсуждения Справочного сообщества Gmail на тему " Могу я отключить DMARC ", Gmail не позволяет добавлять исключения для тестов DMARC. Заключение: не пересылайте в Gmail.

1
ответ дан 3 December 2019 в 11:22

Мне кажется, что причиной мог быть "полный отказ" для Microsoft SPF. Если принимающая система имеет механизм для принудительного применения ОБЕИХ SPF и DMARC, то «жесткий сбой» SPF приведет к сбою этого сообщения, даже если DMARC передаст его из-за прохода DKIM. Помните, что SPF - это отдельная вещь, которая существовала до DMARC. Однако одна из проблем с его использованием заключалась в том, что не существовало стандарта для принимающих систем в том, как интерпретировать «мягкий сбой» и «жесткий сбой». Таким образом, получатели были сами по себе, чтобы решить, что делать с обоими. Microsoft может по-прежнему использовать SPF для входящей почты и может отбрасывать сообщения, которые оцениваются как «полный сбой». Paypal использует «мягкий сбой», который может быть интерпретирован как недостаточно важный для блокировки с помощью механизма SPF. Оба могут быть оценены DMARC, но проверка SPF может уничтожить сообщения до того, как DMARC сможет их передать.

1
ответ дан 3 December 2019 в 11:22

На самом деле здесь действуют 2 политики. Один из них - это политика жесткого отказа для Microsoft SPF, и поскольку вы не меняете адрес envelope.from , Gmail может просто отказаться от него на основе SPF.

Чтобы решить эту проблему, было бы разумно перепишите envelope.from он же обратный путь . Однако это нарушает выравнивание, необходимое для прохождения 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/

Надеюсь, это вам поможет.

0
ответ дан 3 December 2019 в 11:22

Теги

Похожие вопросы