PE>> It is not possible to get "no address at all", the fields are
 PE>> binary numbers. The net + node are 16 bits.

 BL>   hex 00 00 must go pretty close to no address at all, especially if
 BL> the full address is 00 00: 00 00/ 00 00. 00 00. It'd make me
 BL> suspicious, anyway.

Presumably you are aware of the standard whereby 3:3/0 represents
the Zone 3 gate, 3:711/0 represents the node coordinator of net
711?  I'm not sure if 3:0/0 is the Zone Coordinator at all.

 PE>> Tell me which combination of 16 bits represents "no address at
 PE>> all".

 BL>   See above.

Better give me an FTS or Policy4 reference that says that 0:0/0 is
never a valid address while you're at it.

 PE>> Squish can't even check in the nodelist to see if an address is
 PE>> valid.

 BL>   I understand that, but I assumed that a sensible qwk2pkt would
 BL> produce hex 00 00 etc if it doesn't have an address (just null pad the
 BL> spaces), and that the first Squish would pick that up and default to
 BL> the first node, to prevent the mail being sent world-wide.

If you think that 0:0/0 should be converted into 3:711/934, then
you should put that into qwk2pkt, not squish.  BTW, the addresses
that pqwk221 put in were not 0:0/0 but 53:53690/223 or something
like that.

 BL>   The way I see it, obviously faulty mail should be kept local, to
 BL> save money. From what you've been saying, it just goes out to random
 BL> addresses, presumably passed from one BBS to the next all over the
 BL> world, looking for a home. From a user's point of view, an important
 BL> message just vanishes, and privacy is zilch.

It passes from one BBS to another waiting for someone who doesn't
know where to pass it.  That person so far has been Prophet for
mail that has left this system.

 PE>> I just pass everything on to Dave Hatch. Until it gets to
 PE>> someone who can't route it somewhere else, it will travel on
 PE>> it's merry way.

 BL>   Does Squish repack and rename packets, or do they just go complete?

repack and rename.  Any message from you may need to be sent to
multiple places, in the case of echomail, or routed to a particular
address in the case of netmail.  Although you may send 3 netmail
messages to me in packet, I may be sending them to 3 different
people.  E.g. mail to 3:690/718 will be sent to a different spot
to 3:711/850 because 3:690/718 calls me directly so I keep netmail
for him here.

 BL>   I hate to agree with Rod, but the whole principle of safety is based
 
It often means you end up backing the whacky alternative, doubly
so if it involves anything to do with fidonet. 
 
 BL> on *two* things having to go wrong before you get a failure. It is
 BL> silly to say that the software generating the packets ought to be
 BL> foolproof, and rely on that. One would hope that there is a
 
You have to rely on it, since you cannot possibly second-guess the
net address yourself.  If it's buggy, it should be fixed, or not
used.  Using non-conforming software on the net can land you with
a policy complaint. 
 
 BL> double-failure built into the software, but even if it does fail,
 BL> there should be a second failsafe at the next stage, so that *both*
 BL> have to fail before you get an actual failure.

Trouble is, every address is valid, according to the standard.

 BL>   This is the whole principle of failsafe procedures. I admit that it
 BL> is not always possible. If the wing falls of a 747 you're essentially
 BL> ratshit, but in those cases even *more* stringent procedures are imposed.

Yep, same as POLICY4 will get you for using invalid software.

 BL>   It's insane that a wrong address loses the mail and sends it anywhere.
 BL> The correct approach is to *assume* a wrong address and make sure the
 BL> damage is contained... as you did in PQWK222. IMO, Squish should default
 BL> bad mail to 3:711/934.0... or better still, use a lookup for your points
 BL> using the "To: name" field. Even an automatic system could do that.

It's none of my business where a node chooses to send netmail to.
With a couple of exceptions, I just have to give it to Dave.

 BL>   yair... but 0x2020 starts to look a bit weird. The two likely errors
 BL> would be hex 0000 and hex 2020. The chance of those being a correct
 BL> address is 1/64,000 even if you assume they are all equally possible.
 
It is extraordinary that you would seek to limit a value of 0x2020,
or 8224.  It's things like that that CAUSE problems. 

 BL>   I know 222 does that (which is why I'm using it). I wondered what
 BL> Rod's 202 did.

I just had a look, and I've still got 202 here.  I had a look,
and the code assumes the caller has set the default, which he
may have, I didn't trace it back far enough to tell.  I can 
send you the code if you're interested, I'm not.  I will most
likely to continue to fix bugs in the latest version, but not
put in any enhancements, but that's it.  The code is like
vomit.  BFN.  Paul.
@EOT:

--- Mksmsg