Pro / dkim-exchange

DKIM Signing Agent for Microsoft Exchange Server
Other
409 stars 143 forks source link

Google DKIM validation #84

Closed AlwindB closed 9 years ago

AlwindB commented 9 years ago

Using the DKIM-Exchange plugin I noticed that on the 2.1.4 install (clean install) on Exchange 2010 (14.3.123.4) that DKIM validation with Google does not detect the presence of a DKIM key (dkim=neutral).

Below the headers:

Received-SPF: pass (google.com: domain of A**_.***@m*****.com designates *... as permitted sender) client-ip=..._; Authentication-Results: mx.google.com; spf=pass (google.com: domain of A**.**@m****.com designates *... as permitted sender) smtp.mail=A**_.***@m*****.com; dkim=neutral (no signature) header.i=@m**_***.com; dmarc=pass (p=REJECT dis=NONE) header.from=m*****_.com dkim-signature: v=1; a=rsa-sha256; s=key20150408; d=m_**.com; c=relaxed/relaxed; q=dns/txt; h=From:content-type:date:from:message-id:mime-version:subject:to; bh=RtiycR1cKu3bB2m/xfdGzGfZlmRfqJR/fADAKgy5ZGQ=; b=JncdPhOjI5pBAgnCDmgqYlQp/yIHYxXbTiupLQbXl5dT3QRQFfQlN3hYCHVsYJ+wKzSX8AQkMoQxok7LtqNqkgccPhE3UKcew4CaHDPIJKqABD4AW4g4tHzgCM2/fyUSW54I5czMD4bVP2ROjFJcdBTrtZD4OJi4q31Xl1CIcFA=;

Whilst using EA DomainKeys the header is being set as: Received-SPF: pass (google.com: domain of A**_.***@m*****.com designates *... as permitted sender) client-ip=..._; Authentication-Results: mx.google.com; spf=pass (google.com: domain of A**.**@m****.com designates *... as permitted sender) smtp.mail=A**_.***@m*****.com; dkim=pass header.i=@m**_***.com; dmarc=pass (p=REJECT dis=NONE) header.from=m*****_.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=key20150327; d=m_**.com; h=from:to:subject:date:message-id:content-type:mime-version; bh=ymeIG2f9WWjRJs8InKjRDD9Lm+54k30ESM3uApkBsvo=; b=S/o8/DTb7nFLJCLMO3V/XNapSkpghf4oFNs07h54tFkCUqP8/VwvgoeUvn2Fv8qBQoSVuNUA 0z9n/UQuzZ7O/QhDXmMnswramIrdadUZEAsNzyiIKJfh1eDVOtOIluiFi1CqVP23LLjUyhx2 5L3GtckmaO0jalUIAO5RbJypCHg=

Be aware that this is a different private/public keyset.

Currently I cannot explain where the difference comes from, except for my guess that is has something to do with building the headers.

AlexLaroche commented 9 years ago

I did the test on my test server without any error... Could be a configuration problem? You should check your key in your DNS and in the Exchange DKIM Agent configuration?

AlexLaroche commented 9 years ago

You could also try to test your configuration by sending a email to "check-auth@verifier.port25.com".

http://www.port25.com/support/authentication-center/email-verification/

AlwindB commented 9 years ago

Hi Alex,

found out something interesting, when changing the header and body canonicalization, the validation of the DKIM passes or fails. Also the header changes from case sensitive to lowercase.

This all with the same DKIM key, so no changes on that end of the configuration.

See my check below

header/body

simple/simple = pass header start= DKIM-Signature: v=DKIM1; etc....

simple/relaxed = pass header start= DKIM-Signature: v=DKIM1; etc....

relaxed/simple = fail header start= dkim-signature: v=DKIM1; etc....

relaxed/relaxed = fail header start= dkim-signature: v=DKIM1; etc....

topcats commented 9 years ago

I am running Exchange 2013 CU8 with the new 2.1.4 and have just tested to the port25.com address

All appears fine for me

SPF check: pass DomainKeys check: neutral DKIM check: pass Sender-ID check: pass SpamAssassin check: ham

AlwindB commented 9 years ago

topcats, how is your setup simple/simple or one of the other options

topcats commented 9 years ago

yes running simple/simple rsasha1

AlexLaroche commented 9 years ago

I did a test yesterday with relaxed/relaxed and simple/simple without any problem... :/

AlwindB commented 9 years ago

Regarding DKIM prefered options: RFC advises sha256 above sha1, sha256 is also the default algorithm when it's not specified.

Some more information, running W2k8 R2 w/Exchange 2010.

When trying to build a native DKIM validation plugin (for DMARC) based on the Transport Agent we noticed that Exchange is altering some message headers. So it might be related to that, have to check up with my collegue.

topcats commented 9 years ago

I had a problem with sha256 when I was inserting the hash into the dns records. It appeared to truncate the txt record, so I changed to sha1, which works ok

gogglespisano commented 9 years ago

If you're using BIND DNS, there is a text length limit, but you can work around it,

"abcdef" can be written as "abc" "def" or ("abc" "def")

You can split a text value into smaller strings and it will glue it all back together. If you want to spread it out over multiple lines, then surround the value in parenthesis.

topcats commented 9 years ago

Am using a third party hosted dns web console, i'm stuck with it for now so a shorter key will have to do :(

AlexLaroche commented 9 years ago

For Windows DNS servers, the long DKIM keys can be broken up into multiple lines when entering the record into the DNS management tool. A single long line will be truncated at 256 characters but multiple lines will be accepted. For example, the following DKIM record would be truncated when entering it into dnsmgmt:

"v=DKIM1; k=rsa; h=sha256 p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzLj8Fw4H27vKcm3BVChkxgM2fjHUCQGxrp8jeYgdWRdsF3w5lWKICVawjkISzpQqF7wwgRWMNVAxxCs2opJKHpmTPsdRfRnHuqCdBgEDBUT3717k74qDCoP7TGVgQmB3DWm2vsg/LmaHpAk1OQ9MV5W0WnH3XEaJmtR67OAEuEABdjBX0A3V+5lb1piwpkL7RUyOPkNEyIjSILC4c2Zn7+HaM4CP8hJ8ZEx8bCFhkML4PbiEQZoXuxe5D+DB8mNt6UwzyjfbMZ1CeGEWLZpkcRlBgPx75XIeh9yVyw0bHctaCr43xwnb41KuluCzXD8sLFbYpYDyQThIqUXrGtv48wIDAQAB"

The same record, broken up into multiple lines would be correctly stored and served by the Windows DNS server:

"v=DKIM1; k=rsa; h=sha256 p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzLj8Fw4H27vKcm3BVChkxgM2fjHUCQGxrp8jeYgdWRdsF3w5lWKICVawjkISzpQqF7wwgRWMNVAxxCs2opJKHpmTPsdRfRn HuqCdBgEDBUT3717k74qDCoP7TGVgQmB3DWm2vsg/LmaHpAk1OQ9MV5W0WnH3XEaJmtR67OAEuEABdjBX0A3V+5lb1piwpkL7RUyOPkNEyIjSILC4c2Zn7+HaM4CP8hJ8ZEx8bCFhk ML4PbiEQZoXuxe5D+DB8mNt6UwzyjfbMZ1CeGEWLZpkcRlBgPx75XIeh9yVyw0bHctaCr43xwnb41KuluCzXD8sLFbYpYDyQThIqUXrGtv48wIDAQAB"

AlexLaroche commented 9 years ago

Please reopen if the problem isn't solved.