Я последовал за эти инструкции для установки OpenDKIM с Postfix, и он работает как рекламируется. В мои исходящие письма добавлен заголовок DKIM-Signature, например:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=mail;
t=1398638300; bh=mk/7yYUxFCWz+ZHB0opJIA/S3J5ELoPZPfAO0KQdVg4=;
h=Date:From:To:Subject:From;
b=fPPfUliJUgA0re38nkJ2R18TeFgbamOv1U8nDb9958eTeAT6Mp7oq4WGrHPiPmc+b
mrLu9RuW0/S4d0ipkilNZDxgecwl7qttrDbTEkWxdhwwTSe5FL3OBaUoUxJFrMGjmY
RdBjY5ZWtvk29+gXZ+af5Of9OrY7COLlqGkFXRXw=
Мой вопрос о d= параметр выше. В случаях, когда один почтовый сервер обрабатывает исходящую почту нескольких виртуальных доменов, должен ли d = содержать почтовый сервер, отправляющий сообщение? Или это должен быть домен, который отображается в адресе От:?
Я пытался читать RFC 6376 по этому поводу, но я нашел только один важный момент:
d= The SDID claiming responsibility for an introduction of a message
into the mail stream [...] The conventions and semantics used by a Signer to
create and use a specific SDID are outside the scope of this specification
Я надеюсь, что кто-то здесь знает, как параметр d = используется на практике.
Вы смотрите на вопрос не с той точки зрения - с точки зрения отправителя. Вы должны смотреть на это с точки зрения получателя.
Допустим, у нас есть person@foo.com, который отправляет нам сообщение через почтовый сервер 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 подпись из домена отправителя является наиболее надежной и может требоваться политиками электронной почты отправителя. С введением DMARC теперь домены могут публиковать политику с желаемыми действиями для электронной почты, которая не соответствует политике.
DKIM предназначен для сопоставления отправителя из заголовка, который может не быть отправителем конверта. SPF проверяет разрешение отправителя конверта на отправку почты для домена с помощью отправляющего сервера. DMARC связывает их вместе, чтобы обеспечить лучшую политическую основу.
Все три механизма требуют, чтобы данные были опубликованы в дереве DNS соответствующего домена.
DKIM от третьей стороны просто указывает, был ли подписанный контент изменен после подписания этими доменами. Это может быть полезно для отказа, но не для репутации отправителя.
DKIM основан на домене. Он говорит только о домене подписи электронного письма. Если вы используете d = esp.com, который является доменом поставщика услуг электронной почты, тогда принимающая почтовая система будет использовать репутацию esp.com для принятия решения об электронной почте. И если используется d = customer.com (например, домен для адреса From:), то будет использоваться оценка репутации customer.com. Итак, если esp.com имеет высокую репутацию, было бы разумно использовать d = esp.com. В противном случае используйте d = customer.com.
Из RFC 8376 стандарт:
После проверки подписи эта информация ДОЛЖНА быть передана Оценщику идентификации (например, явное разрешение / белый список и система репутации) и / или конечному пользователю. Если SDID не совпадает с адресом в поле заголовка From :, почтовой системе СЛЕДУЕТ приложить все усилия, чтобы убедиться, что фактический SDID понятен читателю.
SDID: идентификатор домена подписи (= d)
ОБНОВИТЬ:
Подробнее о подписи на основе автора и подписи третьей стороны от dkim.org spec:
Подпись, домен которой не совпадает с доменом адреса RFC5322.From, иногда называется подписью третьей стороны. ... Хотя о ценности подписей третьих лиц часто идут жаркие споры ...
Для некоторых подпись, не связанная с доменом автора (домен в адресе RFC5322.From), менее ценна, поскольку предполагается, что наличие подписи автора гарантирует, что использование адреса в заголовке RFC5322.From разрешено. .
Для других эта релевантность строго привязана к записанным поведенческим данным, присвоенным рассматриваемой личности, то есть ее оценке доверия или репутации ... Следовательно, облегчение доставки сообщений, содержащих действительную подпись домена с сильная положительная репутация, независимо от того, связан ли этот домен с адресом в поле заголовка RFC5322.From сообщения.
Просматривая несколько писем из Gmail, я обнаружил d параметр, содержащий домен отправителя конверта. Итак, адрес, используемый в MAIL From Команда SMTP используется в d параметр.
Я не могу придумать другого способа определения домена, который имел бы больше смысла, чем использование отправителя конверта.