У меня Postfix работает на машине Debian 9, и я установил opendkim (оба из репозиториев Debian). Сокет / соединение milter - inet: localhost: 8892, и межсетевой экран iptables разрешает это соединение (a telnet localhost 8892 успешно).
Однако я получаю подписанные сообщения только в том случае, если отправляю электронное письмо с консоли (с mail -s "testing DKIM" my-address@not-the-same-domain), но не, если я пришлю его из Thunderbird. Обратите внимание: в Thunderbird я использую ssh-туннелирование, чтобы почтовый сервер видел, что соединение исходит от localhost. (то есть на своем рабочем столе я запускаю ssh -Llocalhost:2525:my-server:25 tunnel@my-server, и я сообщаю Thunderbird, что сервер исходящей почты - это localhost, порт 2525.
Это пример подписи, которую я получаю при отправке с консоли:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=[omitted -- but it shows the correct domain];
s=mail; t=1557228588;
bh=slJTHzrIw+6TkIIPpFmGER34xtLwMLZ2md99gvHoFTE=;
h=To:Subject:Date:From:From;
b=jtOM5OOM83l [ ··· several lines of "gibberish" ··· ] 4qdpSt4l86DEA==
Любые идеи о том, что может вызвать эту проблему?
[[РЕДАКТИРОВАТЬ]] Проблема становится все более загадочной. Изучая логи, я заметил предупреждение external host XXXX.my-service-provider.com попытался отправить как my-domain.com
Я скорректировал /etc/hosts, /etc/hostname ... Наконец я понял, что мне нужно настроить обратный поиск DNS, и я сделал это. Теперь команда hostname отвечает FQDN (правильный домен, для которого я настраиваю DKIM).
Сейчас в /var/log/syslog когда я отправляю электронное письмо, я получаю сообщение external host *the-correct-FQDN* attempted to send as *the-correct-FQDN*. А переданное сообщение не содержит DKIM-подписи.
Если я сделаю telnet localhost 25, поприветствуйте SMTP-сервер с помощью helo the-correct-FQDN, сообщение подписано DKIM; журналы показывают, что соединение с localhost (127.0.0.1) отвечал за передачу.
Любые идеи?
[[КОНЕЦ РЕДАКТИРОВАНИЯ]]
Аналогичная проблема и контекст: использование openDKIM с Postfix в качестве MTA, который затем является ретранслятором только для аутентифицированных почтовых пользовательских агентов (MUA), более поздний подсчет, в частности, клиентов MS-Outlook, настроенных с подключениями SMTP + POP или SMTP + IMAP к Postfix MTA через TLS / SSL + SASL (аутентификация с логином и паролем) через порт 587 в моем случае.
Когда используется локальная консоль mailx или sendmail, интеграция openDKIM контролируется через non_smtpd_milters вариант в постфикс / main.cf, в то время как smtpd_milters опция действительно контролировать случай входящих сообщений электронной почты SMTPD от аутентифицированных MUA. Итак, сначала вам может потребоваться проверить, что оба параметра выровнены, например лайк
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
Затем, когда действительная подпись DKIM создается для локальных сообщений электронной почты (через mailx или sendmail), но не для сообщений электронной почты от аутентифицированных MUA, это, скорее всего, проблема с определением отправителя сообщения и тем самым предотвращением openDKIM для сканирования в домен "От:", для которого настроена подпись. Вероятно, вы нашли такие следы, как:
opendkim[9530]: E3B6A13CBED: can't determine message sender;
что в моем случае произошло из-за вмешательства в header_checks вариант в Postfix. Ищите его в main.cf или master.cf (который может переопределять параметры в main.cf), например
-o header_checks=regexp:/etc/postfix/submission_header_cleanup
и убедитесь, что связанные правила очистки заголовка будут НЕ содержать регулярное выражение вроде:
/^Received:/ IGNORE
которые вы должны затем закомментировать или удалить.
Наконец, убедитесь постфикс / main.cf сообщит Postfix передать достаточно данных в opendkim через протокол milter с опцией вроде:
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_type} {auth_authen}
Оказывается, проблема была вызвана отсутствием параметра InternalHosts. Для текущей версии opendkim в Debian 9 (2.11) я решил это следующим образом:
Отредактированный файл /etc/opendkim.conf и добавил следующую строку:
InternalHosts file:/etc/opendkim-trustedhosts.conf
Затем файл /etc/opendkim-trustedhosts.conf содержит:
127.0.0.1
x.x.x.x (the actual public IP of the server)
И вуаля --- перезапустите, и проблема устранилась!
Некоторые различия я заметил относительно другая информация, которую я нашел там --- из того, что я мог видеть, в CentOS (не уверен, более старые версии или все еще такие), конфигурация по умолчанию: есть каталог etc/opendkim, а внутри этого каталога, среди прочего, находится файл TrustedHosts.conf; файл /etc/opendkim.conf уже есть InternalHosts директива, указывающая на файл TrustedHosts. В Debian 9 его нужно создавать вручную.