Seems there have been cases of crims hijacking USB charging outlets in
airports to connect special devices that can pwn your mobile device
<https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.

When I was in Hong Kong Airport a few years ago, it was very hard for
me to find a mains outlet to charge my laptop. Just about all the
ports built into the public seating areas were USB ones, for
phones/tablets.

It is possible to get USB cables that only connect the power wires for
charging, without enabling data transfer. Alternatively, here
<https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
device that tries to protect you from malicious devices. If you don’t
want to build your own, there’s a link in the readme to buy NZ-made
ones.

Maybe better only charge powerbanks on untrusted outlets and then later
charge your phone with them. That adds the benefit that power glitches
may only kill the powerbank and not the phone.

--
I do not bite, I just want to play.

Lawrence D'Oliveiro wrote:
> It is possible to get USB cables that only connect the power wires for
> charging, without enabling data transfer. Alternatively, here
> <https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
> device that tries to protect you from malicious devices.
See also "USB condom"
<https://www.usbcompany.co.uk/accessories/usb-condom>
Not so simple with type-C and PD

In article <lcftdfFlf5sU1@mid.individual.net>,
Andy Burns <usenet@andyburns.uk> wrote:
>Lawrence D'Oliveiro wrote:
>
>> It is possible to get USB cables that only connect the power wires for
>> charging, without enabling data transfer. Alternatively, here
>> <https://github.com/robertfisk/USG/wiki> is a USB "firewall"-type
>> device that tries to protect you from malicious devices.
>
>See also "USB condom"
><https://www.usbcompany.co.uk/accessories/usb-condom>
>
>Not so simple with type-C and PD

This one's worked reasonably well for me:

https://amzn.to/3xaZQ2r

I suspect it blocks PD negotiation for higher power levels, but if all
you're charging is a phone, it should fall back to at least 5V 2.4-3A charging
of some sort. (My current phone doesn't support PD anyway...it uses
something called "Warp Charge" that is unlikely to be supported by any
public charger.)

(Your newsreader is inserting CRs at the ends of lines, BTW...might want to
fix that.)

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

On Fri, 07 Jun 2024 14:12:23 GMT, Scott Alfter wrote:

> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
> fix that.)

I see CRLF at the ends of lines in Andy Burns' message. Both in the
raw message and in the base64-decoded text. I checked Andy's message
on two different news servers.

CRLF is the correct, standard on-the-wire format.

--
Kind regards
Ralph Fox
🦊

A man must plow with such oxen as he hath.

Ralph Fox wrote:

> Scott Alfter wrote:
>
>> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
>> fix that.)
>
> I see CRLF at the ends of lines in Andy Burns' message. Both in the
> raw message and in the base64-decoded text. I checked Andy's message
> on two different news servers.
>
> CRLF is the correct, standard on-the-wire format.

Actually I think bare LF's are correct, no?

Thunderbird does on occasion do the wrong thing, if it sees 8-bit
characters (often an &nbsp; whitespace character, or two spaces at the
end of a paragraph) it decides to base-64 encode where it doesn't need
to, I think on this occasion it took objection to Lawrence's fancy
double quotes around the word 'firewall', unfortunately I've tried
various character encodings/charsets and nothing prevents the issue.

On Fri, 07 Jun 2024 21:57:40 +0100, Andy Burns wrote:

> Ralph Fox wrote:
>> CRLF is the correct, standard on-the-wire format.
>
> Actually I think bare LF's are correct, no?

I think the RFC specifies CRLF. What the client shows is another matter.

> I think on this occasion it took objection to Lawrence's fancy
> double quotes around the word 'firewall', unfortunately I've tried
> various character encodings/charsets and nothing prevents the issue.

I don't have the issue as I killfiled him way back!

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

In article <5br66jp0u5gdvppc8nm9j2rmug0piq02uc@4ax.com>,
Ralph Fox <-rf-nz-@-.invalid> wrote:
>On Fri, 07 Jun 2024 14:12:23 GMT, Scott Alfter wrote:
>
>> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
>> fix that.)
>
>I see CRLF at the ends of lines in Andy Burns' message. Both in the
>raw message and in the base64-decoded text. I checked Andy's message
>on two different news servers.
>
>CRLF is the correct, standard on-the-wire format.

