telnet(1)-ing non-Telnet servers?

[Ivan Shmakov]

>>>>> Whiskers <catwh...@operamail.com> writes:

[Cross-posting to news:comp.protocols.tcp-ip.]

[...]

> If you have a local news spool, and merely want to read a particular
> article, you can use text tools to do so - or telnet into (eg)
> Leafnode. (Telnet also works with upstream news-servers of course).
> Lynx is quite good at reading individual articles, but not so good
> for following threads or posting.

Alas, even with --source, Lynx (as of 2.8.8dev.5 debian 1)
appears to garble the articles somewhat.

> Eg:

> ]$ telnet localhost nntp

Won't telnet(1) go nuts should the article being fetched happen
to contain an \xFF octet? FWIW, I'd advocate for using nc(1)
(AKA Netcat) here instead. (Why, some of my hosts have no
telnet(1) client installed at all.)

> Trying ::1...
> Connected to localhost.
> Escape character is '^]'.
> 200 Leafnode NNTP daemon, version 2.0.0.alpha20110806a at tavy.mobile.private
> ARTICLE <slrnkl884t...@nbleet.hcc.net>
> 220 0 <slrnkl884t...@nbleet.hcc.net> article retrieved - text follows

[...]

--
FSF associate member #7257 np. Face in the Sand -- Iron Maiden

[Barry Margolin]

In article <8738v7zw...@violet.siamics.net>,

Ivan Shmakov <onei...@gmail.com> wrote:

> >>>>> Whiskers <catwh...@operamail.com> writes:
>
> [Cross-posting to news:comp.protocols.tcp-ip.]
>
> [...]
>
> > If you have a local news spool, and merely want to read a particular
> > article, you can use text tools to do so - or telnet into (eg)
> > Leafnode. (Telnet also works with upstream news-servers of course).
> > Lynx is quite good at reading individual articles, but not so good
> > for following threads or posting.
>
> Alas, even with --source, Lynx (as of 2.8.8dev.5 debian 1)
> appears to garble the articles somewhat.
>
> > Eg:
>
> > ]$ telnet localhost nntp
>
> Won't telnet(1) go nuts should the article being fetched happen
> to contain an \xFF octet? FWIW, I'd advocate for using nc(1)
> (AKA Netcat) here instead. (Why, some of my hosts have no
> telnet(1) client installed at all.)

NNTP is a text protocol, binaries are sent encoded in ASCII (either
bas64 or uuencoded, I think). There shouldn't be any \xFF octets.

Also, when telnet connects to a non-default port, it doesn't try to
negotiate TELNET options. Does it still react to them if it receives
them?

--
Barry Margolin
Arlington, MA

[Ivan Shmakov]

>>>>> Barry Margolin <bar...@alum.mit.edu> writes:
>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
>>>>> Whiskers <catwh...@operamail.com> writes:

[...]

>>> ]$ telnet localhost nntp

>> Won't telnet(1) go nuts should the article being fetched happen to
>> contain an \xFF octet? FWIW, I'd advocate for using nc(1) (AKA
>> Netcat) here instead. (Why, some of my hosts have no telnet(1)
>> client installed at all.)

> NNTP is a text protocol, binaries are sent encoded in ASCII (either

> base64

There also is the case of non-ASCII (as in: UTF-8) plain text.
Which may be either encoded in 7-bit (either quoted-printable or
Base64), or left "unencoded" 8-bit.

My understanding is that the major NNTP implementations of today
allow for 8-bit-clean transfer (with the obvious exception for
\x00, \x0A, \x0D), and RFC 5537 seem to prohibit an NNTP
transport from munging the content, whether the most significant
bit is set or not. (Although an implementation is still allowed
to reject an article it isn't capable of passing through.)

Consider, e. g.:

--cut: urn:ietf:rfc:5537 --
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). [...]
--cut: urn:ietf:rfc:5537 --

> or uuencoded, I think).

Somehow, I doubt MIME allows for uuencoded data. And while such
an encoding doesn't require MIME, I know of no good reason to
use it instead of "properly MIMEd" Base64.

