On 3/21/21 8:13 PM, John Levine wrote:
> It appears that Wietse Venema said:
>> With uniform or compressed payloads, 256 bytes become 261 on average,
>> thus it takes 978.9 bytes on average to expand into 998. Add CR
>> and LF to the 998, and we have an expansion of 1000/978.9=1.022 or
>> just a
John Levine:
> It appears that Wietse Venema said:
> >With uniform or compressed payloads, 256 bytes become 261 on average,
> >thus it takes 978.9 bytes on average to expand into 998. Add CR
> >and LF to the 998, and we have an expansion of 1000/978.9=1.022 or
> >just a little over 2%.
>
> That
It appears that Wietse Venema said:
>With uniform or compressed payloads, 256 bytes become 261 on average,
>thus it takes 978.9 bytes on average to expand into 998. Add CR
>and LF to the 998, and we have an expansion of 1000/978.9=1.022 or
>just a little over 2%.
That was my estimate too. I was
On Sun, Mar 21, 2021 at 07:25:31PM -0400, Demi Marie Obenour wrote:
> Another approach would be to create a “wrapped” MIME type that
> just wraps another message in base64. That has the advantage of
> working with multipart/signed et al. quoted-printable also has line
> continuations.
It is an
On 3/21/21 2:25 PM, Wietse Venema wrote:
> John Levine:
>> It appears that Wietse Venema 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
On Sun, Mar 21, 2021 at 04:38:56PM -0400, Wietse Venema wrote:
> With non-uniform input, or with input from a smaller alphabet, I
> expect that YMMV (the expansion can be less or more than 2%). For
> example 1000 null bytes expand into 2000 (100%), and when content
> requires no escaping, 998 byte
John Levine:
> It appears that Wietse Venema said:
> >> 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 characte
It appears that Wietse Venema said:
>> 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
John Levine:
> It appears that Wietse Venema 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
It appears that Wietse Venema 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 n
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 MT
On 3/20/21 2:51 PM, John Levine wrote:
> It's defined in RFC 3030. Read all about it:
> https://www.rfc-editor.org/info/rfc3030
>
> It happens that I just added CHUNKING and BDAT to an MTA I use (mailfront if
> you know
> what that is.) Inbound the code is quite simple and I would be surprised
12 matches
Mail list logo