Maybe they were extras in addition to whatever standard newline is present.
When I replied to his post, there was an extra Ctrl-M at the end of every
line. Right now, while I'm replying to your post, it's normal...no extra
characters that need deleting.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

On Fri, 7 Jun 2024 21:57:40 +0100, Andy Burns wrote:
> Ralph Fox wrote:
>> Scott Alfter wrote:
>>
>>> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
>>> fix that.)
>>
>> I see CRLF at the ends of lines in Andy Burns' message. Both in the
>> raw message and in the base64-decoded text. I checked Andy's message
>> on two different news servers.
>>
>> CRLF is the correct, standard on-the-wire format.
>
> Actually I think bare LF's are correct, no?

The on-the-wire format for transmission is CRLF, *not* bare LF. See,
for example, RFC5537 "Netnews Architecture and Protocols" section 2
"Transport".

<https://www.rfc-editor.org/rfc/rfc5537#section-2>

| Transports for Netnews articles MUST treat news articles as
| uninterpreted sequences of octets, excluding the values %d00 (which
| may not occur in Netnews articles), %d13, and %d10 (which MUST only
| appear in Netnews articles as a pair in that order and which,
| together, denote a line separator). These octets are the US-ASCII
| [ASCII] characters NUL, CR, and LF respectively.

How a newsreader client or news server stores articles locally (CRLF
or bare LF) is up to that client or server. But when communicating
between client and server / server and client, the on-the-wire format
is CRLF.

> Thunderbird does on occasion do the wrong thing, if it sees 8-bit
> characters (often an &nbsp; whitespace character, or two spaces at the
> end of a paragraph) it decides to base-64 encode where it doesn't need
> to, I think on this occasion it took objection to Lawrence's fancy
> double quotes around the word 'firewall', unfortunately I've tried
> various character encodings/charsets and nothing prevents the issue.

Using the latest Thunderbird 115.11.1 on Windows...

* When I compose a reply to Lawrence's post with the 'curly' quotes
and put it in the Outbox, my reply is not base-64 encoded.
* I would like to try composing my reply with various character
encodings/charsets, but current Thunderbird 115.11.1 does not seem
to have that option any more. In Thunderbird, my composed reply
to Lawrence is always UTF-8.

Using Thunderbird 115.11.0 on Linux Mint...

Same thing.

--
Kind regards
Ralph Fox
🦊

Great spenders are bad lenders.

Ralph Fox wrote:

> Using the latest Thunderbird 115.11.1 on Windows...
>
> * When I compose a reply to Lawrence's post with the 'curly' quotes
> and put it in the Outbox, my reply is not base-64 encoded.

Several times I've half-arsedly looked into what causes my TB to use
base64, after looking in a hex editor, it always seems to occur after a
perfect storm combination of user-agents, content-types,
character-encodings etc

Maybe I have some ancient about:config setting that I can't remember?

I've never managed to get even close to being able to log a good
bugzilla ticket.

> * I would like to try composing my reply with various character
> encodings/charsets, but current Thunderbird 115.11.1 does not seem
> to have that option any more.

Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding

In Thunderbird, my composed reply
> to Lawrence is always UTF-8.
>
> Using Thunderbird 115.11.0 on Linux Mint...
>
> Same thing.