> There shouldn't be any \xFF octets.

Specifically, while UTF-8 doesn't seem to use \xFF, ISO-8859-1
assigns it for LATIN SMALL LETTER Y WITH DIAERESIS, windows-1251
for CYRILLIC SMALL LETTER YA, and so on.

> Also, when telnet connects to a non-default port, it doesn't try to
> negotiate TELNET options. Does it still react to them if it receives
> them?

Frankly, I don't know for sure. My guess is that it may vary
between implementations. I'd prefer to be on the "safe side,"
however, which is: nc(1).

--
FSF associate member #7257 http://hfday.org/

[Barry Margolin]

In article <87r4iry...@violet.siamics.net>,

Ivan Shmakov <onei...@gmail.com> wrote:

> Consider, e. g.:
>
> --cut: urn:ietf:rfc:5537 --
> 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). [...]
> --cut: urn:ietf:rfc:5537 --

Those restrictions make it practically impossible to transmit raw binary
files without encoding. While a submission agent could scan the file to
see if it contains any of these bytes, and send it unencoded if not, I'd
find such an implementation very surprising.

[glen herrmannsfeldt]

In comp.protocols.tcp-ip Barry Margolin <bar...@alum.mit.edu> wrote:

(snip on using telnet to read news)

> Also, when telnet connects to a non-default port, it doesn't try to
> negotiate TELNET options. Does it still react to them if it receives
> them?

I believe at least once I had a telnet server on a different port,
and that it worked fine.

Or maybe with NAT port translation, so I could reach different hosts
with only one external address.

But reasonably likely it tried, still worked fine, and I didn't notice
strange characters on the screen.

-- glen

[Ivan Shmakov]

>>>>> Barry Margolin <bar...@alum.mit.edu> writes:
>>>>> Ivan Shmakov <onei...@gmail.com> wrote:

[...]

>> --cut: urn:ietf:rfc:5537 --

>> 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). [...]

>> --cut: urn:ietf:rfc:5537 --

> Those restrictions make it practically impossible to transmit raw
> binary files without encoding. While a submission agent could scan
> the file to see if it contains any of these bytes, and send it
> unencoded if not, I'd find such an implementation very surprising.

So would I.

My point was, however, that it doesn't make \xFF impossible, or
even unlikely to happen, within an article's body. Especially
should one consider a non-English newsgroup.

>>> There shouldn't be any \xFF octets.

>> Specifically, while UTF-8 doesn't seem to use \xFF, ISO-8859-1
>> assigns it for LATIN SMALL LETTER Y WITH DIAERESIS, windows-1251 for
>> CYRILLIC SMALL LETTER YA, and so on.

Consider, e. g.:

news:MSGID_2=3A5030=2F830.57=40fidonet...@fidonet.org
news:58bet9-...@news.russian-z1.org

[Shmuel Metz]

In <87r4iry...@violet.siamics.net>, on 04/03/2013

at 02:56 PM, Ivan Shmakov <onei...@gmail.com> said:

> > There shouldn't be any \xFF octets.

> Specifically, while UTF-8 doesn't seem to use \xFF, ISO-8859-1
> assigns it for LATIN SMALL LETTER Y WITH DIAERESIS, windows-1251
> for CYRILLIC SMALL LETTER YA, and so on.

While RFC 3977 provides an 8 bit transport mechanism, RFC 5536 does
not permit un-encoded non-ASCII data. That doesn't, of course,
guaranty that you won't see 'FF'x in non-compliant articles.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Ivan Shmakov]

>>>>> Shmuel (Seymour J.) Metz writes:
>>>>> Ivan Shmakov <onei...@gmail.com> said:

>>> There shouldn't be any \xFF octets.

>> Specifically, while UTF-8 doesn't seem to use \xFF, ISO-8859-1
>> assigns it for LATIN SMALL LETTER Y WITH DIAERESIS, windows-1251 for
>> CYRILLIC SMALL LETTER YA, and so on.

> While RFC 3977 provides an 8 bit transport mechanism, RFC 5536 does
> not permit un-encoded non-ASCII data.

