Наш адрес электронной почты подделывают. У нас уже есть политики SPF / DKIM / DMARC p = "quarantine", однако мы все еще получаем тысячи уведомлений о недоставке (NDR) в нашем почтовом ящике.
Будет ли изменение на DMARC p = "reject" предотвращать обратное рассеяние отчетов о недоставке?
Любой другой совет, как предотвратить обратное рассеяние NDR?
Примечание. Мы используем электронную почту, размещенную на OpenSRS.
DMARC не является решением против обратного рассеяния, и p=reject на самом деле может вызвать больше обратного рассеяния в качестве побочного эффекта на серверах, отправляющих уведомления о недоставке (NDR) вместо использования отказ на этапе подключения во время SMTP-соединения. Вся проблема обратного рассеяния вызвана плохой конфигурацией принимающего MTA или промежуточного MTA. Даже если бы у DMARC было решение для этого, такие администраторы не были бы первыми, кто его принял.
С другой стороны, DMARC предлагает возможность получать Отчеты об отказах (ruf=), что может привести к огромным объемам криминалистических данных. Для этого рекомендуется иметь полностью разделенный адрес, и данные лучше всего пересылать куда-нибудь, где анализ можно автоматизировать.
Возможные способы борьбы с обратным рассеянием включают:
Message-Id возвращенного сообщения соответствует вашему шаблону идентификатора сообщения.И прежде всего: настройте свои собственные SMTP-серверы таким образом, чтобы они не отправляли отчеты о недоставке на возможно поддельные обратные адреса: Используйте отказ на этапе подключения сразу после неудачной проверки получателя или проверки на подделку и т. д. Отчет о недоставке будет создан для локального пользователя на отправляющем MTA.
Я понимаю, что это запоздалый ответ.
DMARC, как указано, не может предотвратить обратное рассеяние ... но это не конец истории.
SPF, DKIM и DMARC уменьшили обратное рассеяние, если они реализованы на принимающих серверах, поэтому проблема меньше, чем была. Однако мы не можем предположить, что люди будут применять какие-либо из этих методов.
@Esa - ваш комментарий об отказе от создания отчета о недоставке для нелокальных пользователей будет означать, что если кто-то установит реле, не отвечающее за окончательную доставку, ни один отправитель никогда не получит отчет о недоставке. Это происходит часто по уважительным причинам - разделение границы почты (или spamwall) от хранилища почтовых ящиков, как правило, хорошо (IMHO), а также позволяет гораздо более гибкую обработку. Я не думаю, что это жизнеспособное решение проблемы обратного рассеяния.
Конечно, вы правы в том, что DMARC не останавливает обратный разброс, поскольку отчет о недоставке является отдельным сообщением от исходного поддельного сообщения, тогда сообщение о недоставке вполне может соответствовать любой политике DMARC для домена, отправляющего отчет о недоставке. Однако, поскольку отчет о недоставке содержит исходные заголовки сообщения, информация в этих заголовках об исходном электронном письме может использоваться для определения обратного рассеивания.
Раньше был доступен фильтр milter под названием milter-null, который вставлял вычисленный заголовок в исходящие сообщения и проверял тот же заголовок в заголовках сообщений в отчете о недоставке. Если его там не было, он блокировал сообщение о недоставке. Этот метод полезен только в том случае, если получающий почтовый сервер знает о заголовках, вставленных все исходящих серверов, и я думаю, что miilter-null работает только тогда, когда один и тот же сервер обрабатывает всю исходящую и входящую почту. Он больше не доступен (я думаю, что это было от snertsoft), хотя вы можете найти источник где-нибудь при постоянном поиске.
Мы рассматриваем возможность реализации решения, использующего исходные заголовки сообщений в отчете о недоставке для реализации DMARC, как это должно было быть реализовано на принимающем сервере. Конечно, это не входит в сферу применения DMARC, и хотя мы видим некоторые слабые стороны этого подхода *, это лучший план, который мы нашли для блокировки обратного рассеяния. Мы еще этого не сделали, но, возможно, кто-то другой уже реализовал решение.