После многих тестов и повторения моих шагов я все еще не могу получить почту Google для проверки.
Мой почтовый сервер - Debian 5.0 с exim
Exim version 4.72 #1 built 31-Jul-2010 08:12:17
Copyright (c) University of Cambridge, 1995 - 2007
Berkeley DB: Berkeley DB 4.8.24: (August 14, 2009)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS move_frozen_messages Content_Scanning DKIM Old_Demime
Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
GnuTLS compile-time version: 2.4.2
GnuTLS runtime version: 2.4.2
Configuration file is /var/lib/exim4/config.autogenerated
Конфигурация моего удаленного транспорта smtp:
remote_smtp:
debug_print = "T: remote_smtp for $local_part@$domain"
driver = smtp
helo_data = mailer.mydomain.com
dkim_domain = mydomain.com
dkim_selector = mailer
dkim_private_key = /etc/exim4/dkim/mailer.mydomain.com.key
dkim_canon = relaxed
.ifdef REMOTE_SMTP_HOSTS_AVOID_TLS
hosts_avoid_tls = REMOTE_SMTP_HOSTS_AVOID_TLS
.endif
.ifdef REMOTE_SMTP_HEADERS_REWRITE
headers_rewrite = REMOTE_SMTP_HEADERS_REWRITE
.endif
.ifdef REMOTE_SMTP_RETURN_PATH
return_path = REMOTE_SMTP_RETURN_PATH
.endif
.ifdef REMOTE_SMTP_HELO_FROM_DNS
helo_data=REMOTE_SMTP_HELO_DATA
.endif
Путь к моему закрытому ключу правильный.
Я вижу заголовок DKIM в своих сообщениях, поскольку они попадают в мою учетную запись Gmail:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mydomain.com; s=mailer;
h=Content-Type:MIME-Version:Message-ID:Date:Subject:Reply-To:To:From; bh=nKgQAFyGv<snip>tg=;
b=m84lyYvX6<snip>RBBqmW52m1ce2g=;
Однако заголовки Gmail всегда сообщают, что dkim = нейтральный (без подписи):
dkim=neutral (no signature) header.i=@mydomain.com
Мои результаты DNS:
dig +short txt mailer._domainkey.mydomain.com
mailer._domainkey. mydomain.com descriptive text "v=DKIM1\; k=rsa\; t=y\; p=LS0tLS1CRUdJ<snip>M0RRRUJBUVV" "BQTRHTkFEQ0J<snip>GdLamdaaG" "JwaFZkai93b3<snip>laSCtCYmdsYlBrWkdqeVExN3gxN" "mpQTzF6OWJDN3hoY21LNFhaR0NjeENMR0FmOWI4Z<snip>tLQo="
Обратите внимание, что открытый ключ base64 имеет длину 364 символа, поэтому мне пришлось разбить ключ с помощью bind9.
$ORIGIN _domainkey. mydomain.com.
mailer TXT ("v=DKIM1; k=rsa; t=y; p=LS0tLS1CRUdJTiBQVUJM<snip>U0liM0RRRUJBUVV"
"BQTRHTkFEQ0JpUUtCZ1<snip>15MGdLamdaaG"
"JwaFZkai93b3lDK21MR<snip>YlBrWkdqeVExN3gxN"
"mpQTzF6OWJDN3hoY21L<snip>Ci0tLS0tRU5E"
"IFBVQkxJQyBLRVktLS0tLQo=")
Может кто-то указать мне верное направление? Я был бы очень признателен.
Вы в любом случае скрываете общедоступные данные, что не помогает нам.
Например, мы не можем проверить, обновили ли вы серийный номер SOA, и что изменение коснулось всех серверов NS, и что это было сделано с отрицательным TTL в SOA, достаточно низким, чтобы Gmail не видел никаких данных. .
Использование нескольких последовательностей «...» в записях DNS TXT не объединяет в одну строку, а предоставляет несколько строк. Затем приложение / протокол / спецификация должны сказать, как работать со строками; например, «соединить с пробелом между ними», «соединить напрямую», «использовать только первым».
В спецификации DKIM говорится, что нужно подключаться напрямую, но это относится непосредственно к той области, на которую разработчики часто не обращают внимания. Я рекомендую вам указать одну строку в качестве единственной строки в записи TXT и посмотреть, изменится ли это.
Я использую Exim с DKIM и Gmail всегда подтверждает это; ваша конфигурация Exim верна. Таким образом, либо ваш DNS не отображается, либо Gmail не любит несколько строк в записи TXT.
Вы также можете попробовать некоторые из тестовых сервисов DKIM:
Не ломай ключ. Просто добавьте его как одну строку. В большинстве редакторов это будет перенос слов. Мой ключ выглядит следующим образом.
rsa1._domainkey IN TXT "v=DKIM1; t=s; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKq2Ul9a5ixDPQm9WMoPI9fUEZU8FZwfux/O9Sl5+GDCR4rt0CsBzyZj4PY5DTtVHix++EZkR5rVdM4W59DtweKCK6XVntq4Y4GSm+gfZkf/fq45BSCQNilbYux4xqsHQIDAQAB"
Я не верю, что DKIM поддерживает сборку строк. Если вы используете многострочный формат, убедитесь, что он собран в одно целое. Если он подается с дополнительными кавычками, он, скорее всего, сломается. Ваш поиск в DNS показывает, что это так.
Очень часто записи SPF отображаются как "v=spf1" "a" "-all", который читается как vspf1a-all. Эта запись должна быть доставлена как v=spf1 a -all но будет работать как "v=spf1 " "a " "-all". SPF определяет поддержку цитируемых частей, объединяя части как есть, без дополнительных пробелов. Это позволяет разбивать строки посередине слова.
РЕДАКТИРОВАТЬ: я тестирую, используя ключ, отформатированный в несколько строк. Однако мне нужно будет дождаться обновления DNS. check-auth@verifier.port25.com сообщает мне, что моего нового ключа не существует.
Формат, который я получаю от связывания, не соответствует формату, который, как мне кажется, мне следует получить в документации. В документации указано, что я должен увидеть одну строку, объединяющую введенные мной фрагменты. Вместо этого я вижу фрагменты, введенные в файл зоны.
Тестирование с привязкой показывает, что фрагменты текста могут иметь длину до 255 символов. Все, что касается этого, нужно разделить. В любом случае два таких фрагмента, вероятно, превысят емкость пакета UPD.
Обзор RFC показывает, что размер ключа 2048 бит, вероятно, является практическим пределом. Есть предупреждение для разработчиков, что им, возможно, придется иметь дело с фрагментами TXT и собирать их заново по порядку.