On Sat, 08 Jun 2024 16:15:04 +1200
Ralph Fox <-rf-nz-@-.invalid> wrote:
> On Fri, 7 Jun 2024 21:57:40 +0100, Andy Burns wrote:
> > Ralph Fox wrote:
> >> Scott Alfter wrote:
> >>
> >>> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
> >>> fix that.)
> >>
> >> I see CRLF at the ends of lines in Andy Burns' message. Both in the
> >> raw message and in the base64-decoded text. I checked Andy's message
> >> on two different news servers.
> >>
> >> CRLF is the correct, standard on-the-wire format.
> >
> > Actually I think bare LF's are correct, no?
>
> The on-the-wire format for transmission is CRLF, *not* bare LF. See,
> for example, RFC5537 "Netnews Architecture and Protocols" section 2
> "Transport".
>
> <https://www.rfc-editor.org/rfc/rfc5537#section-2>
>
> | Transports for Netnews articles MUST treat news articles as
> | uninterpreted sequences of octets, excluding the values %d00 (which
> | may not occur in Netnews articles), %d13, and %d10 (which MUST only
> | appear in Netnews articles as a pair in that order and which,
> | together, denote a line separator). These octets are the US-ASCII
> | [ASCII] characters NUL, CR, and LF respectively.
>
>
> How a newsreader client or news server stores articles locally (CRLF
> or bare LF) is up to that client or server. But when communicating
> between client and server / server and client, the on-the-wire format
> is CRLF.

I believe the RFC quote refers to articles before decoding (if there was an
encoding step). Here the complaint is that Andy's message had CR at the end
of every line even after decoding. I don't believe there is any standard for
that and a newsreader should probably follow the customs of the underlying
operating system.

On 07-June-24 12:02 pm, Lawrence D'Oliveiro wrote:
> Seems there have been cases of crims hijacking USB charging outlets in
> airports to connect special devices that can pwn your mobile device
> <https://www.nzherald.co.nz/travel/news/airport-passengers-warned-of-phone-charging-scams/RGBS35ORBVBUDJIVO466TIFNAQ/>.
>
> When I was in Hong Kong Airport a few years ago, it was very hard for
> me to find a mains outlet to charge my laptop. Just about all the
> ports built into the public seating areas were USB ones, for
> phones/tablets.
>
> It is possible to get USB cables that only connect the power wires for
> charging, without enabling data transfer. Alternatively, here
> <https://github.com/robertfisk/USG/wiki> is a USB “firewall”-type
> device that tries to protect you from malicious devices. If you don’t
> want to build your own, there’s a link in the readme to buy NZ-made
> ones.

Third attempt - I'm not seeing this arrive in the NG.

Is this still an issue, at least as far as Android phones are concerned?

Sylvia.

Sylvia Else wrote:

> Lawrence D'Oliveiro wrote:
>
>> It is possible to get USB cables that only connect the power wires for
>> charging, without enabling data transfer.
>
> Is this still an issue, at least as far as Android phones are concerned?

Most(?) modern phones ask if you want to just charge, or enable
file/media transfer ... but who knows if there might be a way to
maliciously spoof an extra USB endpoint?

On Sat, 8 Jun 2024 21:36:22 -0000 (UTC), Spiros Bousbouras wrote:
> On Sat, 08 Jun 2024 16:15:04 +1200
> Ralph Fox <-rf-nz-@-.invalid> wrote:
>> On Fri, 7 Jun 2024 21:57:40 +0100, Andy Burns wrote:
>>> Ralph Fox wrote:
>>>> Scott Alfter wrote:
>>>>
>>>>> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
>>>>> fix that.)
>>>>
>>>> I see CRLF at the ends of lines in Andy Burns' message. Both in the
>>>> raw message and in the base64-decoded text. I checked Andy's message
>>>> on two different news servers.
>>>>
>>>> CRLF is the correct, standard on-the-wire format.
>>>
>>> Actually I think bare LF's are correct, no?
>>
>> The on-the-wire format for transmission is CRLF, *not* bare LF. See,
>> for example, RFC5537 "Netnews Architecture and Protocols" section 2
>> "Transport".
>>
>> <https://www.rfc-editor.org/rfc/rfc5537#section-2>
>>
>> | Transports for Netnews articles MUST treat news articles as
>> | uninterpreted sequences of octets, excluding the values %d00 (which
>> | may not occur in Netnews articles), %d13, and %d10 (which MUST only
>> | appear in Netnews articles as a pair in that order and which,
>> | together, denote a line separator). These octets are the US-ASCII
>> | [ASCII] characters NUL, CR, and LF respectively.
>>
>>
>> How a newsreader client or news server stores articles locally (CRLF
>> or bare LF) is up to that client or server. But when communicating
>> between client and server / server and client, the on-the-wire format
>> is CRLF.
>
> I believe the RFC quote refers to articles before decoding (if there was an
> encoding step).

