[GH-ISSUE #86] Exchange 2007 - "body hash did not verify" if Content-Transfer-Encoding: 8bit is set #65

New issue

Closed

opened 2026-02-26 10:35:32 +03:00 by kerem · 26 comments

kerem commented 2026-02-26 10:35:32 +03:00

Owner

Copy link

Originally created by @idevice on GitHub (May 8, 2015).
Original GitHub issue: https://github.com/Pro/dkim-exchange/issues/86

Hello,

at the first, thanks developing and sharing such a great extension for Exchange :)
I am trying to deploy it on Exchange 2007 (v. 8.3.83.6) running on SBS 2008 server.
DKIM signing works great with Outlook/OWA/Apple Mail, but with Thunderbird I got
" (body hash did not verify) header.i@ " error. Its seems to be related to 8bit encoding, because when message is send though Thunderbird, content-transfer-encoding is set to 8bit (mails send from all other mail client are using different type than 8bit- mainly quoted-printable - and in this case are signed properly).

I am start to thinking (after read many posts about exchange/dkim and 8bitmime encoding issues) that problem is in exchange re-encoding, but weird is that I also tested trial of EA DomainKeys/DKIM and it works properly with same Exchange configuration and thunderbird / 8bit encoding (i.e. same exchange config, same client, same mail content but one time is Exchange DkimSigner enabled and second time is EA DomainKeys agend enabled..) Now i am wondering if I miss some special setting needed for DkimSigner or it can be issue of dkimsigner itself.

Has anyone similar issue?

Used last version of DkimSigner v.2.1.4 (RsaSha1, Relaxed/Relaxed - but I tried also other combinations), Exchange 2007 (8.3.83.6).

I can provide any log or message header if needed.

Thanks,

Michal D.

Originally created by @idevice on GitHub (May 8, 2015). Original GitHub issue: https://github.com/Pro/dkim-exchange/issues/86 Hello, at the first, thanks developing and sharing such a great extension for Exchange :) I am trying to deploy it on Exchange 2007 (v. 8.3.83.6) running on SBS 2008 server. DKIM signing works great with Outlook/OWA/Apple Mail, but with Thunderbird I got " (body hash did not verify) header.i@ " error. Its seems to be related to 8bit encoding, because when message is send though Thunderbird, `content-transfer-encoding` is set to 8bit (mails send from all other mail client are using different type than 8bit- mainly quoted-printable - and in this case are signed properly). I am start to thinking (after read many posts about exchange/dkim and 8bitmime encoding issues) that problem is in exchange re-encoding, but weird is that I also tested trial of EA DomainKeys/DKIM and it works properly with same Exchange configuration and thunderbird / 8bit encoding (i.e. same exchange config, same client, same mail content but one time is Exchange DkimSigner enabled and second time is EA DomainKeys agend enabled..) Now i am wondering if I miss some special setting needed for DkimSigner or it can be issue of dkimsigner itself. Has anyone similar issue? Used last version of DkimSigner v.2.1.4 (RsaSha1, Relaxed/Relaxed - but I tried also other combinations), Exchange 2007 (8.3.83.6). I can provide any log or message header if needed. Thanks, Michal D.

kerem 2026-02-26 10:35:32 +03:00

• closed this issue
• added the
  bug
  agent
  labels

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (May 8, 2015):

It may be related to the fact you mentioned that some clients convert 8bit to quoted printable or 7bit which of course breaks the hashsum.
As the DKIM RFC states, the message should be converted to quoted printable: http://tools.ietf.org/html/rfc4871#section-5.3

See also: http://stbuehler.de/blog/article/2011/05/19/dkim_fails_at_content-transfer-encoding.html

But letting the dkim-signer change the content encoding of the message would probably break other already existing signatures. E.g. the mail may be signed using S/MIME. If our signer then converts the mail, it may break the S/MIME signature.

Here you can find a discussion regarding this problem: http://sourceforge.net/p/dkimproxy/mailman/message/188564/

The conclusion from this thread is:

