FM> Therefore we must look for AREA: before *any* other lines, and THERE
 FM> MUST BE AT LEAST ONE 0x01 LINE. If there is no reason to generate any
 FM> other 0x01, then you might as well generate ^aSOT: and therefore you
 FM> might as well generate it *all* the time.

 FM> I think that is sufficient to make the case for ^aSOT:

  Beautifully reasoned. My only criticism is that the ^aSOT: does not
convey any information. A blank line (#13) would do the same, or at
most, #1#13.

 FM> There's *nothing* you can do with messages from software which
 FM> doesn't generate ^aSOT:, happens not to generate any other 0x01
 FM> lines before the user text, and the user types AREA: at the
 FM> beginning of the first line of a netmail message.

  Yes there is! You can do a more exhaustive check, adding more
information. FTS-4 defines capitals and no spaces. Instead of just
cheacking AREA: you could read the entire line which must be all
capitals and no spaces. You could even set the maximum length of a
line (80 bytes, say).

  Logically, it will never be perfect, but you can improve the odds
against an accidental fault. This is why I assumed a spiteful bastard.

 FM> No case for ^EOT: here.

  You ought to put your logical mind to creating a case *against*
EOT. There's a good case!   

 FM> SUMMARY

 FM> There is no case for ^aEOT:. You should generate tear and
 FM> origin lines in that order at the end of your message, and add
 FM> seen-by lines to the end of a message.

 FM> There is a case for ^aSOT:, certainly if you have generated no
 FM> other 0x01 lines at the beginning of a netmail message.

  Good summary. I'd like to see your case against SOT/EOT, now.

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

---