[pfx] Re: Milter multiline header formatting

[Scott Kitterman via Postfix-users]

On March 6, 2024 7:37:47 PM UTC, Steffen Nurpmeso via Postfix-users 
<postfix-users@postfix.org> wrote:
>Hello Wietse Venema :)
>
>Wietse Venema via Postfix-users wrote in
> <4tqhxw0ksyzj...@spike.porcupine.org>:
> |Steffen Nurpmeso via Postfix-users:
> |> Wietse Venema via Postfix-users wrote in
> |>  <4tqh100n6pzj...@spike.porcupine.org>:
> |>|Are you trying to say that Postfix represents a multiline message
> |>|header as text with \n instead of \r\n?
> |> 
> |> Yes.
> ...
> |>|I agree that \r\n would be better, but I'm surprised that this has
> |>|not come up before.
> ..
> |Every Received: header is multiline, and it is not unusual to have
>
>These are not "usually" DKIM signed i'd say.
>
> |multiline Subject:, To:, and other common headers.
>
>Yes.
>
> |Again, Postfix does not store line terminators, not when email comes
> |from UNIX tool with \n, via SMTP with \r\n, or encapsulated as
> |netstrings which uses neither. 
>
>OK then there is nothing i can do on the MUA side.
>
> |Instead, Postfix generates line terminators upon output, and until
> |now they are always \n.
> |
> |Postfix systems have been signing with Milters since Postfix Milter
> |support was added in 2006. I'm just surprised that the non-canoncal
> |line endings in a multiline header have not been a problem before.
>
>My milter now treats LF and CR not in a CRLF as real whitespace.
>The email i just sent was accepted by Google, this one should also
>wrap, and we see what this software does (rspamd is it i think).
>
>So it seems to me, without having looked what OpenDKIM does, and
>maybe i should explicitly Cc: Scott Kitterman for his dkimpy, but
>i know he is on this list, just let's wait a bit, that all these
>DKIM milters do it falsely, and treat LF and CR other than the
>combination of CRLF as whitespace.  Even though WSP is defined by
>"RFC 5234, B.1.  Core Rules:" as "WSP    = SP / HT; white space",
>and that is what the DKIM and email standards go for.  For the
>latter i explicitly asked a month or so ago.
>So they break the email standard, postfix does, too, and in
>combination all is fine again.

As far as I know, we're doing it mostly correctly I'm dkimpy (see below).  It's 
used in lots of ways that have nothing to do with postfix, so I am strongly 
inclined to believe it's right or there would have been lots of reports of 
interoperability issues.  I am up to my eyeballs in other stuff at the moment, 
so there's no way I can even contemplate time for a code review in the absence 
of a known issue.

One thing that may be a factor is the canonicalization algorithm being used.  I 
tried simple early on, but it proved to be fragile.  I suspect (but equally 
haven't recently checked) most are using relaxed canonicalization.  For the 
header, line endings don't matter for it since you unfold everything.  The 
'simple' canonicalization is easy to implement, but very fragile.  It is, in 
fact, bad enough that even if you tell dkimpy to use simple for the header, it 
does relaxed anyway.  For the body it will do whichever is specified.

Scott K
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org