• PGP/MIME transfer encoding (was: Better colorscheme than Solarized?)

    From Michael =?ISO-8859-1?Q?B=E4uerle?=@michael.baeuerle@stz-e.de to comp.misc on Mon Oct 17 13:22:13 2022
    From Newsgroup: comp.misc

    Spiros Bousbouras wrote:
    On 16 Oct 2022 13:18:25 -0000
    kludge@panix.com (Scott Dorsey) wrote:
    In article <Z2xjxj6GLU0cTiaJR@bongo-ra.co>,
    Spiros Bousbouras <spibou@gmail.com> wrote:

    My guess is that what's causing problems for some people is that Hawk's posts
    are BASE64 encoded. I don't know why Thunderbird does that but there do exist
    news.software.newsreaders and alt.comp.software.newsreaders for such questions.

    They are BASE64 encoded because they are MIME-packed. They are MIME-packed for the reasons mentioned above, that the signature contains high bit chars and PGP signing is enabled. When you turn PGP signing on, the signature is not just appended to the file but sent as a MIME enclosure. Because there are high bit chars, that MIME enclosure gets BASE64ed.

    Is there some RFC which says that it has to be encoded ? In other words , if <thbc1u$1kurt$16@dont-email.me> had

    [...]
    --------------Tt8my9EQNXhQlE93lqBKz0mM
    Content-Type: multipart/mixed; boundary="------------mmNZ03EhTrk2EIAXSj0QuBYT"

    --------------mmNZ03EhTrk2EIAXSj0QuBYT
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit

    Hello!

    I'm looking for a color scheme that's better than Solarized. While i
    [...]
    /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
    [...]
    --------------mmNZ03EhTrk2EIAXSj0QuBYT
    Content-Type: application/pgp-keys; name="OpenPGP_0x0D8C69D9C42BA5C8.asc" Content-Disposition: attachment; filename="OpenPGP_0x0D8C69D9C42BA5C8.asc" Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable
    [...]

    , would it violate any RFC ?

    RFC 3156 says:
    <https://datatracker.ietf.org/doc/html/rfc3156#section-3>
    |
    | 3. Content-Transfer-Encoding restrictions
    |
    | Multipart/signed and multipart/encrypted are to be treated by agents
    | as opaque, meaning that the data is not to be altered in any way [2],
    | [7]. However, many existing mail gateways will detect if the next
    | hop does not support MIME or 8-bit data and perform conversion to
    | either Quoted-Printable or Base64. This presents serious problems
    | for multipart/signed, in particular, where the signature is
    | invalidated when such an operation occurs. For this reason all data
    | signed according to this protocol MUST be constrained to 7 bits (8-
    | bit data MUST be encoded using either Quoted-Printable or Base64).

    The example above would violate the "MUST be constrained to 7 bits".
    But QP transfer encoding (instead of Base64) should be allowed.


    [Subject adjusted]
    --- Synchronet 3.19c-Linux NewsLink 1.113
  • From Spiros Bousbouras@spibou@gmail.com to comp.misc on Mon Oct 17 15:53:10 2022
    From Newsgroup: comp.misc

    On Mon, 17 Oct 2022 13:22:13 +0200 (CEST)
    Michael Bäuerle <michael.baeuerle@stz-e.de> wrote:
    Spiros Bousbouras wrote:
    Is there some RFC which says that it has to be encoded ? In other words , if
    <thbc1u$1kurt$16@dont-email.me> had

    [...]
    --------------Tt8my9EQNXhQlE93lqBKz0mM
    Content-Type: multipart/mixed; boundary="------------mmNZ03EhTrk2EIAXSj0QuBYT"

    --------------mmNZ03EhTrk2EIAXSj0QuBYT
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit

    Hello!

    I'm looking for a color scheme that's better than Solarized. While i
    [...]
    /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
    [...]
    --------------mmNZ03EhTrk2EIAXSj0QuBYT
    Content-Type: application/pgp-keys; name="OpenPGP_0x0D8C69D9C42BA5C8.asc" Content-Disposition: attachment; filename="OpenPGP_0x0D8C69D9C42BA5C8.asc" Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable
    [...]

    , would it violate any RFC ?

    RFC 3156 says:
    <https://datatracker.ietf.org/doc/html/rfc3156#section-3>
    |
    | 3. Content-Transfer-Encoding restrictions
    |
    | Multipart/signed and multipart/encrypted are to be treated by agents
    | as opaque, meaning that the data is not to be altered in any way [2],
    | [7]. However, many existing mail gateways will detect if the next
    | hop does not support MIME or 8-bit data and perform conversion to
    | either Quoted-Printable or Base64. This presents serious problems
    | for multipart/signed, in particular, where the signature is
    | invalidated when such an operation occurs. For this reason all data
    | signed according to this protocol MUST be constrained to 7 bits (8-
    | bit data MUST be encoded using either Quoted-Printable or Base64).

    The example above would violate the "MUST be constrained to 7 bits".
    But QP transfer encoding (instead of Base64) should be allowed.

    I see. That's a bummer. The same RFC says
    Implementor's note: It cannot be stressed enough that applications
    using this standard follow MIME's suggestion that you "be
    conservative in what you generate, and liberal in what you
    accept." In this particular case it means it would be wise for an
    implementation to accept messages with any content-transfer-
    encoding, but restrict generation to the 7-bit format required by
    this memo. This will allow future compatibility in the event the
    Internet SMTP framework becomes 8-bit friendly.

    Given that the RFC is from 2001 , I wonder if the Internet SMTP framework
    has become 8-bit friendly by now.
    --- Synchronet 3.19c-Linux NewsLink 1.113
  • From Michael =?ISO-8859-1?Q?B=E4uerle?=@michael.baeuerle@stz-e.de to comp.misc on Wed Oct 19 10:25:48 2022
    From Newsgroup: comp.misc

    Spiros Bousbouras wrote:
    Michael Bäuerle wrote:
    Spiros Bousbouras wrote:

    Is there some RFC which says that it has to be encoded ? In other words , if
    <thbc1u$1kurt$16@dont-email.me> had

    [...]
    --------------Tt8my9EQNXhQlE93lqBKz0mM
    Content-Type: multipart/mixed; boundary="------------mmNZ03EhTrk2EIAXSj0QuBYT"

    --------------mmNZ03EhTrk2EIAXSj0QuBYT
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit

    Hello!

    I'm looking for a color scheme that's better than Solarized. While i [...]
    /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
    [...]
    --------------mmNZ03EhTrk2EIAXSj0QuBYT
    Content-Type: application/pgp-keys; name="OpenPGP_0x0D8C69D9C42BA5C8.asc" Content-Disposition: attachment; filename="OpenPGP_0x0D8C69D9C42BA5C8.asc"
    Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable
    [...]

    , would it violate any RFC ?

    RFC 3156 says:
    <https://datatracker.ietf.org/doc/html/rfc3156#section-3>
    |
    | 3. Content-Transfer-Encoding restrictions
    |
    | Multipart/signed and multipart/encrypted are to be treated by agents
    | as opaque, meaning that the data is not to be altered in any way [2],
    | [7]. However, many existing mail gateways will detect if the next
    | hop does not support MIME or 8-bit data and perform conversion to
    | either Quoted-Printable or Base64. This presents serious problems
    | for multipart/signed, in particular, where the signature is
    | invalidated when such an operation occurs. For this reason all data
    | signed according to this protocol MUST be constrained to 7 bits (8-
    | bit data MUST be encoded using either Quoted-Printable or Base64).

    The example above would violate the "MUST be constrained to 7 bits".
    But QP transfer encoding (instead of Base64) should be allowed.

    I see. That's a bummer. The same RFC says
    Implementor's note: It cannot be stressed enough that applications
    using this standard follow MIME's suggestion that you "be
    conservative in what you generate, and liberal in what you
    accept." In this particular case it means it would be wise for an
    implementation to accept messages with any content-transfer-
    encoding, but restrict generation to the 7-bit format required by
    this memo. This will allow future compatibility in the event the
    Internet SMTP framework becomes 8-bit friendly.

    Given that the RFC is from 2001 , I wonder if the Internet SMTP framework
    has become 8-bit friendly by now.

    There is the "8BITMIME" extension defined in RFC 6152: <https://www.rfc-editor.org/rfc/rfc6152>
    This should in theory allow to use SMTP as an 8-bit clean transport
    protocol.

    There ist the "SMTPUTF8" extension defined in RFC 6531: <https://www.rfc-editor.org/rfc/rfc6531>
    This is a complete new Unicode-based message format intended to be used
    with "8BITMIME" transport.

    But even big companies are not able (or more likely not willing) to
    implement it correctly. Maybe it is undesired that mail works well,
    because commercial actors want to push their proprietary products
    (that are intentionally not based on open standards and provide no interoperability to create a lock-in effect).
    --- Synchronet 3.19c-Linux NewsLink 1.113