多くのテストを行い、手順をたどった後でも、検証するGoogleメールを取得できません。
私のメールサーバーはeximを備えたDebian5.0です
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
私の秘密鍵へのパスは正しいです。
メッセージがGmailアカウントに表示されると、メッセージにDKIMヘッダーが表示されます。
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 = neutral(署名なし)を報告します。
dkim=neutral (no signature) [email protected]
私の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=")
誰かが私を正しい方向に向けることができますか?とても感謝しております。
キーを壊さないでください。単一の文字列として追加するだけです。ほとんどのエディターでワードラップされます。私の鍵は次のようになります。
rsa1._domainkey IN TXT "V = DKIM1; T = S、P = MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKq2Ul9a5ixDPQm9WMoPI9fUEZU8FZwfux/O9Sl5 + GDCR4rt0CsBzyZj4PY5DTtVHix ++ EZkR5rVdM4W59DtweKCK6XVntq4Y4GSm + gfZkf/fq45BSCQNilbYux4xqsHQIDAQAB"
DKIMが文字列の再構築をサポートしているとは思いません。複数行フォーマットを使用している場合は、それが1つのピースに再組み立てされていることを確認してください。それが余分な引用符で提供される場合、それはおそらく壊れます。 DNSルックアップは、これが事実であることを示しています。
多くの場合、SPFレコードが"v=spf1" "a" "-all"
として表示され、これはvspf1a-all
として読み取られます。このレコードはv=spf1 a -all
として配信する必要がありますが、"v=spf1 " "a " "-all"
として機能します。 SPFは、余分なスペースを導入せずにパーツをそのまま連結することにより、引用されたパーツのサポートを指定します。これにより、Wordの途中で行を分割できます。
編集:複数の文字列でフォーマットされたキーを使用してテストしています。ただし、DNSが更新されるまで待つ必要があります。 [email protected]は、新しいキーが存在しないことを教えてくれます。
Bindから取得する形式が、ドキュメントで取得する必要があると思われる形式と一致しません。ドキュメントには、入力したフラグメントを連結する単一の文字列が表示されるはずであることが示されています。代わりに、ゾーンファイルに入力されたフラグメントが表示されます。
Bindを使用したテストでは、テキストフラグメントが255文字にもなる可能性があることが示されています。それ以上のものはすべて分割する必要があります。いずれにせよ、そのような2つのフラグメントは、UPDパケットの容量を超える可能性があります。
RFCのレビューは、2048ビットのキーサイズが実際的な制限である可能性が高いことを示しています。はTXTフラグメントを処理し、それらを順番に再アセンブルする必要があるかもしれないという警告が実装者にあります。
とにかく公開されているデータを難読化しますが、それは私たちがあなたを助けるのに役立ちません。
たとえば、SOAシリアル番号を更新したこと、および変更によってすべてのNSサーバーに適用されたこと、およびこれが負のTTL in SOAで、Gmailがデータを合理的に認識できないほど低くなっています。
DNSで複数の「...」シーケンスを使用するTXTレコードは1つの文字列に結合されず、複数の文字列を提供します。次に、アプリケーション/プロトコル/仕様に応じて、文字列。例:「スペースを空けて結合する」、「直接結合する」、「最初にのみ使用する」。
DKIM仕様では直接参加するように書かれていますが、これは実装者が見落としがちな種類の領域に直接関係しています。 TXTレコード内の唯一の文字列として、1つの文字列を指定し、それによって状況が変わるかどうかを確認することをお勧めします。
EximをDKIMで使用し、Gmail常にで検証します。 Eximの構成は正しいです。したがって、DNSが表示されないか、GmailがTXTレコードの複数の文字列を嫌います。
DKIMテストサービスのいくつかを試すこともできます。