Demi Marie Obenour: > How useful would BINARYMIME support be? It does mean that DKIM signing > would need to be done in the sending path, but I cannot think of any > reasons that would be a blocker. Having DKIM and DMARC built-in to > Postfix would be a nice feature, tbh. The only open-source MTA I > know of with built-in DKIM is Exim but I would never dare use it in > production. > > Ideally, the signing keys should be in a separate process for privilege > separation, but Postfix is already multi-process so that should be > doable. Of course, the final decision is up to Wietse.
See also https://github.com/OpenSMTPD/OpenSMTPD/issues/1090 I haven't had the time to properly analyze what this would take. Here's a first inventory. - Background: there is no 1:1 relationship between BINARYMIME chunks and MIME segments. One incoming BINARYMIME chunk can contain any combination of MIME text segments and MIME binary segments, and one large MIME segment can span multiple chunks. - Background: Postfix does not store text line endings (<LF> or <CR><LF>) internally. When receiving mail, the Postfix SMTP server strips <CR><LF> line endings from text, and the Postfix sendmail command strips <LF> line endings when ingesting mail submitted with UNIX command-line tools. When delivering mail, Postfix appends <LF> line endings when writing message text to a UNIX file or command, and Postfix appends <CR><LF> line endings when writing message text to a remote SMTP server. Line endings are not a message property; instead, they are a property of the external environment, to be added by Postfix delivery agents and to be stripped by Postfix mail receiving programs. - Impact: in a receiving Postfix server, the Postfix MIME parser needs to be changed to strip <CR><LF> line endings from MIME headers and from lines in MIME text segments, and the Postfix SMTP server needs to be changed to stop stripping those <CR><LF> line endings. - Impact: the Postfix MIME parser needs new support for 'type binary' MIME body content, and it must parse such content not as lines of text ending in <CR><LF><CR><LF>--boundary-string", but as a binary blob with a length determined by a preceding Content-Length MIME header. - Impact: binary blobs need to be passed around internally in Postfix as a new type of record, so that they remain distinct from Postfix text records. Specifically, the smtpd daemon sends BINARYMIME chunks as blobs to the cleanup daemon (and maybe also other message content). - The impact on Milters or other extrnal content filters is unknown. - The impact on smtpd_proxy_filter is unknown. Currently, the Postfix SMTP daemon replaces a sequence of BDAT commands with a single DATA command. That can't work with BINARYMIME, because BINARYMIME is fundamentally incompatible with DATA. - The impact on UNIX mailbox stores is unknown (these store multiple messages per file). Every mail reading program will have to understand MIME and will have to parse Content-Length: headers or else it will be hopelessly confused about where a message ends. That's just a few things off the top of my head.:1 Wietse
