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