ietf-nntp BCP for RFC977 server/RFC1036 interaction

Chris Lewis clewis at nortel.ca
Thu Dec 19 13:52:00 PST 1996


In message "Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction", 
'mike at cosy.sbg.ac.at' writes:

>On Dec 18, evanc at synapse.net (Evan Champion) wrote:

>> > If I bang-on the IP address of the client then this is not necessary,
>> > in fact it is unduly restrictive.

>> I still don't understand why anyone would want to forge the path to make
>> sure an article doesn't get to a particular site.  

>I know of several people whose signatures have a disclaimer daying that the
>Microsoft Network is not allowed to store/use/... their articles. most of
>them just want to have a sig that makes them look good in the eyes of their
>friends, but some mean it. these are the ones that bang the names of
>microsofts newsservers on their path. if that's their choice, it's a valid
>reason IMHO, but i don't want to give them IHAVE permissions just for that.

If I'm not mistaken, most of them don't even try to alias out Microsoft's
servers.  To obey the disclaimer, Microsoft would have to write software
to detect these articles in some magical fashion, and avoid storing them.
This is impractical, unenforcable and childish.

Furthermore, I believe major portions of Microsoft (microsoft.com
itself) cannot be aliased out in any realistic way anyways, because
the inbound feeds are via POST run by a large number of individuals
doing suck feeds, and Microsoft's servers behave somewhat unexpectedly
to such things when compared to servers we're more familiar with.

[A few months ago Microsoft's servers appeared to be doing something like
discarding Message-Id on POST, and with multiple POST/suck feeds, we saw
perhaps the largest Usenet spew (>17,000 articles if I recall correctly)
I've ever seen.  "spew" being the jargon term, analogously to "spam",
indicating a broken news server regurgitating inbound articles with
new Message-Ids.

On the other hand, it occurs to me that part of the problem was that
Microsoft's servers were also discarding Path: on POST, which, if they
hadn't done that, and paths worked properly w.r.t. feeding microsoft.com,
would have prevented looping.

I think I may have just persuaded myself that discarding Path: is a bad
idea ;-), simply because of the undeniable existance of suck/POST feeds and
the risks of looping.  Perhaps it's safer to be conservative with this one
and leave it alone, given that a BCP site would be inserting a
real NNTP-Posting-Host and/or Sender anyways.]
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.




More information about the ietf-nntp mailing list