I can confirm that the proposed patch fixes the issue. Just tested with
postfix 3.5.7 patched and unpatched.
On 04.11.20 12:18, Wietse Venema wrote:
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
