Re: Malicious USB Interfaces In Airports

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.