On Thu, 7 Sep 1995 11:31:35 CDT Marty Hoag <[log in to unmask]> said: >1. What is a good setting for the number of hops allowed? I think > sendmail defaults to 17 these days. I think this dates back to the 1980s, anyway it is ridiculously low for today's network. About 4 years ago a lot of TCP/IP products had to be changed to support a TTL larger than 25-30, which had been deemed to be an "impossible hop count" when the software was written. I think we're going to see just the same argument now: a. People with the hardcoded max TTL of 25-30 claiming that it made no sense at all to want to reach people more than 25-30 hops away. b. Users not caring about the finer points of network topology and noting that on the XXX they can reach their destination but on the YYY it doesn't work (substitute brand names as appropriate). c. People on the far end of a 20-odd network access point not having much of an option in the matter and trying to argue with the people in (a), unsuccessfully. Eventually they all upped the limit and everyone was happy. >2. Is there any way to add an option to LOCAL SYSVARS to make our local > unspecified header default SHORTHDR? If not, can that be added? Currently that isn't possible. An option could be added to make SHORTHDR the default value for new subscribers. Technically the problem is that the old coding scheme used one byte per option, with space being "unspecified" and internally mapped to some hardcoded value, whereas the new coding scheme uses one bit per option, so there is no "unspecified" setting. The old scheme took up too much space and was error-prone (each "user" of option X had to interpret the various possible values for the one-byte code, and in particular determine the meaning of "unspecified", and sometimes there were slight differences leading to inconsistent behaviour). In a first stage, all this logic was centralized so that the options were decoded by a single piece of code (and the meaning of "unspecified" determined similarly). This solved the consistency problem, but it was SLOW with large lists, because each option had to be decoded regardless of which were going to be used, and in some cases there were a lot of tests to make to determine the "unspecified" default. And of course there was the problem that each option took up at least a byte, and the list files would have to be reformatted every time a new option was added (as opposed to every 31 options). Basically, the old scheme was optimized for REXX code, the new one for compiled code. All in all the problem with SHORTHDR is that the people who wanted it killed here and now were VERY vocal (many threatened to stop paying for the software if this change wasn't made), whereas people who did not want the change hardly said anything. So, we thought no one really minded the change, given the existence of "Default-Options=" and all that, and acted accordingly. If we'd known there were many people opposed to the change, we could have added an option to save the "unspecified" state of the header flag and all sorts of other things, but now it's too late because the one-way conversion has been made. Eric