Text 15399, 69 rader
Skriven 2011-08-29 15:22:29 av Rob Swindell (44436.linux)
  Kommentar till text 15396 av Maurice Kinal (1:261/38.9)
Ärende: for the record
======================
  Re: for the record
  By: Maurice Kinal to Rob Swindell on Mon Aug 29 2011 03:27 pm

 > Hey Rob!
 >
 >  RS> If you're parsing out the message body text from a packet and
 >  RS> viewing just the body text with standard *nix tools, then none.
 >
 > Not quite none since the nonreadable codes still have to be dealt with,
 > not to mention that the actual message body requires determination
 > from the raw pkt.
 >
 >  RS> That's no longer packet data.
 >
 > What is being displayed is no longer pkt or msg data.  Displaying that
 > will cause much grief if not properly filtered first or as you have
 > pointed out simply ignored.  Easier to filter than ignore.
 >
 >  RS> I was referring to the entire packet though.
 >
 > vim can do that.  Same with mcedit and I assume other text editors.
 > So far for raw pkt's mcedit seems to be the 'best' but that is
 > probably due to it's more DOS-like behavior.  It 'sees' 0x0d's as
 > valid linefeeds whereas vim just displays those as '^M's in the message
 > body and '13 U+000D' on the statusline, or at least here it does.

A 0x0d is a carriage-return, not a linefeed, If you have an editor that is
treating it as a new-line sequence, then that is different than "seeing it as a
linefeed". Anyway, glad you have combination that works for you.

 >  RS> Yes, of course: the DateTime, toUserName, fromUserName and subject
 >  RS> are all variable-length null-terminated ASCII text header fields.
 >
 > But none of those are in the pkt header.  Those are all after the
 > first 14 bytes of the packed msg header.

I guess you could argue that only the first 14 bytes are the header, but I
would argue that the header is everytyhing preceding the body text and in this
case that includes the fields I mentioned above. And correcting what I said
above, the DateTime field is fixed length (always 20 bytes).

 > The only ascii I see in
 > the pkt header - first 58 bytes of the raw pkt - is the 8 ascii
 > nulls some call the 'password' field.

In a type 2.0 packet, the password is the only ASCII field, but in type 2.2
packets, the header includes optional domains (for 5D addresses). So yes, there
is ASCII text in both the packet header and the packed message headers.

 > As luck would have it the 16
 > bit pkt terminator at the end of the file poses as two ascii nulls
 > and thus is easily stripped out so that the remaining ACTUAL ascii
 > nulls can be used as field seperators once the pkt header and first
 > 14 bytes of the msg header(s) are sent to the bit bucket where they
 > truly belong.  All those are what I was querying you about.  Do you
 > use any of that internally?

The packed message header fields are important as they include the to/from/date
of the message. If you're referring to only the first 14 bytes of the packed
message header, yes, the originating and destination addresses are stored and
displayed to the reader of the message. The only packed-message "attribute"
flag used by Synchronet/SBBSecho is the "private" attribute.

                                            digital man

Synchronet "Real Fact" #73:
Vertrauen went online (as a WWIV BBS running on a 10MHz PC-XT clone) in 1988.
--- SBBSecho 2.12-Win32
 * Origin: Vertrauen - vert.synchro.net (1:103/705)