PE> It also doesn't say "Don't print out the message and stick it
 PE> up Bob's backside". BFN. Paul.
 
 BL>   Exactly. I am allowed to stick your messages up my arse, and I am
 BL> allowed to send #1 in text.

 PE> Nope.  For the same reason you're not allowed to go:

 PE> echo "fred" >temp.pkt

  Many things are defined and many are not. The most accurately
specified and least ambiguous part of FTS-1 is the date/time string,
yet you admit that the 20-byte specification may be something else in
some messages.

  The reality is that anything may be sent that can be processed and
sent. There are just a few fundamental invariables in PKT format, and
all of these revolve around the null. If you have too many or too few
nulls, the format falls apart:

1.  The packet header must be 58 bytes or less. The reason for this is
    that there may be stray nulls in there.

2.  The messaage header must be 14 bytes or less, for the same reason.
    The beginning and end 2-bytes don't matter a rat's arse. 10-bytes
    would work okay.

3.  The address information in the headers must be correct or messages
    will go to random addresses.

4.  There must be a null following date/time, to, from, subject, and
    message... 5 nulls per message. It doesn't really matter what's in
    between the nulls... except AREA:AREA_NAME following the 2nd-last
    null if you want e-mail.

6.  The two nulls on the end of the packet don't matter a rat's arse.

  If I sent a message obeying *just* those fundamentals it would be
processed unless some smartarse like you added a whole lot of other
checking not basic to correct processing. The message would be
correctly delivered, just as I sent it.

  Obvioulsy, if I sent a PKT with just FRED in it, it would not pass
these basic tests. You will observe that nowhere in my basics is '01
mentioned.

  You don't understand Fido very well, do you? These few basics are
what makes it work so well.

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---