Finally we've almost gotten around to the errata.  We apologize for the delay.
The book is in its third printing (thanks to all of you!)  The first two
printings were made from the same plates, therefore the errors were the
same.  We fixed most everything we could for the third printing.

The reviews have been generous, and we thank you all for your kind words
and encouragement.  We've heard a number of stories about it: a bidding
war in the Ukraine and a copy dropped on the south pole (along with
many tons of other less-important items) in the dead of winter.

A few people have asked if we could make the postscript of the book
available in its entirety.  Well, we must confess that we _like_
receiving royalties, though neither of us will get rich from them.
If you can think of a way to distribute the book electronically, and
protect the income flow for the publishers and us,  please let us
know.  It is currently an open research problem.

Again, we thank you for the error reports and many notes and comments
we've received from all over the world.  The response has been gratifying.



Errors and comments in the first two printings:
	
Page 22, section 2.1.3
	refers to "The Transport Control Protocol"
	should be ``Transmission Control Protocol.'' 
page 22, Section 2.1.3, The sequence number of the
	next expected byte, not the last, is given.
	
	

page 27, last sentence, change:
		... some sites have attempted the mandate such a link...
	to
		... some sites have attempted to mandate such a link...

p. 31, bomb 12
	Even without MIME, many terminals provide escape sequences that cause
	the terminal to transmit the contents of the screen, or part of the
	screen.  It is possible to embed in a message these sequences and
	effectively trick the terminal into sending your message with the
	privilege and identity of the person reading the mail.  In an earlier
	life I actually demonstrated that you could use this technique to create
	new, privileged user accounts by making the system console do it.
	Other terminals allow function keys to be reprogrammed.  I'm not
	sure, but I suspect xterm has at least one of these vulnerabilities.

page 55, The quote in italics implies that Brent Chapman made the quote.  He
	didn't, and the excellent paper cited there is a good reference
	to what he preaches.  Our apologies.

page 56, paragraph beginning "A TCP conversation" near
	midpage. Fourth line. "an initial open request packet in TCP does not have
	the set in the..." should read "an initial open request packet in TCP
	does not have the ACK bit set in the...". As I said, a minor item.

page 72:  there should be a UDP flag on the third line
	(the worst mistake in the book)

page 112, the here document probably should be quoted, i.e. <<'!'

page 182: In the caption to figure 11.1 there probably be a
	"," between "FTP" and "/etc/group" on the second line.

page 189, Table 11.1	port 2592 is the used by the game Netrek, both in
	UDP and TCP.

page 189: Port 2592 is used by servers for netrek, a multi-player
	network game that is certainly still available (see rec.games.netrek).
	Some netrek servers use different port numbers because of firewalls
	blocking port 2592, so 3001 could also be a netrek port.  (Early netrek
	implementations used TCP; all modern ones use UDP after TCP
	initialisation.)  There even exists something called trekhopd that is
	used to allow netrek packets to get around firewalls that block certain
	ranges of UDP ports.

page 221: There is no equation (13.1).  The label appears mid-paragraph
	on page 221.  And "By prepending the secret to the desired" (second
	paragraph from bottom) reads strangely, I suspect a missing work after
	"secret".

page.250: the TCP port number for http (WWW) should be 80, not 83.
	(Ouch!)

Our thanks to
	bhatiani@jpmorgan.com, James Cameron, Jerry Cole, Steve Cooper,
	John Halperin, ian@sq.com, Tom ``Meph'' Kelly, Dave Mack, Lars Thegler,
	Danny Yee



Errors in the third printing:

Christopher Klaus wrote ISS.  We neglected to give
	credit, and apologize.



Update and commentary:

The gateway described in the book has been running for over a year now.
Its success has caused its performance to degrade:  we often see transfers
as slow as 20KB/second in the middle of the day.  We rewrote the 'relay'
and 'proxy' programs to use 'select' rather than forking off an extra process.
Though this didn't change performance much, it cut the number of running processes
in half.

Various incidents have cause the external host (ninet) to fill up.  (It turns
out that any hardware design at all will eventually be swamped in the face of
exponential growth.) Most recently, we began swapping (gasp!), a very bad
thing.  The simple upgrade from 32MB to 96MB did the trick on that one.
I am planning to goose up the file cache size to, perhaps, 20MB to stop using
the disk at all.

The mail load has increased as well.  On one recent day I measured 20,000
messages in a day.  The load came principly from several popular mailing
lists like the recent flurry on comp.lang, as well as some smaller private
lists.

It is clear that we are going to need much greater performance, and the new
host arrived today.  We'll let you know about the new design when we see
if the approach works well enough.


Bill Cheswick
Steve Bellovin
	-11 October 1994