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

Reply via email to