Hello Wietse, thanks for your fast and detailed answer.
Accepting 8-bit dkim signed email and forwarding it to a 7-bit-only host inevitably leads to breaking the DKIM signatures. I am talking primary about emails which are received from the world over SMTP, and are forwarded, ideally unchanged, over SMTP to some other provider. In this case doing the signing after converting to 7-bit is not an option, as the emails arrive signed and the idea is not to break the signature. As there is nothing that can be done if a provider sends 8-bit mails for a domain with DMARC p=reject; policy to sites accepting only 7-bit emails, I wouldn't concern myself furhter with this case. Remote MTAs that do conversions and break signatures are out of my control, therefore I am not concerned about them. I can only suggest putting text in a file, that is supposed to be read by DKIM-deployers. Can Postfix know, when it signes a message over DKIM, whether the host to which the message will be forwarded is 8bit capable and transfer only if this is not the case the email to 7bit before signing it? About line lengths, sendmail truncates (structured) header-values by default to 256 octets per (unfolded) line, I have updated the text at h ttps://github.com/trusteddomainproject/OpenDKIM/issues/17 accordingly. Does Postfix consider From/Sender/To with display-part containing dot, that is not quoted, a well-formed email, and leave it as it, or does it quote it, hence modifying the email? By default sendmail quotes that part. So does sendmail, when the apostrophe sign (') is unquoted. Do you have an idea, what in the RFCs suggest special handling of the apostrophe sign? Implicitly folding long headers is foreseen by RFC 6376 and is mitigated by using the relaxed header canonicalization algorithm -- the software is supposed first to unfold all lines, and then to calculate the hash over the header-values. I do understand now approximately how and when postfix alters the emails, but I think it would be better, if somebody who works with Postfix proposes adapting https://github.com/trusteddomainproject/OpenD KIM/blob/master/opendkim/README to state precisely when Postfix modifies emails. I guess there will be some questions afterwards, which I cannot answer and it would be better if the communication goes directly. I did so in the 8-bit part of the README and in the installation for sendmail-part. Greetings Dilian On Sun, 2018-05-20 at 12:36 -0400, Wietse Venema wrote: > Like other MIME-aware MTAs, Postfix downgrades 8bit body content > to 7bit when a remote SMTP server does not announce 8BITMIME support. > If DKIM signatures must survive transmission to servers that don't > announce 8BITMIME, I recommend to downgrade before signing (for > example, specify "-o smtp_discard_ehlo_keywords=8bitmime,silent- > discard" > for an SMTP client that delivers to a null filter or to amavisd). > > You could specify "disable_mime_output_conversion = no" locally, > but that won't prevent remote MTAs from doing the 8bit to 7bit > downgrade and breaking DKIM signatures. > > You prevent Postfix from adding From/Date/Message-ID headers, and > from rewriting addresses in headers, by setting the -G flag for the > sendmail command, and by setting local_header_rewrite_clients to > empty (by default these modifications are enabled only for > submissions > by local processes and from clients in local networks). > > Otherwise, Postfix should not modify a well-formed email message. > For example, if the address in a from/to/etc. header is not modified, > then the header is passed through unchanged regardless of the content > of mailbox display names, comments, etc. > > However, there are no guarantees for out-of-spec email and for some > obsolete forms. For example, Postfix will fold lines > 998 (not > including the <CR><LF>) by inserting <CR><LF><SPACE> to minimize > damage to MIME-formatted messages, will truncate (multiline) headers > that contain >102400 bytes or >10240 tokens, and will replace the > obsolete form "headername :" with the normal form "headername:" > because many things in Postfix expect the normal form. > > Wietse