Dominic Raferd:
> On 18/06/2020 17:17, Dominic Raferd wrote:
> > On Thu, 18 Jun 2020 at 15:03, Wietse Venema <wie...@porcupine.org> wrote:
> >> Dominic Raferd:
> >>> I understand the reason for smtp_line_length_limit and for its default
> >>> value of 998, which is of course good.
> >> It breaks DKIM signatures, it is needed only for mail that is sent
> >> via SMTP, and worse, it breaks lines in the middle of a multibyte
> >> character (and of course in the middle of a word, in the middle of
> >> an HTML tag, and so on). So it really shuod not be considered a
> >> reliable solution.
> >>
> >> The main reason smtp_line_length_limit exists is to prevent other
> >> MTAs from breaking MIME-formatted mail, where one huge message
> >> header could cause all message content to become exposed in the
> >> underlying encoding (base64 or quoted-printable).
> >>
> >> If your problem is with cron job outputs that aren't sent across
> >> the Internet, you could just disable this behavior by setting the
> >> limit to zero, and by configuring other MTAs similarly.
> >>
> >> Alternatively, as these cron jobs are under local control, you could
> >> massage their output through a program that fixes long lines.
> >>
> > Thanks for your answer and explanation.
> >
> > Your second suggestion is what I do, but it is difficult to catch all
> > instances. I have now followed your first and set the limit to zero
> > (which I believe is undocumented as a way to turn off automatic
> > line-breaking). Actually I am relaying into Gmail so it will be
> > interesting to see if it copes with overlong lines.
> For information: setting smtp_line_length_limit = 0 works, however 
> having such a long line (in the mail body) still breaks the DKIM 
> signature. There must be something else going on (presumably unrelated 
> to postfix).

DKIM requires well-formatted email, and that includes respecting
any limits for transmission protocols. Again, there must be better
ways to do this than Postfix's line breaking of last resort: inserting
<CR><LF><SPACE> in a string in the middle of some multibyte character
or word.

Perhaps attaching the cronjob's output with 'mailx -a file.type'
is an option (where the filename suffix matches a rule in a MIME
type file; hopefully it will base64 encode the content). There is
a lot more about MIME in the Heirloom mailx manpage.

        Wietse

Reply via email to