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

 BL>   Your argument falls apart at Prophet, though, doesn't it? If no one
 BL> checks faulty addresses, every message ever sent would keep rotating.

Actually, I tell a lie, if I send a message to someone in Zone 2,
with an incorrect address, it gets bounced somewhere in Zone 2,
not by Prophet.  I'm not sure what algorithm Prophet uses to
bounce messages.

 BL>   But even if we limited the addresses to 128 zones, 4096 nets and
 BL> 16,384 nodes, it would still give us 8-billion addresses. How many
 BL> do we need? My guess is that 8-billion is plenty - one each.

The zones represent a continent, at least in Fidonet.  Different
networks use different zones (or even the same zones), e.g.
Adultnet is 69.

 BL>   BTW, I'm looking at pkt2qwk - and it creates numbers at the end of
 BL> the qwk message header, where the qwk packets from BlueWave and the
 BL> SPCUG have spaces. BlueWave seems happy enough to them ignore anyway,
 BL> but these numbers are not supposed to be there.

It could be uninitialized data, or it could be something in the
standard you aren't aware of.

 BL>   BTBTW... I've found a nuisance with your "EOT:" proposal in PKT.

 BL>   I'm making my VB version of pkt2qwk, and when you read the message
 BL> to convert to QWK, the "SOT:" goes in seamlessly. I read
the message
 BL> looking for the 0x00 terminators, and then the "AREA:" at
the head of
 BL> the message, and then "SOT:". If I don't find it, I use
the previous
 BL> reference as the actual message-start. No worries. Foolproof, and
 BL> nicely compatible.
 
You're meant to be stripping SOT, no?  You want to strip all 
lines starting with x'01', as they are of no interest to the
message recipient. 

 BL>   At the other end, it's not so nice. If you look for "EOT:" first,
 BL> and it is missing, you will pick up the next one in the next message
 BL> and break the packet. You have to look for the 0x00 message terminator
 BL> first, and then come back to find "EOT:". This is the messy part.

You should always look for the x'00' first.  How are you stripping
SEENBY lines?

 BL>   A much nicer method would be to have the "EOT:" at a *fixed*
 BL> distance from the 0x00 message-terminator, or even a maximum distance
 BL> that you could use to check one against the other, and be sure you
 BL> are in the same message. You could do the same thing with the
"SOT:"
 BL> header. As well as closing off the message, it would give you a way to
 BL> do double-checking, and still be backwards compatible if the SOT and EOT
 BL> were missing.

 BL>   Since all this takes place in the actual message, it would not break
 BL> the FTS-0001 standard. All you would have to do is pad after
"EOT:" with
 BL> spaces to keep the spacing from the null terminator at 128 bytes or
 BL> whatever you think is enough to add the origin, path and seenby.

 BL>   What do you think?

Have you actually read FSC-XXXX.000?  It is meant to solve a
specific problem, and it is meant to be simple to create,
because it's main purpose is to protect SEENBYs in the user
text from proper SEENBYs.  It is to provide a clear distinction
between user text and control lines.  BFN.  Paul.
@EOT:

--- Mksmsg