Thus said Ken Hornstein on Mon, 20 Feb 2023 21:11:48 -0500: > Facinating! I am curious: who/what sent this to you! Do you remember > the MIME type?
0.11 % (percent) of my messages have Content-Transfer-Encoding of binary at the beginning of the line somewhere in the message. Here are the headers from one that dates all the way back to 2001 (this message does not appear to have any actual "binary" content in it). -------------------------------BEGIN------------------------------------ Content-Type: multipart/mixed; boundary="----------=_154292612-6290-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) From: "Jato Boa" <j...@earthlink.net> Date: Xxx, 00 Xxx 2001 16:09:27 +0800 This is a multi-part message in MIME format... ------------=_154292612-6290-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline [ascii data] ------------=_154292612-6290-0 Content-Type: image/jpg; name="OosI Fric Ghesuf kurfIzKi chruzGi Awt.jpg" Content-Disposition: attachment; filename="OosI Fric Ghesuf kurfIzKi chruzGi Awt.jpg" Content-Transfer-Encoding: base64 [base64 data] -------------------------------END-------------------------------------- Also, I have quite a few from the Bugtraq mailing list that have a C-T-E of binary. The headers indicate binary, but the rest of the body doesn't seem to imply it (doesn't need it probably), but then there are some like this: https://seclists.org/bugtraq/2004/Aug/223 Here are relevant headers and the binary values were replaced with <HEX>: -------------------------------BEGIN------------------------------------ Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: "J<E9>r<F4>me" ATHIAS <jerome.ath...@caramail.com> To: bugt...@securityfocus.com Subject: First vulnerabilities in the SP2 - XP ?... X-Spam-BMF-Status: No, hits=0.000000 required=0.900000 http://www.heise.de/security/artikel/50051 Regards, J<E9>r<F4>me ATHIAS -------------------------------END-------------------------------------- Today, I think this message would instead be quoted-printable or some other encoding. Here's another example from a well known online seller of goods that used messagelabs to send out customer order statuses: -------------------------------BEGIN------------------------------------ Content-Transfer-Encoding: binary Content-Type: multipart/related; boundary="_----------=_79242061420" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.01 (F2.72; A1.60; B2.21; Q2.21) Date: Xxx, 00 Xxx 0000 16:36:04 UT From: [online store redacted] This is a multi-part message in MIME format. --_----------=_79242061420 Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="_----------=_79242061421" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.01 (F2.72; A1.60; B2.21; Q2.21) Date: Xxx, 00 Xxx 0000 16:36:04 UT This is a multi-part message in MIME format. --_----------=_79242061421 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 3.01 (F2.72; A1.60; B2.21; Q2.21) Date: Xxx, 00 Xxx 0000 16:36:04 UT [quoted printable data] -------------------------------END-------------------------------------- Here's a more recent email from another online provider of services with <HEX> replaced where binary value was found: -------------------------------BEGIN------------------------------------ Content-Type: text/html Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) ... <tr> <td style=" mso-table-lspace:0pt; mso-table-rspace:0pt; line-height:26px; text-align:center; font-size:13px; border:0px;"> Copyright <C2><A9> 2021 ... -------------------------------END-------------------------------------- Are these bugs in email client implementations? I've looked at a handful of the messages that I have which have a header of C-T-E binary and the body of the message is almost always some other C-T-E (mostly quoted-printable) or non-binary. But sometimes it seems justified. Maybe they just throw the C-T-E on there "just in case" as a sloppy way of getting by? > I guess what I was hoping for was a consensus on what we SHOULD do > when we encounter a NUL byte, because I haven't heard that yet! Like > what should the code do, precisely? I'm not sure. Does any one have any example of having received a NUL byte in an email? I'm having a hard time convincing grep to look for one. Andy
