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

Reply via email to