Мы запускаем небольшую службу электронной почты (не массовую отправку) (около 300 доменов) для наших клиентов и только начинаем внедрять DMARC. Одна из причин для этого - помочь остановить обратное рассеяние (отчеты о недоставке для электронных писем, которые не были отправлены), помогая нам определить, когда отчеты о недоставке предназначены для обратного рассеивания.
Мы не можем помешать людям подделывать адреса электронной почты, которые мы размещаем, и мы не можем заставить другие системы правильно внедрять SPF, DKIM и DMARC, но мы хотим иметь возможность идентифицировать ответ обратного рассеивания.
Теоретически, если мы получаем отчеты о недоставке, тогда к отчету о недоставке следует прикреплять исходные заголовки сообщений, чтобы мы могли проверить их, чтобы увидеть, была ли отправлена подмена. Таким образом, идея состоит в том, чтобы переквалифицировать исходные заголовки сообщений с учетом SPF, DKIM и DMARC, а также, если исходная система NDR должен поместили сообщение в корзину, тогда мы можем сохранить его.
Я просматривал одно такое сообщение, которое было получено в тестируемом нами домене, который страдает от множества спуфингов. Политика DMARC для рассматриваемого домена:
"v=DMARC1; p=reject; aspf=s; adkim=s"
Соответствующие заголовки электронной почты (анонимные) в отчете о недоставке:
Received: from h2773125.stratoserver.net (h2773125.stratoserver.net [81.169.157.174])
by mailboundary.domainundertest.tld (8.14.7/8.14.7) with ESMTP id x65BOdv8028405
for <user@domainundertest.tld>; Fri, 5 Jul 2019 11:24:44 GMT
DMARC-Filter: OpenDMARC Filter v1.3.2 mailboundary.domainundertest.tld x65BOdv8028405
Authentication-Results: mailboundary.domainundertest.tld; dmarc=none (p=none dis=none) header.from=h2773125.stratoserver.net
На данный момент это верно - отчет о недоставке исходит от целевой системы, получившей ложное сообщение, поэтому отчет о недоставке (это сообщение) проходит.
В сообщении о недоставке указано несколько учетных записей электронной почты в разных доменах, которые отклоняются. Это может указывать на то, что система, генерирующая отчет о недоставке, является открытым ретранслятором и, если это так, вероятно, неправильно настроена или, возможно, специально настроена спамерами. Конечно, если это было настроено специально спамерами, то они не будут заботиться о том, чтобы не создавать обратного рассеивания!
В заголовках исходного сообщения перечислено только следующее:
Return-Path: <user@domainundertest.tld>
Received: from 92.119.160.85 (unknown [113.163.187.18])
by h2773125.stratoserver.net (Postfix) with ESMTPSA id DEC718656E;
Sat, 29 Jun 2019 22:54:56 +0000 (UTC)
Message-ID: <a77f25767d56838fa91caaf90dc8323e07995fd8@domainundertest.tld>
Reply-To: "CestusKaput96368" <some_apparently_throwaway_address@yahoo.com>
From: "CestusKaput96368" <user@domainundertest.tld>
Subject: Ich bin ein boses Madchen und muss bestraft werden.
Date: Sun, 30 Jun 2019 01:54:59 +0300
MIME-Version: 1.0
Content-Type: text/plain
Это все заголовки ... но достаточно, чтобы это заблокировать.
Мы видим, что исходящий конверт (Return-Path) исходит из домена, который мы пытаемся защитить, и у нас есть IP-адрес, с которого он был отправлен (113.163.187.18), поэтому мы можем проверить SPF - он не будет работать. Поскольку у нас есть политика aspf=s сервер, отправивший отчет о недоставке, должен был сохранить сообщение, чтобы мы могли сохранить отчет о недоставке.
Итак, что мы хотим сделать, так это реализовать нашу собственную проверку DMARC для сообщений NDR на основе исходных заголовков.
Кто-нибудь знает об инструменте с открытым исходным кодом для этого? Мы могли бы написать собственный milter на C или Perl, если нужно, но я подумал, что может быть что-то уже существует.
Приветствуются любые мысли и мнения!