Somehow, I fail to find such a prohibition there. Could you
please quote the relevant part thereof?

> That doesn't, of course, guaranty that you won't see 'FF'x in
> non-compliant articles.

--

[Rod Dorman]

In article <87zjxew...@violet.siamics.net>,

Ivan Shmakov <onei...@gmail.com> wrote:
>>>>>> Shmuel (Seymour J.) Metz writes:
>>>>>> Ivan Shmakov <onei...@gmail.com> said:
>>>> There shouldn't be any \xFF octets.
>
>>> Specifically, while UTF-8 doesn't seem to use \xFF, ISO-8859-1
>>> assigns it for LATIN SMALL LETTER Y WITH DIAERESIS, windows-1251 for
>>> CYRILLIC SMALL LETTER YA, and so on.
>
>> While RFC 3977 provides an 8 bit transport mechanism, RFC 5536 does
>> not permit un-encoded non-ASCII data.
>
> Somehow, I fail to find such a prohibition there. Could you
> please quote the relevant part thereof?

RFC 5536 section 1.4. Syntax Notation
body = <see RFC 5322 Section 3.5>

RFC 5322 Section 3.5 Overall Message Syntax
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127

--
-- Rod --
rodd(at)polylogics(dot)com

[Shmuel Metz]

In <87zjxew...@violet.siamics.net>, on 04/04/2013

at 10:07 AM, Ivan Shmakov <onei...@gmail.com> said:

> > While RFC 3977 provides an 8 bit transport mechanism, RFC 5536
>does
> > not permit un-encoded non-ASCII data.

> Somehow, I fail to find such a prohibition there. Could you
> please quote the relevant part thereof?

RFC 5536:

2.1. Base

An article is said to be conformant to this specification if it
conforms to the format specified in Section 3 of [RFC5322] and
to the additional requirements of this specification.

RFC 5322

2.1. General Description

At the most basic level, a message is a series of characters. A
message that is conformant with this specification is composed
of characters with values in the range of 1 through 127 and
interpreted as US-ASCII [ANSI.X3-4.1986] characters. For
brevity, this document sometimes refers to this range of
characters as simply "US-ASCII characters".

Note: This document specifies that messages are made up of
characters in the US-ASCII range of 1 through 127. There are
other documents, specifically the MIME document series
([RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288],
[RFC4289]), that extend this specification to allow for
values outside of that range. Discussion of those mechanisms
is not within the scope of this specification.

3.5. Overall Message Syntax

A message consists of header fields, optionally followed by a
message body. Lines in a message MUST be a maximum of 998
characters excluding the CRLF, but it is RECOMMENDED that lines
be limited to 78 characters excluding the CRLF. (See section
2.1.1 for explanation.) In a message body, though all of the
characters listed in the text rule MAY be used, the use of
US-ASCII control characters (values 1 through 8, 11, 12, and 14
through 31) is discouraged since their interpretation by
receivers for display is not guaranteed.

text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127

[Ivan Shmakov]

>>>>> Shmuel (Seymour J ) Metz <spam...@library.lspace.org.invalid> writes:
>>>>> Ivan Shmakov <onei...@gmail.com> said:

>>> While RFC 3977 provides an 8 bit transport mechanism, RFC 5536 does
>>> not permit un-encoded non-ASCII data.

>> Somehow, I fail to find such a prohibition there. Could you please
>> quote the relevant part thereof?

> RFC 5536:

> 2.1. Base

> An article is said to be conformant to this specification if it
> conforms to the format specified in Section 3 of [RFC5322] and to the
> additional requirements of this specification.

> RFC 5322

[...]

> Note: This document specifies that messages are made up of characters
> in the US-ASCII range of 1 through 127. There are other documents,
> specifically the MIME document series ([RFC2045], [RFC2046],
> [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that extend this
> specification to allow for values outside of that range. Discussion
> of those mechanisms is not within the scope of this specification.

ACK, thanks!

... Thus, the real question is if by referencing this section
RFC 5536 also effectively "inherits" the note above.

(The other option is, obviously, that RFC 5536 fails to document
the existing practice.)

[...]