Yes.

> Here the complaint is that Andy's message had CR at the end
> of every line even after decoding. I don't believe there is any standard for
> that and a newsreader should probably follow the customs of the underlying
> operating system.

Andy's message _after_ decoding_ also has CRLF at the end of every
line. As I stated in my reply to Scott Alfter earlier in this thread.

I tested this by running Andy's base-64 message body through a
base-64 decoder outside of my newsreader (to avoid any possibility
that my newsreader might modify the line ends after decoding).

--
Kind regards
Ralph Fox
🦊

Of idleness comes no goodness.

On Fri, 07 Jun 2024 21:41:34 GMT, Scott Alfter wrote:
> In article <5br66jp0u5gdvppc8nm9j2rmug0piq02uc@4ax.com>,
> Ralph Fox <-rf-nz-@-.invalid> wrote:
>> On Fri, 07 Jun 2024 14:12:23 GMT, Scott Alfter wrote:
>>
>>> (Your newsreader is inserting CRs at the ends of lines, BTW...might want to
>>> fix that.)
>>
>> I see CRLF at the ends of lines in Andy Burns' message. Both in the
>> raw message and in the base64-decoded text. I checked Andy's message
>> on two different news servers.
>>
>>CRLF is the correct, standard on-the-wire format.
>
> Maybe they were extras in addition to whatever standard newline is present.
> When I replied to his post, there was an extra Ctrl-M at the end of every
> line. Right now, while I'm replying to your post, it's normal...no extra
> characters that need deleting.

Andy's message body is base-64 encoded. Mine is not.

When I run Andy's raw base-64 message body through a base-64 decoder,
the message _after_ decoding also has CRLF and only CRLF at the ends
of lines. I tested this with a base-64 decoder outside of my newsreader,
to avoid any possibility that my newsreader might be modifying the line
ends after decoding.

--
Kind regards
Ralph Fox
🦊

He that would have honey, must have bees.

Ralph Fox wrote:

> Andy's message body is base-64 encoded. Mine is not.
>
> When I run Andy's raw base-64 message body through a base-64 decoder,
> the messageafter decoding also has CRLF and only CRLF at the ends
> of lines. I tested this with a base-64 decoder outside of my newsreader,
> to avoid any possibility that my newsreader might be modifying the line
> ends after decoding.

I accept that TB is doing that (I think not just mine) several times
I've tried to stop it, but I fear I can't ... it's usually "lured" into
doing base64 by a particular sequence of messages, suggestions welcome ...

On Sun, 9 Jun 2024 21:52:45 +0100, Andy Burns wrote:
> Ralph Fox wrote:
>
>> Andy's message body is base-64 encoded. Mine is not.
>>
>> When I run Andy's raw base-64 message body through a base-64 decoder,
>> the messageafter decoding also has CRLF and only CRLF at the ends
>> of lines. I tested this with a base-64 decoder outside of my newsreader,
>> to avoid any possibility that my newsreader might be modifying the line
>> ends after decoding.
>
> I accept that TB is doing that (I think not just mine) several times
> I've tried to stop it, but I fear I can't ... it's usually "lured" into
> doing base64 by a particular sequence of messages, suggestions welcome ...

