https://bugs.exim.org/show_bug.cgi?id=166
--- Comment #4 from Michael Evans <mjevans1983@???> ---
headers_continue (default false) when set to true would skip sending that extra
empty line and allow the file text inclusions to also contain any arbitrary
header data. That seems like the easiest, most forward compatible, and most
useful way of allowing this desired change. The precise wording of the option
is also clear and self-documenting. The headers continue (past what Exim sets
by default/has been instructed to otherwise add).
Observing my existing configuration, Exim sets the following headers (to
expected values) From, To, Subject, In-Reply-To, References, Auto-Submitted.
In my configuration I'm providing the to, from, headers, subject,
(return_message = false) and file arguments.
Yes, that moves the security model to trusting the file content, but reading a
file from the mail server's disk should be similar to including another
configuration file, which is also allowed. Other mechanisms external to the
mail daemon can be used to create the desired file and this doesn't actually
change the flow of behavior. It just makes it far easier to modify the
remainder of the mail envelope. The exact format of the included data is, as
before, still not validated or modified otherwise.
I'm not sure how difficult adding a single configuration is, but the actual
logic change would be...
https://github.com/Exim/exim/blob/master/src/src/transports/autoreply.c
On line 655. if (!headers_continue) fprintf(fp, "\n");
There'd be corresponding variable handling and true/false evaluation at about
line 350 above, and anything else required to add the option to the
configuration validation process.
Aside from the impact to applying security updates, I'm actually considering
rebuilding the package locally to just unconditionally apply it since I'm not
using the autoreply transport otherwise.
--
You are receiving this mail because:
You are the QA Contact for the bug.
