https://bugs.exim.org/show_bug.cgi?id=166
Michael Evans <mjevans1983@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mjevans1983@???
--- Comment #2 from Michael Evans <mjevans1983@???> ---
What I need is just one small option flag for this router:
headers_continue
Default False; when set to True the delimiting double-CRLF between the "header"
and "body" sections would be suppressed.
Setting that to true would allow the use of MIME encoding libraries as well as
not statically encoding the global MIME escape character in the configuration
and in the generation of message reply files. This would be MUCH more
//secure// than re-using MIME boundary parts. It would also, hopefully, be
back-portable to stable Debian releases.
This could be a security issue in contexts where un-trusted users contribute
anything to the reply data, I'm having trouble thinking of an example offhand.
However I'm not willing to say that it'd never be exploitable.
The above would make sending a MIME encoded multipart message body as a secure
option.
My current understanding is that such a message should look something like
this:
From: <example@???>
To: <example@???>
Subject: Example Multipart
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BLAH"
--BLAH
Content-Type: multipart/alternative; boundary="OHNO"
--OHNO
Content-Type: multipart/text; charset="utf-8"
Content-Transfer-Encoding; quoted-printable
The text and marked up versions are supposed to be equivalent.
--OHNO
Content-Type: text/html;charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<html><body><p>The text and marked up versions are supposed to be
equivalent.</p></body></html>
--OHNO
--BLAH
Content-Type: image/jpgeg;name="somefile.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline;filename="somefile.png"
Content-ID: <file@what?>
Encoded file goes here. Look this up if necessary
...
--BLAH
.
--
You are receiving this mail because:
You are the QA Contact for the bug.