Just to be clear, I am not complaining. My newsreader automatically
decodes base-64. I would not even know a message is base-64 encoded
unless I look at the raw message source (like TB's Ctrl+U).

As for why TB is doing that, I suspect it is because your Thunderbird's
preference 'mail.strictly_mime' is set to true. The default is false.

When preference 'mail.strictly_mime' is set to true, Thunderbird will
MIME-encode (quoted-printable or base-64) bodies containing characters
outside the 7-bit US-ASCII range.

When I set 'mail.strictly_mime' is set to true, compose a reply to
Lawrence's post with the 'curly' quotes, and put it in the Outbox,
in that case my reply _is_ base-64 encoded. But I do not know why
Thunderbird is choosing to use base-64 over quoted-printable.
* If the body contains over ~20% 8-bit _bytes_, MIME base-64 is
more efficient than MIME quoted-printable.
* But in this case the body has less than ~20% 8-bit bytes, so
quoted-printable would be more efficient.

--
Kind regards
Ralph Fox
🦊

The wind keeps not always in one quarter.

On Sat, 8 Jun 2024 12:00:10 +0100, Andy Burns wrote:
> Ralph Fox wrote:
>
>> Using the latest Thunderbird 115.11.1 on Windows...
>>
>> * When I compose a reply to Lawrence's post with the 'curly' quotes
>> and put it in the Outbox, my reply is not base-64 encoded.
>
> Several times I've half-arsedly looked into what causes my TB to use
> base64, after looking in a hex editor, it always seems to occur after a
> perfect storm combination of user-agents, content-types,
> character-encodings etc
>
> Maybe I have some ancient about:config setting that I can't remember?
>
> I've never managed to get even close to being able to log a good
> bugzilla ticket.
>
>> * I would like to try composing my reply with various character
>> encodings/charsets, but current Thunderbird 115.11.1 does not seem
>> to have that option any more.
>
> Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding

The above setting did not affect the charset of my reply. Even though
the above setting was (already) set to "windows-1252", Thunderbird used
the UTF-8 charset for the reply I composed to Lawrence's post.

Also, the above setting is only present for news servers, not for email
servers. I expect that a setting to control the charset of _outgoing_
messages would be available for both email and news.

At one time you could specify the character encoding for an outgoing
message from its Compose window menu "Options >> Character Encoding".
<http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
Similar to how you still can in SeaMonkey. See this screen-shot from
SeaMonkey:
<http://img4.imagetitan.com/img.php?image=27_lchai5__text-encoding-menu-on-the-compose-window-in-seamonkey.png>

--
Kind regards
Ralph Fox
🦊

Grass grows not upon the high way.

Ralph Fox wrote:
> On Sat, 8 Jun 2024 12:00:10 +0100, Andy Burns wrote:
>> Ralph Fox wrote:
>>
>>> Using the latest Thunderbird 115.11.1 on Windows...
>>>
>>> * When I compose a reply to Lawrence's post with the 'curly' quotes
>>> and put it in the Outbox, my reply is not base-64 encoded.
>>
>> Several times I've half-arsedly looked into what causes my TB to use
>> base64, after looking in a hex editor, it always seems to occur after a
>> perfect storm combination of user-agents, content-types,
>> character-encodings etc
>>
>> Maybe I have some ancient about:config setting that I can't remember?
>>
>> I've never managed to get even close to being able to log a good
>> bugzilla ticket.
>>
>>> * I would like to try composing my reply with various character
>>> encodings/charsets, but current Thunderbird 115.11.1 does not seem
>>> to have that option any more.
>>
>> Tools/Accounts/[ServerName]/ServerSettings/DefaultTextEncoding
>
>
> The above setting did not affect the charset of my reply. Even though
> the above setting was (already) set to "windows-1252", Thunderbird used
> the UTF-8 charset for the reply I composed to Lawrence's post.
>
> Also, the above setting is only present for news servers, not for email
> servers. I expect that a setting to control the charset of _outgoing_
> messages would be available for both email and news.
>
>
> At one time you could specify the character encoding for an outgoing
> message from its Compose window menu "Options >> Character Encoding".
> <http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
> Similar to how you still can in SeaMonkey. See this screen-shot from
> SeaMonkey:
> <http://img4.imagetitan.com/img.php?image=27_lchai5__text-encoding-menu-on-the-compose-window-in-seamonkey.png>
>
>

Have you looked at about:config, Tools-->Options-->Advanced-->Config
Editor...
In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
you could change it to Windows-1252. Or simply use SeaMonkey. With some
config editing, you could probably share your news directories, unless
Thunderbird has changed something.
Dave

On Fri, 14 Jun 2024 16:15:33 -0700, Dave Yeo wrote:
> Ralph Fox wrote:
>>
>> At one time you could specify the character encoding for an outgoing
>> message from its Compose window menu "Options >> Character Encoding".
>> <http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
>> Similar to how you still can in SeaMonkey. See this screen-shot from
>> SeaMonkey:
>> <http://img4.imagetitan.com/img.php?image=27_lchai5__text-encoding-menu-on-the-compose-window-in-seamonkey.png>
>>
>
> Have you looked at about:config, Tools-->Options-->Advanced-->Config
> Editor...
> In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
> you could change it to Windows-1252.

That about:config preference is not in Thunderbird version 115.11.1
(the current release).

> Or simply use SeaMonkey. With some
> config editing, you could probably share your news directories, unless
> Thunderbird has changed something.
> Dave

I am happy sending email in us-ascii or UTF-8.

The discussion was whether the sending charset had anything to do with
Andy's posts being base64 encoded. I think not. I suspect Andy's posts
are base64 encoded when they contain non-ASCII characters (no matter
what the charset) because I suspect Andy's Thunderbird preference
'mail.strictly_mime' is set to true.

--
Kind regards
Ralph Fox
🦊

Every ones faults are not written in their foreheads.

Ralph Fox wrote:

> I suspect Andy's posts
> are base64 encoded when they contain non-ASCII characters

Yes, I did tests several months ago

> (no matter
> what the charset) because I suspect Andy's Thunderbird preference
> 'mail.strictly_mime' is set to true.

With various charsets, with/without the "strictly" setting, on messages
that were 7-bit clean or otherwise.

My conclusion was that everything annoys somebody, but the least
annoying overall is to embrace UTF-8 and put up with base64 where it
isn't really required.

with <vd6q6jlmnc8sa9cbeg8a21cfidvl7ditjf@4ax.com> Ralph Fox wrote:
> On Fri, 14 Jun 2024 16:15:33 -0700, Dave Yeo wrote:
>> Ralph Fox wrote:

>>> At one time you could specify the character encoding for an outgoing
>>> message from its Compose window menu "Options >> Character Encoding".
>>> <http://kb.mozillazine.org/Font_settings_in_Thunderbird#Character_encoding>.
*SKIP* [ 5 lines 3 levels deep]
>> Have you looked at about:config, Tools-->Options-->Advanced-->Config
>> Editor...
>> In my old Thunderbird I see mailnews.send_default_charset;UTF-8 I guess
>> you could change it to Windows-1252.
> That about:config preference is not in Thunderbird version 115.11.1
> (the current release).

(disclaimer: I'm TB ignorant, but) In FF-current setting 'User-Agent:'
is secret option (it's missing from about:preferences and about:config),
it must be created manually. I speculate, setting 'Content-Type:
charset=' in TB-current *might be* secret option. That being said, this
implies two things: more digging through documentation and/or search
results, and hoping one day it won't be ignored forever.

*CUT* [ 15 lines 2 levels deep]

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Andy Burns <usenet@andyburns.uk> wrote:
> Ralph Fox wrote:
>> I suspect Andy's posts are base64 encoded when they contain
>> non-ASCII characters
>
> Yes, I did tests several months ago
>
>> (no matter what the charset) because I suspect Andy's
>> Thunderbird preference 'mail.strictly_mime' is set to true.
>
> With various charsets, with/without the "strictly" setting, on
> messages that were 7-bit clean or otherwise.
>
> My conclusion was that everything annoys somebody,

True, personally UTF-8 annoys me more, but not enough to complain
to people using it.

> but the least annoying overall is to embrace UTF-8

Argh, down that road people end up using emojis everywhere like
they do on some web forums. I might start complaining if people
embraced Unicode that much on Usenet.

--
__ __
#_ < |\| |< _#