The only reliable solution is to produce a 7-bit mail BEFORE
signing it with S/MIME. Don't know how to force Thunderburd
do to so, I hope it is possible.

If this is not an option, then you can choose between
two bad choices:

  - let DKIM sign 8-bit mail. A risk is that recipient's mailer
    will invalidate both signatures if it decides to downconvert;

  - convert the mail before signing, which  guarantees to invalidate
   your 8-bit S/MIME, but avoids a need for any further conversions
   downstream, increasing chances of DKIM signature surviving.

On the other hand, we are already modifying (normalizing) the content of the email when canonicalization simple is used (e.g. to make sure the line endings are correct). We have to investigate if this also breaks S/MIME signatures (#87).

Maybe a solution to this problem is to add additional settings to let the admin decide what to do. Here are some settings I can think of at the moment:

• Do not sign any mails containing a S/MIME signature. Just forward them without signature.
• Convert 8bit to quoted-printable (with the possibility to break S/MIME)
• Convert 8bit to quoted-printable. If the signer gets an email with S/MIME, send an NDR to the sender informing him to disable 8bit in his mail client.
• Keep 8bit (with the possibility that the DKIM hash will be invalidated afterwards)

Any thoughts?

<!-- gh-comment-id:100240774 --> @Pro commented on GitHub (May 8, 2015): It may be related to the fact you mentioned that some clients convert `8bit` to `quoted printable` or `7bit` which of course breaks the hashsum. As the DKIM RFC states, the message should be converted to `quoted printable`: http://tools.ietf.org/html/rfc4871#section-5.3 See also: http://stbuehler.de/blog/article/2011/05/19/dkim_fails_at_content-transfer-encoding.html But letting the dkim-signer change the content encoding of the message would probably break other already existing signatures. E.g. the mail may be signed using S/MIME. If our signer then converts the mail, it may break the S/MIME signature. Here you can find a discussion regarding this problem: http://sourceforge.net/p/dkimproxy/mailman/message/188564/ The conclusion from this thread is: ``` The only reliable solution is to produce a 7-bit mail BEFORE signing it with S/MIME. Don't know how to force Thunderburd do to so, I hope it is possible. If this is not an option, then you can choose between two bad choices: - let DKIM sign 8-bit mail. A risk is that recipient's mailer will invalidate both signatures if it decides to downconvert; - convert the mail before signing, which guarantees to invalidate your 8-bit S/MIME, but avoids a need for any further conversions downstream, increasing chances of DKIM signature surviving. ``` On the other hand, we are already modifying (normalizing) the content of the email when canonicalization `simple` is used (e.g. to make sure the line endings are correct). We have to investigate if this also breaks S/MIME signatures (#87). Maybe a solution to this problem is to add additional settings to let the admin decide what to do. Here are some settings I can think of at the moment: - Do not sign any mails containing a S/MIME signature. Just forward them without signature. - Convert 8bit to quoted-printable (with the possibility to break S/MIME) - Convert 8bit to quoted-printable. If the signer gets an email with S/MIME, send an NDR to the sender informing him to disable 8bit in his mail client. - Keep 8bit (with the possibility that the DKIM hash will be invalidated afterwards) Any thoughts?

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (May 8, 2015):

@idevice do you have the possibility to test again with EA DomainKeys/DKIM and check what happens if you send an e-mail as 8bit encoded, which is signed with S/MIME?
Does it break the S/MIME signature?

<!-- gh-comment-id:100242934 --> @Pro commented on GitHub (May 8, 2015): @idevice do you have the possibility to test again with `EA DomainKeys/DKIM` and check what happens if you send an e-mail as 8bit encoded, which is signed with S/MIME? Does it break the S/MIME signature?

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@idevice commented on GitHub (May 8, 2015):

when use S/MIME signature it seems that its automatically switched to quoted-printable, because when I do it, I receive message in quoted-printable encoding - properly DKIM signed via both dkim transport agents - EA and Yours, and also S/MIME gives me results that message is properly signed without content modifications... Just now I am trying find how to force 8-bit with S/MIME...

<!-- gh-comment-id:100259394 --> @idevice commented on GitHub (May 8, 2015): when use S/MIME signature it seems that its automatically switched to quoted-printable, because when I do it, I receive message in quoted-printable encoding - properly DKIM signed via both dkim transport agents - EA and Yours, and also S/MIME gives me results that message is properly signed without content modifications... Just now I am trying find how to force 8-bit with S/MIME...

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (May 8, 2015):

Thanks for testing! I've also found an option to force quoted-printable within firefox. You need to set mail.strictly_mime to true within the hidden properties (see http://forums.mozillazine.org/viewtopic.php?f=28&t=1697835) But it's not practicable to tell every user of the mail server to set this setting, thus we need to find another option, e.g. the settings mentioned above.

<!-- gh-comment-id:100261689 --> @Pro commented on GitHub (May 8, 2015): Thanks for testing! I've also found an option to force `quoted-printable` within firefox. You need to set `mail.strictly_mime` to true within the hidden properties (see http://forums.mozillazine.org/viewtopic.php?f=28&t=1697835) But it's not practicable to tell every user of the mail server to set this setting, thus we need to find another option, e.g. the settings mentioned above.

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@idevice commented on GitHub (May 8, 2015):

Yes, I found same thing, problem is that its forcing quoted-printable instead/over 8bit, but I still did not find opposite settings (eg. force Content-Transfer-Encoding: 8bit ) So I am not sure if I will be able to reproduce this behavior which you ask me for (8bit with SMIME over EA.. :/

<!-- gh-comment-id:100263634 --> @idevice commented on GitHub (May 8, 2015): Yes, I found same thing, problem is that its forcing quoted-printable instead/over 8bit, but I still did not find opposite settings (eg. force Content-Transfer-Encoding: 8bit ) So I am not sure if I will be able to reproduce this behavior which you ask me for (8bit with SMIME over EA.. :/

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@idevice commented on GitHub (May 8, 2015):

Maybe I am wrong, but it seems that 8-bit cant (shouldn't) be signed with S/MIME, according S/MIME RFC 5751 ( http://tools.ietf.org/html/rfc5751 ) At least signed part of multipart message should be converted to QP or B64 before signing.... so maybe it will helps with Dkimsigner 8bit to QP conversion.. (if I understand it well: when 8bit its present, we can assume that it should not be signed with S/MIME, - of course if mail client follow standards :) )

<!-- gh-comment-id:100273010 --> @idevice commented on GitHub (May 8, 2015): Maybe I am wrong, but it seems that 8-bit cant (shouldn't) be signed with S/MIME, according S/MIME RFC 5751 ( http://tools.ietf.org/html/rfc5751 ) At least signed part of multipart message should be converted to QP or B64 before signing.... so maybe it will helps with Dkimsigner 8bit to QP conversion.. (if I understand it well: when 8bit its present, we can assume that it should not be signed with S/MIME, - of course if mail client follow standards :) )

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (May 8, 2015):

You are right, It's mentined in this section: http://tools.ietf.org/html/rfc5751#section-3.1.3 that S/MIME requires 7bit data. So the combination of 8bit+S/MIME should never occur. If the signer is confronted with such an email, we should generate an NDR and send it back to the sender as mentioned in the RFC:

If a compliant agent that cannot transmit 8-bit or binary data
encounters a multipart/signed message with 8-bit or binary
data in the first part,  it would have to return the message to
the sender as undeliverable.

<!-- gh-comment-id:100284301 --> @Pro commented on GitHub (May 8, 2015): You are right, It's mentined in this section: http://tools.ietf.org/html/rfc5751#section-3.1.3 that S/MIME requires 7bit data. So the combination of 8bit+S/MIME should never occur. If the signer is confronted with such an email, we should generate an NDR and send it back to the sender as mentioned in the RFC: ``` If a compliant agent that cannot transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable. ```

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (May 8, 2015):

So the solution which we should implement is:

Convert 8bit to quoted-printable. If the signer gets an 8bit email with S/MIME, send an NDR (non delivery report) to the sender informing him about the non-conform message encoding.

<!-- gh-comment-id:100285494 --> @Pro commented on GitHub (May 8, 2015): So the solution which we should implement is: Convert 8bit to quoted-printable. If the signer gets an 8bit email with S/MIME, send an NDR (non delivery report) to the sender informing him about the non-conform message encoding.

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@idevice commented on GitHub (May 8, 2015):

For me, its perfect, but i cant talk for other users, so its a question if dont make some gui settings adjustment like switch or check box for : - 8bit - pass as it as /or/ convert to QP and deny 8bit SMIME..

Anyway thanks a lot for quick investigate of this issue.

Odesláno z iPhonu

1. 5. 2015 v 18:20, Stefan Profanter notifications@github.com:

So the solution which we should implement is:

Convert 8bit to quoted-printable. If the signer gets an 8bit email with S/MIME, send an NDR (non delivery report) to the sender informing him about the non-conform message encoding.

—
Reply to this email directly or view it on GitHub.

<!-- gh-comment-id:100322056 --> @idevice commented on GitHub (May 8, 2015): For me, its perfect, but i cant talk for other users, so its a question if dont make some gui settings adjustment like switch or check box for : - 8bit - pass as it as /or/ convert to QP and deny 8bit SMIME.. Anyway thanks a lot for quick investigate of this issue. Odesláno z iPhonu 1. 5. 2015 v 18:20, Stefan Profanter notifications@github.com: > So the solution which we should implement is: > > Convert 8bit to quoted-printable. If the signer gets an 8bit email with S/MIME, send an NDR (non delivery report) to the sender informing him about the non-conform message encoding. > > — > Reply to this email directly or view it on GitHub.

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@AlexLaroche commented on GitHub (May 8, 2015):

@Pro : I also think that this is the better way to implement it.

Convert 8bit to quoted-printable. If the signer gets an 8bits email with S/MIME, send a NDR (non delivery report) to the sender informing him about the non-conform message encoding standard.

Should we have an option where we could choose to send email without DKIM signing?

@idevice : Can you confirm that EA DomainKeys/DKIM convert the email from 8bits to quoted-printable?

<!-- gh-comment-id:100374418 --> @AlexLaroche commented on GitHub (May 8, 2015): @Pro : I also think that this is the better way to implement it. Convert 8bit to quoted-printable. If the signer gets an 8bits email with S/MIME, send a NDR (non delivery report) to the sender informing him about the non-conform message encoding standard. Should we have an option where we could choose to send email without DKIM signing? @idevice : Can you confirm that EA DomainKeys/DKIM convert the email from 8bits to quoted-printable?

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@idevice commented on GitHub (May 8, 2015):

Seems that EA keep 8bit somehow... Is there some private way how to provide you source code of messages? (new to github and I don't know how it works here..)

<!-- gh-comment-id:100377863 --> @idevice commented on GitHub (May 8, 2015): Seems that EA keep 8bit somehow... Is there some private way how to provide you source code of messages? (new to github and I don't know how it works here..)

kerem commented 2026-02-26 10:35:33 +03:00

Author

Owner

Copy link

@AlexLaroche commented on GitHub (May 10, 2015):

@Pro : Have you experiment the problem on exchange 2010 or 2013? I think the current problem only apply to Exchange 2007?

https://technet.microsoft.com/en-us/library/gg144562(v=exchg.141).aspx
https://technet.microsoft.com/en-us/library/gg144562%28v=exchg.150%29.aspx

<!-- gh-comment-id:100576935 --> @AlexLaroche commented on GitHub (May 10, 2015): @Pro : Have you experiment the problem on exchange 2010 or 2013? I think the current problem only apply to Exchange 2007? https://technet.microsoft.com/en-us/library/gg144562(v=exchg.141).aspx https://technet.microsoft.com/en-us/library/gg144562%28v=exchg.150%29.aspx

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@AlexLaroche commented on GitHub (May 16, 2015):

@idevice: Can you try to update to Rollup 16 for Exchange Server 2007 Service Pack 3? Currently, only Exchange 2007 SP1 without any rollup are installed? May be this bug have been fix.

Source : http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollup-build-numbers.aspx

<!-- gh-comment-id:102671451 --> @AlexLaroche commented on GitHub (May 16, 2015): @idevice: Can you try to update to Rollup 16 for Exchange Server 2007 Service Pack 3? Currently, only Exchange 2007 SP1 without any rollup are installed? May be this bug have been fix. Source : http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollup-build-numbers.aspx

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@AlexLaroche commented on GitHub (May 16, 2015):

@idevice : You could also disable Exchange 8bitmime support. It will probably solve your problem because Thunderbird will have to use another Content-Tranfer-Encoding.

In PowershellShell : Set-ReceiveConnector -Identity "Connector Name" -EightBitMimeEnabled $False

Source (more tricky way - via ADSI) : http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02449735

<!-- gh-comment-id:102677902 --> @AlexLaroche commented on GitHub (May 16, 2015): @idevice : You could also disable Exchange 8bitmime support. It will probably solve your problem because Thunderbird will have to use another Content-Tranfer-Encoding. In PowershellShell : Set-ReceiveConnector -Identity "Connector Name" -EightBitMimeEnabled $False Source (more tricky way - via ADSI) : http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c02449735

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@idevice commented on GitHub (May 16, 2015):

i have Rollup 15 installed (version of exchange from my first post was taken from exchange management console - about - and there is only major "sp" version number - i am sorry for that misunderstanding)

for disabling 8bit directly on exchange resp. disable ESMTP.. - i already found that information (btw also on Microsoft site directly) but with warning that it shouldn't be done at least on main connector. So i want to try to avoid this solution.

about your question about "Change the Method for 7-bit Transfer Encoding" - this MS KB also exist for exchange 2007 but result from my testing are: change of type "ByteEncoderTypeFor7BitCharsets" only change type of 7bit encoding itself (so change of these setting don't affect 8bit type), and in ´KB for 2007 is also mentioned:

Note The method that you use to change the transfer encoding does not affect the following MIME-format messages:
•Messages that are sent by an SMTP client, such as POP/IMAP
• Messages that come from an SMTP server that is not an Exchange Server 2007-based server, such as Sendmail, Qmail, Postfix, and so on
• Messages that come from an SMTP server that is an Exchange Server 2007-based server that is running the Hub Transport or Edge Transport role and that does not use the settings that are described in this article

<!-- gh-comment-id:102697474 --> @idevice commented on GitHub (May 16, 2015): i have Rollup 15 installed (version of exchange from my first post was taken from exchange management console - about - and there is only major "sp" version number - i am sorry for that misunderstanding) for disabling 8bit directly on exchange resp. disable ESMTP.. - i already found that information (btw also on Microsoft site directly) but with warning that it shouldn't be done at least on main connector. So i want to try to avoid this solution. about your question about "Change the Method for 7-bit Transfer Encoding" - this MS KB also exist for exchange 2007 but result from my testing are: change of type "ByteEncoderTypeFor7BitCharsets" only change type of 7bit encoding itself (so change of these setting don't affect 8bit type), and in ´KB for 2007 is also mentioned: Note The method that you use to change the transfer encoding does not affect the following MIME-format messages: •Messages that are sent by an SMTP client, such as POP/IMAP • Messages that come from an SMTP server that is not an Exchange Server 2007-based server, such as Sendmail, Qmail, Postfix, and so on • Messages that come from an SMTP server that is an Exchange Server 2007-based server that is running the Hub Transport or Edge Transport role and that does not use the settings that are described in this article

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@AlexLaroche commented on GitHub (May 21, 2015):

@idevice : Are you able to reproduce the problem with simple/simple configuration?

I think the problem is only with relaxed/relaxed configuration. (Precisely : I think it's when relaxed is use for generate body hash.)

<!-- gh-comment-id:104445830 --> @AlexLaroche commented on GitHub (May 21, 2015): @idevice : Are you able to reproduce the problem with simple/simple configuration? I think the problem is only with relaxed/relaxed configuration. (Precisely : I think it's when relaxed is use for generate body hash.)

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@avoidik commented on GitHub (Dec 11, 2015):

Any info on this problem? I have Exchange 2010 with latest CU. I've tried all combination of Canonicalization algorithms and always get dkim=neutral (body hash did not verify). Mail sent directly over SMTP.

<!-- gh-comment-id:163863731 --> @avoidik commented on GitHub (Dec 11, 2015): Any info on this problem? I have Exchange 2010 with latest CU. I've tried all combination of Canonicalization algorithms and always get **dkim=neutral (body hash did not verify)**. Mail sent directly over SMTP.

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (Dec 11, 2015):

@avoidik are you using Content-Transfer-Encoding: 8bit?

<!-- gh-comment-id:163879461 --> @Pro commented on GitHub (Dec 11, 2015): @avoidik are you using Content-Transfer-Encoding: 8bit?

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@avoidik commented on GitHub (Dec 11, 2015):

Thanks. Found this by myself. Got it.

<!-- gh-comment-id:163881425 --> @avoidik commented on GitHub (Dec 11, 2015): Thanks. Found this by myself. Got it.

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (Dec 14, 2015):

I've found MimeKit (https://github.com/jstedfast/MimeKit) which also provides a better implementation for DKIM signing. We will integrate it into this agent and release it as version 3.0.0 (see https://github.com/Pro/dkim-exchange/tree/mime_kit). This will probably reduce the number of problems regarding wrongly signed mails. It will take some days, hopefully it is ready in January.
We need to test how it handles 8bit mails.

<!-- gh-comment-id:164424041 --> @Pro commented on GitHub (Dec 14, 2015): I've found MimeKit (https://github.com/jstedfast/MimeKit) which also provides a better implementation for DKIM signing. We will integrate it into this agent and release it as version 3.0.0 (see https://github.com/Pro/dkim-exchange/tree/mime_kit). This will probably reduce the number of problems regarding wrongly signed mails. It will take some days, hopefully it is ready in January. We need to test how it handles 8bit mails.

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (Dec 14, 2015):

It looks like the MimeKit handles 8bit correctly: https://github.com/jstedfast/MimeKit/blob/master/MimeKit/MimeMessage.cs#L1434

<!-- gh-comment-id:164425134 --> @Pro commented on GitHub (Dec 14, 2015): It looks like the MimeKit handles 8bit correctly: https://github.com/jstedfast/MimeKit/blob/master/MimeKit/MimeMessage.cs#L1434

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@Pro commented on GitHub (Jan 1, 2016):

v3.0.0 beta is now released. This should fix the 8bit issue:
https://github.com/Pro/dkim-exchange/releases/tag/v3.0.0-beta

<!-- gh-comment-id:168315080 --> @Pro commented on GitHub (Jan 1, 2016): v3.0.0 beta is now released. This should fix the 8bit issue: https://github.com/Pro/dkim-exchange/releases/tag/v3.0.0-beta

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@wish01 commented on GitHub (Mar 9, 2017):

Hi, how to change the setting so that the attachments are always coded the Equally?
Example error: if the name of the attachment is Cyrillic, then Content-Type: text / plain; Charset = "koi8-r", DKIM: Error. if the name of the attachment is in Latin, then Content-Type: text / plain; Charset = "windows-1251", DKIM: PASS.
Where do I change the encoding setting on the Exchange server or in Exchange DkimSigner?

<!-- gh-comment-id:285261286 --> @wish01 commented on GitHub (Mar 9, 2017): Hi, how to change the setting so that the attachments are always coded the Equally? Example error: if the name of the attachment is Cyrillic, then Content-Type: text / plain; Charset = "koi8-r", DKIM: Error. if the name of the attachment is in Latin, then Content-Type: text / plain; Charset = "windows-1251", DKIM: PASS. Where do I change the encoding setting on the Exchange server or in Exchange DkimSigner?

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@avoidik commented on GitHub (Mar 9, 2017):

AFAIK encoding detected based on email's text and subject automatically

9 мар 2017 г. 7:51 пользователь "wish01" notifications@github.com написал:

Hi, how to change the setting so that the attachments are always coded the
same, if the name of the attachment is Cyrillic, then Content-Type: text /
plain; Charset = "koi8-r", DKIM: Error. if the name of the attachment is in
Latin, then Content-Type: text / plain; Charset = "windows-1251", DKIM:
PASS.
Where do I change the encoding setting on the Exchange server or in
Exchange DkimSigner?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Pro/dkim-exchange/issues/86#issuecomment-285261286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGI0XGGHIeOXwmP1uUh5ywzo9TJ0KTCXks5rj5NVgaJpZM4ETwMt
.

<!-- gh-comment-id:285261682 --> @avoidik commented on GitHub (Mar 9, 2017): AFAIK encoding detected based on email's text and subject automatically 9 мар 2017 г. 7:51 пользователь "wish01" <notifications@github.com> написал: > Hi, how to change the setting so that the attachments are always coded the > same, if the name of the attachment is Cyrillic, then Content-Type: text / > plain; Charset = "koi8-r", DKIM: Error. if the name of the attachment is in > Latin, then Content-Type: text / plain; Charset = "windows-1251", DKIM: > PASS. > Where do I change the encoding setting on the Exchange server or in > Exchange DkimSigner? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/Pro/dkim-exchange/issues/86#issuecomment-285261286>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGI0XGGHIeOXwmP1uUh5ywzo9TJ0KTCXks5rj5NVgaJpZM4ETwMt> > . >

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@wish01 commented on GitHub (Mar 9, 2017):

How then to fix the DKIM error? Upgrading to version 3.0.8 did not fix the bug.

<!-- gh-comment-id:285262979 --> @wish01 commented on GitHub (Mar 9, 2017): How then to fix the DKIM error? Upgrading to version 3.0.8 did not fix the bug.

kerem commented 2026-02-26 10:35:34 +03:00

Author

Owner

Copy link

@avoidik commented on GitHub (Mar 17, 2017):

@wish01 you can try advise above

Set-ReceiveConnector -Identity "Connector Name" -EightBitMimeEnabled $False

<!-- gh-comment-id:287310369 --> @avoidik commented on GitHub (Mar 17, 2017): @wish01 you can try advise above ``` Set-ReceiveConnector -Identity "Connector Name" -EightBitMimeEnabled $False ```

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

dependabot/nuget/Src/Configuration.DkimSigner/MimeKit-4.7.1

Ed25519-SHA256

feature/dkim-verify

coverity_scan

v3.4.1.2

v3.4.2

v3.4.1.1

v3.4.1

v3.4.0

v3.3.4

v3.3.3

v3.3.2

v3.3.1

v3.2.9

v3.2.8

v3.2.7

3.2.6

v3.2.5

v3.2.4

v3.2.4-alpha

v3.2.3.1

v3.2.3

v3.2.2

v3.2.0

v3.1.0

v3.0.13

v3.0.12

v3.0.11

v3.0.10

v3.0.9

v3.0.8

v3.0.7

v3.0.6

v3.0.5

v3.0.4

v3.0.3

v3.0.2

v3.0.1

v3.0.0

v3.0.0-beta.2

v3.0.0-beta

v2.1.8

v2.1.7

v2.1.6

v2.1.5

v2.1.5-beta.2

v2.1.5-beta

v2.1.4

v2.1.3

v.2.1.2

v2.1.1

v2.1.0

v2.0.3

v2.0.2

v2.0.1

v2.0.0-beta.4

v2.0.0-rc.1

v2.0.0-beta.3

v2.0.0-beta.2

v2.0.0-beta

v2.0.0-alpha.1

v2.0.0-alpha

v1.8.3

1.8.2

v1.8.1

v1.8.0

v1.7.0

v1.6.0

v1.5.2

Labels

Clear labels   

agent

  

agent

  

bug

  

bug

  

enhancement

  

gui

  

invalid

  

need-info

  

question

  

wontfix

No labels

agent

agent

bug

bug

enhancement

gui

invalid

need-info

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/dkim-exchange-Pro#65

No description provided.