John Levine:
> It appears that Wietse Venema <postfix-users@postfix.org> said:
> >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.
>
> Since most other MTAs don't suport BINARYMIME, you'd need some way
> to sniff the recipient server and then rewrite the binary parts
> as base64 before sending the message, recomputing any DKIM and ARC
> signatures on the way. Have fun with that.
That might work for one-to-one messages, but not for one-to-many.
A more general solution would convert and sign during delivery. Not
fun, but technically possible.
> BINARYMIME avoids the 33% size increase of base64. If people cared
> about that, since every MTA now supports 8BITMIME it would be easy
> to invent a quoted-unprintable content-transfer-encoding which
> escaped only the few characters that are special in 8BITMIME (CR
> LF NUL and to be on the safe side, 0xff.) That would get you about
> 98% of the way to binary with 2% of the work.
This would turn binary content into a long line. That works perfectly
with qmail and Postfix (except that the Postfix SMTP client will
need a hint to avoid folding such lines at the 998 octet limit of
RFC 5321).
Wietse
