[pfx] Re: surprise with strict_mime_encoding_domain
On Tue, Apr 04, 2023 at 09:00:16PM +0200, A. Schulze via Postfix-users wrote: > Mime-Version: 1.0 > Content-Type: multipart/signed; > boundary="mua-name=_some_random"; > protocol="application/pkcs7-signature"; > micalg=sha-256 > Content-Transfer-Encoding: quoted-printable This is not valid MIME, "multipart/*" is required to not use any non-identity transfer encodings. It can only be 7bit or 8bit. https://www.rfc-editor.org/rfc/rfc2046#section-5.1 As stated in the definition of the Content-Transfer-Encoding field [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The "multipart" boundary delimiters and header fields are always represented as 7bit US-ASCII in any case (though the header fields may encode non-US-ASCII header text as per RFC 2047) and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] surprise with strict_mime_encoding_domain
Hello, an SMTP Server with strict_mime_encoding_domain=yes blocked some messages (which was ... unexpected) # postconf mail_version mail_version = 3.7.4 # postconf -n alias_maps = maillog_file = /dev/stdout smtpd_recipient_restrictions = defer strict_mime_encoding_domain = yes # postconf -M smtp inet n - - - - smtpd postlogunix-dgram n - - - 1 postlogd proxymap unix - - - - - proxymap rewriteunix - - - - - trivial-rewrite cleanupunix n - - - 0 cleanup # telnet localhost 25 220 d1fdbe288619.localdomain ESMTP Postfix helo localhost 250 d1fdbe288619.localdomain mail from:<> 250 2.1.0 Ok rcpt to: 250 2.1.5 Ok data From: To: Subject: invalid message? Date: Sat, 01 Apr 2023 18:00:00 + Message-Id: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="mua-name=_some_random"; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: quoted-printable --mua-name=_some_random Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 --mua-name=_some_random Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 --mua-name=_some_random-- . 550 5.6.0 invalid message/* or multipart/* encoding domain https://www.postfix.org/postconf.5.html#strict_mime_encoding_domain mention it: "This blocks mail from poorly written software" Well, the MUA is "Apple Mail" ... I can't tell for sure if the message data is valid Mime. Andreas ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
strict_mime_encoding_domain
Pretend I'm an idiot. (For most people who know me this won't be hard.) Could somebody please explain to me... in a way that takes into account my idiocy... what this strict_mime_encoding_domain option actually does, i.e. if you turn it on? What exactly constitutes invalid Content-Transfer-Encoding: information for the message/* or multipart/* MIME content types ? Separate but perhaps related question: Assume that an incoming message includes the following header, either right in the initial headers, or else in the headers of some MIME subpart: Content-Transfer-Encoding: 7bit Assume further than one or more characters in the relevant MIME part actually have their high bits set. Does Postfix have any option that would cause the message in question to be either (a) rejected or else (b) flagged in some way? Regards, rfg P.S. Wietse, I've been keeping my eye open for that signal 11 crash in the local delivery agent that I reported, but it just stopped occuring for some reason. But I've set: /sbin/sysctl kern.sugid_coredump=1 on my FreeBSD system, so in case it ever does happen again, hopefully I'll be able to give you a source filename and lineno. (I really do think that what I saw was probably due to something weird/bad that _I_ must have done. I have some really hairy things being invoked from .forward files on the system in question, and _they_ were probably misbehaving.)
Re: strict_mime_encoding_domain
Ronald F. Guilmette: Pretend I'm an idiot. (For most people who know me this won't be hard.) Could somebody please explain to me... in a way that takes into account my idiocy... what this strict_mime_encoding_domain option actually does, i.e. if you turn it on? It stops some malformed email: legitimate mail that is sent by broken software, and junk that is sent by ratware. What exactly constitutes invalid Content-Transfer-Encoding: information for the message/* or multipart/* MIME content types ? Anything that does not say 7bit or 8bit. The reason is that the MIME headers/boundaries INSIDE message/* or multipart/* must not be obscured by some quoted-printable or base64 encoding. Generally, any MIME type that triggers recursion MUST have Content-Transfer-Encoding: of 7bit or 8bit; it can't be something that corresponds to a transformation. Separate but perhaps related question: Assume that an incoming message includes the following header, either right in the initial headers, or else in the headers of some MIME subpart: Content-Transfer-Encoding: 7bit Assume further than one or more characters in the relevant MIME part actually have their high bits set. Does Postfix have any option that would cause the message in question to be either (a) rejected or else (b) flagged in some way? That would be strict_8bitmime_body, or strict_8bitmime. Wietse
