Viktor Dukhovni:
> On Wed, Nov 04, 2020 at 10:32:57AM -0500, Andreas Weigel wrote:
>
> > Hi everyone,
> >
> > I think I stumbled upon a problem with postfix 3.5.X and very long
> > header lines. To reproduce, I build a very simple setup with two VMs:
> > - "A" running postfix 3.3.0 (xubuntu 18.04 package)
> > - "B" running postfix 3.5.6 (xubuntu 20.10 package)
> >
>
> Yes, this looks like a bug introduced in Postfix 3.5 via:
>
> 20190615
>
> Feature: SMTP/LMTP client support for 'D', 'O', 'R', 'X'
> flags similar to the pipe(8) daemon, to produce Delivered-To,
> X-Original-To, and Return-Path headers, and to indicate
> final delivery. Files: smtp/smtp.c, smtp/smtp.h, smtp/smtp_misc.c,
> smtp/smtp_proto.c, smtp/smtp_rcpt.c.
>
> The new code that handles adding those headers was also reused to emit
> all headers, incorrectly including logical headers that span multiple
> physical lines:
>
>
> https://github.com/vdukhovni/postfix/commit/2ff7c91a461a093ff7a04a2ea9d1d3c0f1376243#diff-0e8480070aeb81a843eb195dc510a864f404ea03c5cdd597c6e00ab98d08de1cR2307-R2313
>
> The value of "rec_type" needs to be passed to smtp_out_raw_or_mime() and
> the output processed accordingly. Untested patch below:
Thanks, the untested patch passes the eyeball test. I introduced
an error that lost the queue file record type. Generating new headers
as REC_TYPE_NORM was OK, but losing the extsing record types was not.
Can the bug reporter confirm that this addresses the issue? Making
this automatically testatble will take some time.
Wietse