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 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 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