Wietse Venema via Postfix-users wrote in
 <4tqwct4jgczj...@spike.porcupine.org>:
 |Wietse Venema via Postfix-users:
 |> The text should have said:
 |> 
 |>   Other command-line arguments
 |>  Specify "{" and "}" around command arguments that must start
 |>  with "{" or that must contain whitespace (Postfix 3.0 and
 |>  later). These outer "{" and "}" are removed from the input,
 |>  together with any leading or trailing whitespace.
 |> 
 |> Basically, Postfix strips one level of {} around any command-line
 |> argument that starts with "{".
 |> 
 |> In that light, if you want "{daemon_name},sign", you need to specify
 |> {{daemon_name},sign} like this:
 |> 
 |> dkim-sign unix -       n       n       -       0       spawn
 |>         user=_postfix_xlocal argv=/tmp/s-dkim-sign
 |>         --milter-macro-sign {{daemon_name},sign}
 |>         --key rsa-sha256,rsa,/tmp/pri-rsa.pem
 |
 |Or, as you're using "long" options:
 |
 | dkim-sign unix -       n       n       -       0       spawn
 |         user=_postfix_xlocal argv=/tmp/s-dkim-sign
 |         --milter-macro-sign={daemon_name},sign
 |         --key=rsa-sha256,rsa,/tmp/pri-rsa.pem
 |
 |should also be valid. 

Yes.  Now i know why i have not tried, because i have

  vpnsub_cleanup   unix  n       -       n       -       0       cleanup
          -o {header_checks=regexp:{{/^Received:/ IGNORE}}}

in there, too.  Likely because of this.
(((It is not a getopt thing, but, yes.)))

 |In this form, no argument starts with "{", and you can avoid the
 |extra "{" and "}"

Dear Wietse Venema, i think postfix's sendmail (?) has a bug in
handling line ending normalization in header continuation lines.
I have updated the postfix-lmdb package i maintain, but just
started up today just now, not yet using it, so i do not know
whether there was any change.

My DKIM failure from last night, it is due to this.

Ie, the MUA i maintain, it practically "does MBOX" (it is older
than the first real email RFC, and much stuff is still not
changed, in effect, at least).  This means it passes (but for
SMTP) an MBOX down the line, with only LF line endings.

So when responding in this thread last night, the line was so long
that it was folded to two lines.  Now it happens that postfix has
recognized it as a continuation (otherwise further headers would
not have been recognized as headers i'd say), and it does
recognize LF as the used line ending (otherwise the entire message
would have been treated as a single line), but the milter has seen
the header like this (chars as decimal):

Mar  6 02:41:29 s-dkim-sign: [2124][crit]: TO IS <subject:Re: [pfx] SOLVED: 
Escaping of braces {} in configuration
Mar  6 02:41:29 s-dkim-sign: [2124][crit]:  (master(5))
Mar  6 02:41:29 s-dkim-sign: [2124][crit]: >
Mar  6 02:41:29 s-dkim-sign: [2124][crit]: [.] 111 110 10 32 40 109 [.]

The line continuation is passed as LF (10).  Therefore my milter
passes the LF through literally (i had asked for that on the IETF
list, explicitly), but this causes this list and Google to fail.
I also simply removed it, but ditto.  It was to late to try to
treat it as normal whitespace, 'will do this evening.  This would
be bogus and not according to the IETF email and DKIM standards,
but it effectively would be the only remaining option to make DKIM
pass, so i actually expect that variant to work out this evening.

Anyway, i felt that it is a bug of postfix in that the line
continuation should also be normalized to CRLF before passing the
header to the milter.  I actually have a hard time, as, as things
stand, any non-SMTP usage of the MUA i maintain in conjunction
with postfix does result in bad DKIM signatures when line
continuation is involved, and that part of the program is due to
be rewritten in the upcoming years, it is quite an effort to get
there regulary.  (As it simply thinks of emails as LF lines.)
I could only hack that in (and thought of offering a switch to
enable this via on-the-fly adjusting when passing data out to the
MTA) for the next release.
I looked at Scott Kitterman's dkimpy, and this did not make me
more happy.  (Even though he uses trim() that eats anything, that
only as a last step, before it is plain \r\n and [\t ].)  Ie, this
would really mean those emails would have broken DKIM signatures
for at least Google and the DKIM verifier of this list here, i had
no time to test Microsoft yet.  (Or other lists.)

Thank you.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to