Ricardo Signes:
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
> t=1412607024; bh=ZJ8Kpz6ZlqWM7sz40HW3fMAm5i4O9s27k2poen3h01U=;
>
> h=Received:Received:Received:X-Yahoo-Newman-Property:X-Yahoo-Newman-Id:X-YMail-OSG:Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Length:From:Subject;
> ...
>
> Putting everything else aside, THEY SIGNED CONTENT-LENGTH.
>
> Unless I am mistaken, cleanup(8) quite reasonably *deletes* Content-Length.
Good catch. Unfortunately, this behavior is not configurable.
Changing Postfix behavior requires either patching one bit in the
executable file, or rebuilding Postfix from source.
RFC 2076 says that Content-Length is non-standard and that its use
is discouraged, mentioning robustness and interoperability problems.
This RFC is contemporary with the start of Postfix implementation.
Content-Length was certainly causing me some problems and that is
why I must have decided to drop it.
By now, maybe is is better to keep this header?
I'll certainly make the "header drop" list configurable. That is
long overdue.
Wietse
--- ./header_opts.c- 2008-05-08 16:41:35.000000000 -0400
+++ ./header_opts.c 2014-10-06 13:04:23.000000000 -0400
@@ -59,7 +59,7 @@
"Content-Description", HDR_CONTENT_DESCRIPTION, HDR_OPT_MIME,
"Content-Disposition", HDR_CONTENT_DISPOSITION, HDR_OPT_MIME,
"Content-ID", HDR_CONTENT_ID, HDR_OPT_MIME,
- "Content-Length", HDR_CONTENT_LENGTH, HDR_OPT_DROP,
+ "Content-Length", HDR_CONTENT_LENGTH, 0,
"Content-Transfer-Encoding", HDR_CONTENT_TRANSFER_ENCODING, HDR_OPT_MIME,
"Content-Type", HDR_CONTENT_TYPE, HDR_OPT_MIME,
"Delivered-To", HDR_DELIVERED_TO, 0,
