https://bugs.exim.org/show_bug.cgi?id=166
Michael Evans <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Michael Evans <[email protected]> --- 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: <[email protected]> To: <[email protected]> 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
