Какое доменное имя должно появиться в подписи DKIM?
Я провел свое исследование на том же самом предмете о полгода назад, и я закончил с решением Asigra. Это может сделать ВСЕ, что Вы спрашиваете и т.д. Asigra делает программное обеспечение, но услуга предоставляется независимыми поставщиками услуг и нет никакого дефицита их. Попросите у Asigra направлений или просто Google. Я мог отослать Вас к моему, если Вам нравится (они платят комиссиям за направления, таким образом, я могу заработать или два для того, чтобы сделать это :-).
Существует незначительное раздражение с их решением, что Вы должны будете разделить установки для резервных копий Windows и Linux, но это не грандиозное предприятие, и они могут зафиксировать (или скорее re-inroduce) его в следующей версии.
Это не одно решение для щелчка, потому что это предоставляет столько возможностей, и будет требоваться некоторое понимание резервных копий. Вы звучите хорошо осведомленными, таким образом, я предполагаю, что это не была бы проблема :-). После того как это установлено, это просто работает. Кроме того, это обеспечивает скорее усовершенствованное создание отчетов, полезное для анализа тенденции и планирования мощностей.
Надеюсь, это поможет.
Подпись DKIM из домена отправителя является наиболее надежной и может требоваться политиками электронной почты отправителя. С введением DMARC теперь домены могут публиковать политику с желаемыми действиями для электронной почты, которая не соответствует политике.
DKIM предназначен для сопоставления отправителя из заголовка, который может не быть отправителем конверта. SPF проверяет разрешение отправителя конверта на отправку почты для домена с помощью отправляющего сервера. DMARC связывает их вместе, чтобы обеспечить лучшую основу политики.
Все три механизма требуют, чтобы данные были опубликованы в дереве DNS соответствующего домена.
DKIM от третьей стороны просто указывает, был ли подписанный контент изменен после подписания этими доменами. Это может быть полезно для отказа, но не для репутации отправителя.
Вы смотрите на вопрос с неправильной точки зрения - с точки зрения отправителя. Вы должны смотреть на это с точки зрения получателя.
Предположим, у нас есть person@foo.com, отправляющее нам сообщение через mailserver random.com. Мы ничего не знаем ни об одном из доменов. О чем-нибудь говорит подпись от foo.com в электронном письме от person@foo.com ? Очевидно, что это так, поскольку foo.com может что-то сказать об учетных записях электронной почты, которые он контролирует. Что вам говорит подпись от random.com в электронном письме от person@foo.com ? Очень мало. random.com может контролироваться спамером, рассылающим спам с адреса person@foo.comчтобы обойти ваши фильтры. Так что, если вы ничего не знаете о random.com, его подпись также ничего не значит.
Также помните, что электронное письмо может содержать несколько подписей DKIM. Итак, если вы запустите список рассылки, сообщение, отправленное в список, может содержать подпись из домена в заголовке From. Список рассылки может также подписать его, используя домен списка, указанный в конверте. Оба предоставляют получателю полезную информацию, помогая ему решить, доверять ли сообщению.
В DKIM не требуется, чтобы значение d = (или соответствующее значение i = ) соответствовало любым другим заголовкам в сообщение. DKIM сам по себе аутентифицирует только подписавшего, а не отправителя, оставляя получателю возможность реализовать некоторую политику, чтобы сделать эту информацию полезной.
DMARC позволяет домену отправителя определять политики для DKIM, что делает подпись DKIM гораздо более полезной для получатель. В DMARC заголовки d = и From: должны соответствовать (либо точно, либо разрешающие субдомены, в зависимости от указанной строгости).
Для OpenDKIM вы захотят посмотреть на директивы конфигурации SigningTable и KeyTable , чтобы правильно работать с несколькими доменами.
DKIM основан на домене. Он говорит только о домене подписи электронного письма. Если вы используете d = esp.com, который является доменом поставщика услуг электронной почты, тогда принимающая почтовая система будет использовать репутацию esp.com для принятия решения об электронной почте. И если используется d = customer.com (например, домен для адреса From:), то будет использоваться оценка репутации customer.com. Поэтому, если esp.com имеет высокую репутацию, было бы разумно использовать d = esp.com. В противном случае используйте d = customer.com
Из стандарта RFC 8376 :
После проверки подписи эта информация ДОЛЖНА быть передано Оценщику идентификации (например, явное разрешение / белый список и система репутации) и / или конечному пользователю. Если SDID не совпадает с адресом в поле заголовка От: почта системе СЛЕДУЕТ позаботиться о том, чтобы действительный SDID был понятен читатель.
SDID: Идентификатор домена подписи (= d)
ОБНОВЛЕНИЕ:
Подробнее о подписи на основе автора и подписи третьей стороны из спецификации dkim.org :
Подпись, чья домен не совпадает с доменом в RFC5322. Адрес from иногда называют сторонней подписью. ... Хотя часто возникают жаркие споры о ценности сторонних подписей ...
Для некоторых подпись, не связанная с доменом автора (домен в адресе RFC5322.From), менее ценна, потому что существует предположение что наличие подписи автора гарантирует, что использование адреса в заголовке RFC5322.From разрешено.
Для других эта релевантность строго привязана к записанным поведенческим данным, присвоенным рассматриваемой личности, то есть ее оценке доверия или репутация ... Следовательно, обеспечение доставки сообщений, содержащих действительную подпись домена с сильной положительной репутацией, является низким риском, независимо от того, связан ли этот домен с адресом в поле заголовка RFC5322.From сообщения.
Просматривая несколько писем от Gmail, я обнаружил, что параметр d содержит домен отправителя конверта. Таким образом, адрес, используемый в SMTP-команде MAIL From , является тем адресом, который используется в параметре d .
Я могу '