ietf-nntp RFC977bis w.r.t. authentication

Chris Lewis 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
here?

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 mailing list