ietf-nntp RFC977bis w.r.t. authentication
Chris.Lewis.clewis at nt.com
Thu May 7 11:13:08 PDT 1998
Larry Osterman (Exchange) wrote:
> There are 2 major problems with this idea.
> The first (technical) is that TCP/IP is a stream oriented protocol. This
> means that every message sent is subject to IP fragmentation, thus every
> packet needs to have enough information contained within it to allow for
> re-assembly on the receiving end. Many of the existing security protocols
> do not have sufficient information in their packets to allow re-assembly on
> the receiving end, so in effect the security information is "tunneled"
> through the higher level protocol - in other words, it uses the higher level
> protocol to carry the security information.
This wasn't the original intent when I "designed" GENERIC. Packet reassembly
is what the authenticator (non-NNTP) part has to deal with.
> And that brings me to the second problem, and this one is a total
> show-stopper as far as I'm concerned. Assuming that the security logic
> "takes over" the NNTP connection is about as egregious a layering violation
> as I've ever seen. And layering violations are a VERY bad thing.
The question really is, what is the Microsoft and Netscape servers doing
If you believe this to be a show-stopper, with both Microsoft and Netscape
doing it in the show-stopper fashion, then we're screwed, because nobody
does it in a way compatible with SASL.
> BTW: Why didn't your message have a To: header? It made replying to this
> MUCH harder.
Since this list doesn't use Reply-To: headers properly, a reply-all goes
to both the list, with additional copies to potentially _everyone_ who
ever contributed to the thread to that point. This pisses off people,
so they try to remove the other individuals in the reply-all. Which sometimes
results in the ietf-nntp at academ.com address remaining a Cc and not
a to or from.
More information about the ietf-nntp