Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.software.thunderbird > #20942 > unrolled thread

Betterbird has same problem as Thunderbird

Back to article view | Back to alt.comp.software.thunderbird

Contents

  Betterbird has same problem as Thunderbird "Adam H. Kerman" <ahk@chinet.com> - 2026-06-20 15:46 +0000
    Re: Betterbird & Base64 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-21 00:05 +0800
      Re: Betterbird & Base64 "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-06-20 17:17 +0100
        Re: Betterbird & Base64 "Adam H. Kerman" <ahk@chinet.com> - 2026-06-20 16:32 +0000
          Re: Betterbird & Base64 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-21 01:00 +0800
          Re: Betterbird & Base64 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-21 01:10 +0800
    Re: Betterbird has same problem as Thunderbird sticks <wolverine01@charter.net> - 2026-06-20 12:15 -0500
      Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-20 19:59 +0100
        Re: Betterbird has same problem as Thunderbird Paul <nospam@needed.invalid> - 2026-06-21 04:59 -0400
          Re: Betterbird has same problem as Thunderbird Alfred Peters <miteinere-mail-adresseindereinleitungszeilewirddieseoftzulang@geekmail.de> - 2026-06-21 11:15 +0200
          Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-21 10:18 +0100
            Re: Betterbird has same problem as Thunderbird "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-06-21 19:55 +0100
              Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-21 20:11 +0100
                Re: Betterbird has same problem as Thunderbird "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-06-21 20:50 +0100
                  UTF-8 (was: Betterbird has same problem as Thunderbird) Marcel Logen <333200007110-0201@ybtra.de> - 2026-06-22 00:00 +0200
                    Re: UTF-8 "J. P. Gilliver" <G6JPG@255soft.uk> - 2026-06-22 01:41 +0100
    Re: Betterbird has same problem as Thunderbird Jörg Knobloch <jorgk@jorgk.com> - 2026-06-20 20:58 +0200
      Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-20 20:02 +0100
        Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-20 20:03 +0100
      Re: Betterbird has same problem as Thunderbird "Adam H. Kerman" <ahk@chinet.com> - 2026-06-20 19:25 +0000
    Re: Betterbird has same problem as Thunderbird Ralph Fox <-rf-nz-@-.invalid> - 2026-06-21 08:02 +1200
      Re: Betterbird has same problem as Thunderbird "Adam H. Kerman" <ahk@chinet.com> - 2026-06-21 00:13 +0000
    Re: Betterbird has same problem as Thunderbird Alfred Peters <miteinere-mail-adresseindereinleitungszeilewirddieseoftzulang@geekmail.de> - 2026-06-21 10:05 +0200
      Re: Betterbird has same problem as Thunderbird Alfred Peters <miteinere-mail-adresseindereinleitungszeilewirddieseoftzulang@geekmail.de> - 2026-06-21 10:11 +0200
        Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-21 09:34 +0100
          Re: Betterbird has same problem as Thunderbird Alfred Peters <miteinere-mail-adresseindereinleitungszeilewirddieseoftzulang@geekmail.de> - 2026-06-21 10:55 +0200
      Re: Betterbird has same problem as Thunderbird Andy Burns <usenet@andyburns.uk> - 2026-06-21 09:26 +0100
        Re: Betterbird has same problem as Thunderbird "Carlos E. R." <robin_listas@es.invalid> - 2026-06-21 13:11 +0200
          Re: Betterbird has same problem as Thunderbird Jörg Knobloch <jorgk@jorgk.com> - 2026-06-21 14:29 +0200
          Re: Betterbird has same problem as Thunderbird Alfred Peters <miteinere-mail-adresseindereinleitungszeilewirddieseoftzulang@geekmail.de> - 2026-06-21 17:33 +0200
            Re: Betterbird has same problem as Thunderbird "Carlos E. R." <robin_listas@es.invalid> - 2026-06-21 19:27 +0200
    [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-21 20:54 +0800
      Re: [OT] Oranges <Oranges@invalid.invalid> - 2026-06-22 00:05 +0100
        Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-22 13:14 +0800
        Re: [OT] Paul <nospam@needed.invalid> - 2026-06-22 03:11 -0400
          Re: [OT] "Adam H. Kerman" <ahk@chinet.com> - 2026-06-22 07:57 +0000
            Re: [OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-22 18:55 +0800
            [OT]troll? trope? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-06-22 19:22 +0800
            Re: [OT] Paul <nospam@needed.invalid> - 2026-06-22 10:25 -0400
              Re: [OT] "Adam H. Kerman" <ahk@chinet.com> - 2026-06-22 14:47 +0000
                Re: [OT] Paul <nospam@needed.invalid> - 2026-06-22 16:03 -0400
                  Re: [OT] "Adam H. Kerman" <ahk@chinet.com> - 2026-06-23 02:35 +0000
                    Re: [OT] "Carlos E. R." <robin_listas@es.invalid> - 2026-06-23 19:53 +0200

Page 1 of 3  [1] 2 3  Next page →

#20942 — Betterbird has same problem as Thunderbird

Undesireable Base64 encoding, which does not belong on Usenet, and upon
decoding, the line boundaries are nonstandard.

Message-ID: <n9nlh8F30qfU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
User-Agent: Betterbird (Linux)

[toc] | [next] | [standalone]

#20943 — Re: Betterbird & Base64

On 6/20/2026 11:46 PM, Adam H. Kerman wrote:
> Undesireable Base64 encoding, which does not belong on Usenet, and upon
> decoding, the line boundaries are nonstandard.

What the BANG!! is Base64? Why do you use it? Talking about inline 
attachment? That's Outlook Express!

-- 

    @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
   / v \  May the Force and farces be with you! Live long and prosper!!
  /( _ )\ https://sites.google.com/site/changmw/
    ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#20944 — Re: Betterbird & Base64

On 2026/6/20 17:5:0, Mr. Man-wai Chang wrote:
> On 6/20/2026 11:46 PM, Adam H. Kerman wrote:
>> Undesireable Base64 encoding, which does not belong on Usenet, and upon
>> decoding, the line boundaries are nonstandard.
> 
> What the BANG!! is Base64? Why do you use it? Talking about inline 
> attachment? That's Outlook Express!
> 
By inline attachment, do you mean (for example) where a picture appears
to be embedded into an email/post, with some of the text before it and
some after?

And if so, do you mean _true_ inline attachment, which Turnpike was the
only software I knew that could do it (making something that moat other
clients couln't understand), or _apparent_ inline attachment, where at
the desired picture location a marker was placed, the actual picture
still being placed at the end of the message (Which is what I think OE =
and most other clients - did)?
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

[toc] | [prev] | [next] | [standalone]

#20945 — Re: Betterbird & Base64

J. P. Gilliver <G6JPG@255soft.uk> wrote:
>On 2026/6/20 17:5:0, Mr. Man-wai Chang wrote:
>>On 6/20/2026 11:46 PM, Adam H. Kerman wrote:

>>>Undesireable Base64 encoding, which does not belong on Usenet, and upon
>>>decoding, the line boundaries are nonstandard.

>>What the BANG!! is Base64? Why do you use it? Talking about inline 
>>attachment? That's Outlook Express!

>By inline attachment, . . . 

Would the two of you be so kind as to discuss attachments in an
unrelated thread?

I am requesting followups discussing the topic I raised.

[toc] | [prev] | [next] | [standalone]

#20946 — Re: Betterbird & Base64

On 6/21/2026 12:32 AM, Adam H. Kerman wrote:
> 
> Would the two of you be so kind as to discuss attachments in an
> unrelated thread?
> 
> I am requesting followups discussing the topic I raised.
> 
> Message-ID: <n9nlh8F30qfU1@mid.individual.net>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: base64
> User-Agent: Betterbird (Linux)

Back to your email problem:

Did soemthing mess up the message's header? by special methods?
Or was it a transmission error?

-- 

    @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
   / v \  May the Force and farces be with you! Live long and prosper!!
  /( _ )\ https://sites.google.com/site/changmw/
    ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#20947 — Re: Betterbird & Base64

On 6/21/2026 12:32 AM, Adam H. Kerman wrote:
> 
> Would the two of you be so kind as to discuss attachments in an
> unrelated thread?
BTW, if it's just an erratic attachment (inline or not), ask the sender 
to re-send.

If the sender lost the attachment, or the sender had suddenly 
disappeared, then you need to decode/decrypt the base64 token/message 
manually with tools.

-- 

    @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
   / v \  May the Force and farces be with you! Live long and prosper!!
  /( _ )\ https://sites.google.com/site/changmw/
    ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#20948

On 6/20/2026 10:46 AM, Adam H. Kerman wrote:
> Undesireable Base64 encoding, which does not belong on Usenet, and upon
> decoding, the line boundaries are nonstandard.
> 
> Message-ID: <n9nlh8F30qfU1@mid.individual.net>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: base64
> User-Agent: Betterbird (Linux)

Check mine AHK.  I'm not on linux, but when I checked before my encoding 
using BBird was 8bit, which I think is OK?  I do use format flowed which 
is marginally OK?

My sending format is set to "Only Plain Text"


-- 
Science Doesn’t Support Darwin. Scientists Do

[toc] | [prev] | [next] | [standalone]

#20951

sticks wrote:

> Adam H. Kerman wrote:
> >> Undesireable Base64 encoding, which does not belong on Usenet, and upon
>> decoding, the line boundaries are nonstandard.

Unsurprising, since BB is based on TB.

>> Message-ID: <n9nlh8F30qfU1@mid.individual.net>
>> Mime-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>> Content-Transfer-Encoding: base64
>> User-Agent: Betterbird (Linux)
> 
> Check mine AHK.  I'm not on linux, but when I checked before my encoding 
> using BBird was 8bit, which I think is OK?  I do use format flowed which 
> is marginally OK?

TB doesn't take much 'provoking' into deciding it needs to use base64 
because of a stray weird character, I can't remember an example of what 
does it, and it may depend on the content type/encoding of the message 
being replied to.

> My sending format is set to "Only Plain Text"
Seeing the msgid being referred to, I assume it's the sharp-s in the 
original body text, rather than the umlaut in the subject, which was 
Q-encoded.

[toc] | [prev] | [next] | [standalone]

#20965

On Sat, 6/20/2026 2:59 PM, Andy Burns wrote:
> sticks wrote:
> 
>> Adam H. Kerman wrote:
>> >> Undesireable Base64 encoding, which does not belong on Usenet, and upon
>>> decoding, the line boundaries are nonstandard.
> 
> Unsurprising, since BB is based on TB.
> 
>>> Message-ID: <n9nlh8F30qfU1@mid.individual.net>
>>> Mime-Version: 1.0
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>> Content-Transfer-Encoding: base64
>>> User-Agent: Betterbird (Linux)
>>
>> Check mine AHK.  I'm not on linux, but when I checked before my encoding using BBird was 8bit, which I think is OK?  I do use format flowed which is marginally OK?
> 
> TB doesn't take much 'provoking' into deciding it needs to use base64 because of a stray weird character, I can't remember an example of what does it, and it may depend on the content type/encoding of the message being replied to.
> 
>> My sending format is set to "Only Plain Text"
> Seeing the msgid being referred to, I assume it's the sharp-s in the original body text, rather than the umlaut in the subject, which was Q-encoded.

It's possible the body text is not parsing correctly. Should the
0xC3 0x9F have some escape sequence in front of them ? There is no
marker at the beginning of the text.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  48 69 20 61 6C 6C 2C 0D 0A 0D 0A 54 77 6F 20 65  Hi all,....Two e
00000010  6D 70 74 79 20 66 72 65 69 67 68 74 20 74 72 61  mpty freight tra
00000020  69 6E 73 20 63 6F 6C 6C 69 64 65 64 20 77 68 69  ins collided whi
00000030  6C 73 74 20 73 68 75 6E 74 69 6E 67 20 61 74 20  lst shunting at
00000040  61 70 70 72 6F 78 2E 20 30 31 3A 34 30 20 6F 6E  approx. 01:40 on
00000050  20 0D 0A 32 30 2E 30 36 2E 32 36 2E 20 53 61 64   ..20.06.26. Sad
00000060  6C 79 20 6F 6E 65 20 73 74 61 66 66 20 6D 65 6D  ly one staff mem
00000070  62 65 72 20 77 61 73 20 6B 69 6C 6C 65 64 20 28  ber was killed (
00000080  61 20 73 68 75 6E 74 65 72 3F 29 2E 20 54 77 6F  a shunter?). Two
00000090  20 65 6C 65 6D 65 6E 74 73 20 0D 0A 6F 66 20 74   elements ..of t
000000A0  68 65 20 77 61 67 6F 6E 73 20 66 65 6C 6C 20 6F  he wagons fell o
000000B0  6E 74 6F 20 53 63 68 6C 65 69 C3 9F 68 65 69 6D  nto Schleißheim
                                        ^^^^^
000000C0  65 72 20 53 74 72 61 C3 9F 65 20 62 65 6C 6F 77  er Straße below
                               ^^^^^
000000D0  2E 0D 0A 0D 0A 3C 68 74 74 70 73 3A 2F 2F 77 77  .....<https://ww
000000E0  77 2E 62 72 2E 64 65 2F 6E 61 63 68 72 69 63 68  w.br.de/nachrich
000000F0  74 65 6E 2F 62 61 79 65 72 6E 2F 6D 75 65 6E 63  ten/bayern/muenc
00000100  68 65 6E 2D 67 75 65 74 65 72 7A 75 67 2D 73 74  hen-gueterzug-st
00000110  75 65 72 7A 74 2D 76 6F 6E 2D 62 72 75 65 63 6B  uerzt-von-brueck
00000120  65 2C 56 4E 33 4F 44 74 51 3E 0D 0A 0D 0A 3C 68  e,VN3ODtQ>....<h
00000130  74 74 70 73 3A 2F 2F 79 6F 75 74 75 2E 62 65 2F  ttps://youtu.be/
00000140  6F 45 50 46 63 35 6D 65 76 64 49 3E 0D 0A 0D 0A  oEPFc5mevdI>....
00000150  54 68 65 20 77 61 67 6F 6E 73 20 61 70 70 65 61  The wagons appea
00000160  72 20 74 6F 20 62 65 20 6F 66 20 74 68 65 20 41  r to be of the A
00000170  52 53 20 48 63 63 72 72 73 20 74 79 70 65 2E 0D  RS Hccrrs type..
00000180  0A 0D 0A 43 68 65 65 72 73 2C 0D 0A 2D 2D 20 0D  ...Cheers,..-- .
00000190  0A 52 6F 62 0D 0A 22 49 20 68 61 76 65 20 6E 65  .Rob.."I have ne
000001A0  76 65 72 20 75 6E 64 65 72 73 74 6F 6F 64 20 77  ver understood w
000001B0  68 79 20 69 74 20 73 68 6F 75 6C 64 20 62 65 20  hy it should be
000001C0  6E 65 63 65 73 73 61 72 79 20 74 6F 20 62 65 63  necessary to bec
000001D0  6F 6D 65 20 69 72 72 61 74 69 6F 6E 61 6C 20 0D  ome irrational .
000001E0  0A 69 6E 20 6F 72 64 65 72 20 74 6F 20 70 72 6F  .in order to pro
000001F0  76 65 20 74 68 61 74 20 79 6F 75 20 63 61 72 65  ve that you care
00000200  2C 20 6F 72 2C 20 69 6E 64 65 65 64 2C 20 77 68  , or, indeed, wh
00000210  79 20 69 74 20 73 68 6F 75 6C 64 20 62 65 20 6E  y it should be n
00000220  65 63 65 73 73 61 72 79 20 0D 0A 74 6F 20 70 72  ecessary ..to pr
00000230  6F 76 65 20 69 74 20 61 74 20 61 6C 6C 2E 22 20  ove it at all."
00000240  2D 20 41 76 6F 6E 2C 20 42 6C 61 6B 65 27 73 20  - Avon, Blake's
00000250  37 0D 0A 0D 0A                                   7....

   Paul

[toc] | [prev] | [next] | [standalone]

#20966

Es schrieb einmal Paul:
> It's possible the body text is not parsing correctly. Should the
> 0xC3 0x9F have some escape sequence in front of them ?

No. That is the UTF-8 encoding for Unicode u+00DF -> ß.

>  There is no
> marker at the beginning of the text.

It's in the article's header:

| Content-Type	text/plain; charset=UTF-8; format=flowed

Alfred

[toc] | [prev] | [next] | [standalone]

#20967

Paul wrote:

> It's possible the body text is not parsing correctly. Should the
> 0xC3 0x9F have some escape sequence in front of them ? There is no
> marker at the beginning of the text.
The 0xC3 is the marker for a two-byte UTF-8 sequence, so 0xC3 0x9F is 
valid encoding of ß

[toc] | [prev] | [next] | [standalone]

#20976

On 2026/6/21 10:18:59, Andy Burns wrote:
> Paul wrote:
> 
>> It's possible the body text is not parsing correctly. Should the
>> 0xC3 0x9F have some escape sequence in front of them ? There is no
>> marker at the beginning of the text.
> The 0xC3 is the marker for a two-byte UTF-8 sequence, so 0xC3 0x9F is 
> valid encoding of ß

That reads to me as meaning "OxC3 means it and the next byte are a
two-byte UTF-8 sequence", i. e. the first byte of such a sequence is
always 0xC3? To me it seems odd to refer to that as a two-byte sequence,
since only one byte is left after the 0xC3, though I can see that it
_could_ be referred to as a two-byte sequence.
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

… too popular actually to be any good.
- Alison Graham in Radio Times 2-8 February 2013

[toc] | [prev] | [next] | [standalone]

#20977

"J. P. Gilliver" wrote:

> That reads to me as meaning "OxC3 means it and the next byte are a
> two-byte UTF-8 sequence", i. e. the first byte of such a sequence is
> always 0xC3?

Well, first bytes can be between 0xC0 and 0xDF, with second bytes are 
from 0x80 to 0xBF.

There are also three and four byte sequences, the shorter sequences 
being supposed more frequently used characters, 0x00 to 0x7F being 
one-byte sequences, the same as 7 bit ASCII, the number of leading 1 
bits tells you the length of the sequence ...

[toc] | [prev] | [next] | [standalone]

#20978

On 2026/6/21 20:11:41, Andy Burns wrote:
> "J. P. Gilliver" wrote:
> 
>> That reads to me as meaning "OxC3 means it and the next byte are a
>> two-byte UTF-8 sequence", i. e. the first byte of such a sequence is
>> always 0xC3?
> 
> Well, first bytes can be between 0xC0 and 0xDF, with second bytes are 
> from 0x80 to 0xBF.
> 
> There are also three and four byte sequences, the shorter sequences 
> being supposed more frequently used characters, 0x00 to 0x7F being 
> one-byte sequences, the same as 7 bit ASCII, the number of leading 1 
> bits tells you the length of the sequence ...
> 
Ah, including the marker byte itself - so Cx/Dx, or 110x xxxx, having
two 1s then a 0, means a 2-byte sequence (including the C/D byte); so a
3-byte sequence would start E, and a 4- F. Ingenious. With the lower
four bits (five for a two-byte C/D one) being available to use in the
actual character selection.
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

resentment is like drinking poison and expecting the other person to
die - attributed to Carrie Fisher by Gareth McLean,
in Radio Times 28 January-3 February 2012

[toc] | [prev] | [next] | [standalone]

#20980 — UTF-8 (was: Betterbird has same problem as Thunderbird)

J. P. Gilliver in alt.comp.software.thunderbird:

[...]

>Ah, including the marker byte itself - so Cx/Dx, or 110x xxxx, having
>two 1s then a 0, means a 2-byte sequence (including the C/D byte); so a
>3-byte sequence would start E, and a 4- F. Ingenious. With the lower
>four bits (five for a two-byte C/D one) being available to use in the
>actual character selection.

Have a look at the tables in

<https://en.wikipedia.org/wiki/UTF-8#Description>

and

<https://de.wikipedia.org/wiki/UTF-8#Algorithmus>.

It's explained nicely there.

Marcel                                                       (Lines: 26)
-- 
╰───────╮  ╭─────╮ ╭─────╮        ╭─╮             ╭────╮       ╭─╮..67..
        │  ╰──╮  ╰─╯     ╰──╮  ╭──╯ │          ╭──╯  ╭─╯ ╭─╮   │ │..67..
 ╭──────╯  ╭──╯             │  ╰─╮  ╰──╮ ..42..╰─╮   ╰─╮ │ ╰─╮ │ │   ╭──
 ╰─────────╯          ..23..╰────╯     ╰─────────╯     ╰─╯   ╰─╯ ╰───╯  

[toc] | [prev] | [next] | [standalone]

#20982 — Re: UTF-8

On 2026/6/21 23:0:46, Marcel Logen wrote:
> J. P. Gilliver in alt.comp.software.thunderbird:
> 
> [...]
> 
>> Ah, including the marker byte itself - so Cx/Dx, or 110x xxxx, having
>> two 1s then a 0, means a 2-byte sequence (including the C/D byte); so a
>> 3-byte sequence would start E, and a 4- F. Ingenious. With the lower
>> four bits (five for a two-byte C/D one) being available to use in the
>> actual character selection.
> 
> Have a look at the tables in
> 
> <https://en.wikipedia.org/wiki/UTF-8#Description>

Thanks for that.

> 
> and
> 
> <https://de.wikipedia.org/wiki/UTF-8#Algorithmus>.
> 
> It's explained nicely there.
> 
> Marcel                                                       (Lines: 26)

I fear my German is a little rusty, but that does look comprehensive.
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

"Where's Piglet?" asked Pooh, as he munched a pork pie.

[toc] | [prev] | [next] | [standalone]

#20949

On 20 Jun 2026 17:46, Adam H. Kerman wrote:
> Undesireable Base64 encoding, which does not belong on Usenet, and upon
> decoding, the line boundaries are nonstandard.
> 
> Message-ID: <n9nlh8F30qfU1@mid.individual.net>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: base64
> User-Agent: Betterbird (Linux)

Yes, the CTE is chosen based on the content, sometimes base64 is preferred over 
8bit. No exceptions for news.

Make a full sample available; without a full sample, nothing can't be diagnosed.

-- 
Viele Grüße, Jörg
Sent with Betterbird. Simply better.
www.betterbird.eu - www.betterbird.eu/#featuretable
Es ist immer wieder erstaunlich: Kaum macht man's richtig, schon funktioniert's!

[toc] | [prev] | [next] | [standalone]

#20952

Jörg Knobloch wrote:

> Make a full sample available; without a full sample, nothing can't be 
> diagnosed.
Here's a reply with a sharp-s in it ß

[toc] | [prev] | [next] | [standalone]

#20953

Andy Burns wrote:

> Jorg Knobloch wrote:
> 
>> Make a full sample available; without a full sample, nothing can't be 
>> diagnosed.
> > Here's a reply with a sharp-s in it ß

No, that wasn't enough to trigger it, also removing Jorg's umlaut in 
this message

[toc] | [prev] | [next] | [standalone]

#20955

Jörg Knobloch <jorgk@jorgk.com> wrote:
>On 20 Jun 2026 17:46, Adam H. Kerman wrote:

>>Undesireable Base64 encoding, which does not belong on Usenet, and upon
>>decoding, the line boundaries are nonstandard.

>>Message-ID: <n9nlh8F30qfU1@mid.individual.net>
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset=UTF-8; format=flowed
>>Content-Transfer-Encoding: base64
>>User-Agent: Betterbird (Linux)

>Yes, the CTE is chosen based on the content, sometimes base64 is preferred
>over 8bit. No exceptions for news.

The encoding is bad enough but not nonstandard. Why are the line
boundaries always nonstandard? Is that an error during encoding or is
the issue that line boundaries get corrected after composing but not
before encoding?

>Make a full sample available; without a full sample, nothing can't
>be diagnosed.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.comp.software.thunderbird

csiph-web