Re: Netmail issue
By: Alan Ianson to Rob Swindell on Sun Oct 25 2020 08:41 pm
Hello Rob,
The QWK format actually has its own unique line-ending sequence: 227 (0xE3). I don't know the history/reason why (ASCII 10, '\n', seems
like it would have worked fine). According to one QWK spec, this was
to "save space", but that doesn't really make sense. Anyway, MultiMail and (presumably) other QWK readers do not actually wrap text with
CRLF, though perhaps they should. :-)
Multimail does seem to wrap message text with CRLF line endings, or maybe it's the editor that does that. I can seem if I inspect messages in a BW reply packet before uploading.
I was talking about QWK, not BW (assuming you're referring to BlueWave format).
and I think MBSE does that with messages saved on the BBS also.
Should be okay if it does. FidoNet messages are supposed to be '\r' terminated paragraphs (line-feeds are ignored), so where FidoNet is concerned, CRLF or CR should work fine.
I had a look at a message I posted in MBSE inside a .pkt that was waiting in the outbound. It also had CRLF line endings although they may have been put there by the editor also. That's not a problem on an 80x25 screen, it looks good. If you look at that on a wider screen it'll still be wrapped for that 80 character wide terminal, unless your terminal can unwrap it for you.
Okay, but that's just a cosmetic thing. I don't think that's relevant to this message thread.
I'm looking at these messages inside of .pkt files. These lines
start with a CRLF, it's completely out of place there.
It should be fine. The only case where it would not be fine is control paragraphs (kludge lines) which must begin with a single CR (0x0D) character.
I'm not sure what a control paragraph should look like so I can't say if it is correct or not.
A control paragraph (FTN kludge line) betweens with CR (Ctrl-M) and ASCII 1 (Ctrl-A) unless it's the beginning of the text in which case the CR is optional.
Would you mind looking over this packet and tell us what you think? I think you could explain what is happening, if anything better than I can.
http://trmb.ca/5f0abae3.pkt
Here's the hex dump of that packet:
00000: F5 02 F5 02 E4 07 09 00 - 13 00 10 00 07 00 2F 00 : ............../. 00010: 00 00 02 00 99 00 99 00 - FF 01 44 41 59 54 49 4D : ..........DAYTIM 00020: 45 00 01 00 01 00 00 00 - 00 01 11 00 01 00 01 00 : E............... 00030: 01 00 00 00 03 00 6D 62 - 73 65 02 00 F5 02 F5 02 : ......mbse...... 00040: 99 00 99 00 81 00 00 00 - 31 39 20 4F 63 74 20 32 : ........19 Oct 2 00050: 30 20 20 31 36 3A 30 35 - 3A 34 32 00 41 6C 61 6E : 0 16:05:42.Alan 00060: 20 49 61 6E 73 6F 6E 00 - 41 6C 61 6E 20 49 61 6E : Ianson.Alan Ian 00070: 73 6F 6E 00 4A 75 73 74 - 20 61 20 74 65 73 74 00 : son.Just a test. 00080: 01 49 4E 54 4C 20 31 3A - 31 35 33 2F 37 35 37 20 : .INTL 1:153/757
That's a well formed control paragraph (for INTL).
00090: 31 3A 31 35 33 2F 37 35 - 37 0A 0D 01 46 4D 50 54 : 1:153/757...FMPT
That's a control paragraph that begins with LF CR 01 which is pretty unusual, but legal (remember, linefeeds are ignored).
000A0: 20 32 0A 0D 01 54 4F 50 - 54 20 33 0A 0D 01 4D 53 : 2...TOPT 3...MS
More control paragraphs beginning with LF CR 01.
000B0: 47 49 44 3A 20 31 3A 31 - 35 33 2F 37 35 37 2E 32 : GID: 1:153/757.2 000C0: 20 64 39 63 38 35 37 36 - 34 0A 0D 01 54 5A 55 54 : d9c85764...TZUT 000D0: 43 3A 20 2D 30 37 30 30 - 0A 0D 01 43 48 41 52 53 : C: -0700...CHARS 000E0: 45 54 3A 20 4C 41 54 49 - 4E 2D 31 0A 0D 48 65 6C : ET: LATIN-1..Hel
That's interesting: it's also terminating control paragraphs with LF CR, so the LF is not actually part of the control paragraph as control parameters are terminated by a CR. That's pretty weird.
000F0: 6C 6F 20 41 6C 61 6E 2C - 0A 0D 0A 0D 54 68 69 73 : lo Alan,....This
There's a line terminated by LF CR LF.
00100: 20 69 73 20 6A 75 73 74 - 20 61 20 74 65 73 74 2E : is just a test. 00110: 0A 0D 0A 0D 2D 2D 2D 20 - 42 42 42 53 2F 4C 69 36 : ....--- BBBS/Li6
And a line terminated by LF CR LF CR.
00120: 20 76 34 2E 31 30 20 54 - 6F 79 2D 34 0A 0D 01 56 : v4.10 Toy-4...V 00130: 69 61 3A 20 31 3A 31 35 - 33 2F 37 35 37 2E 32 20 : ia: 1:153/757.2 00140: 40 32 30 32 30 31 30 31 - 39 2E 31 36 30 35 35 36 : @20201019.160556 00150: 20 42 42 42 53 2F 4C 69 - 36 20 76 34 2E 31 30 20 : BBBS/Li6 v4.10 00160: 54 6F 79 2D 34 0A 0D 01 - 56 69 61 20 31 3A 31 35 : Toy-4...Via 1:15 00170: 33 2F 37 35 37 40 66 69 - 64 6F 6E 65 74 20 40 32 : 3/757@fidonet @2 00180: 30 32 30 31 30 31 39 2E - 32 33 30 37 34 37 2E 55 : 0201019.230747.U 00190: 54 43 20 6D 62 66 69 64 - 6F 20 31 2E 30 2E 37 2E : TC mbfido 1.0.7. 001A0: 31 38 0D 00 00 00 : 18....
These last control paragraphs are *following* the message text, but they still appear valid. Only the last one has the expected single CR (0D) as a terminator.
So... lots of weird stuff, but nothing that appears to violate spec that I noticed.
This is a test message I wrote to myself from 757.2 to 757.3 and this is the .pkt that MBSE created for 757.3. This packet contains (I think) uneeded and unwanted CRLF's at the beginning of lines.
http://trmb.ca/d319271e.pkt
This is the input .pkt that was sent to 153/757 to forward on to 757.3 if you would like to look. It contain CRLF's as you'd expect.
Here's a hex dump of the packet:
00000: F5 02 F5 02 E4 07 09 00 - 13 00 10 00 05 00 38 00 : ..............8. 00010: 00 00 02 00 FF FF 99 00 - FF 00 44 41 59 54 49 4D : ..........DAYTIM 00020: 45 00 01 00 01 00 99 00 - 00 01 01 00 01 00 01 00 : E............... 00030: 01 00 02 00 00 00 00 00 - 00 00 02 00 F5 02 F5 02 : ................ 00040: 99 00 99 00 81 00 00 00 - 31 39 20 4F 63 74 20 32 : ........19 Oct 2 00050: 30 20 20 31 36 3A 30 35 - 3A 34 32 00 41 6C 61 6E : 0 16:05:42.Alan 00060: 20 49 61 6E 73 6F 6E 00 - 41 6C 61 6E 20 49 61 6E : Ianson.Alan Ian 00070: 73 6F 6E 00 4A 75 73 74 - 20 61 20 74 65 73 74 00 : son.Just a test. 00080: 01 49 4E 54 4C 20 31 3A - 31 35 33 2F 37 35 37 20 : .INTL 1:153/757 00090: 31 3A 31 35 33 2F 37 35 - 37 0D 01 46 4D 50 54 20 : 1:153/757..FMPT 000A0: 32 0D 01 54 4F 50 54 20 - 33 0D 01 4D 53 47 49 44 : 2..TOPT 3..MSGID 000B0: 3A 20 31 3A 31 35 33 2F - 37 35 37 2E 32 20 64 39 : : 1:153/757.2 d9 000C0: 63 38 35 37 36 34 0D 01 - 54 5A 55 54 43 3A 20 2D : c85764..TZUTC: - 000D0: 30 37 30 30 0D 01 43 48 - 41 52 53 45 54 3A 20 4C : 0700..CHARSET: L 000E0: 41 54 49 4E 2D 31 0D 48 - 65 6C 6C 6F 20 41 6C 61 : ATIN-1.Hello Ala 000F0: 6E 2C 0D 0D 54 68 69 73 - 20 69 73 20 6A 75 73 74 : n,..This is just 00100: 20 61 20 74 65 73 74 2E - 0D 0D 2D 2D 2D 20 42 42 : a test...--- BB 00110: 42 53 2F 4C 69 36 20 76 - 34 2E 31 30 20 54 6F 79 : BS/Li6 v4.10 Toy 00120: 2D 34 0D 01 56 69 61 3A - 20 31 3A 31 35 33 2F 37 : -4..Via: 1:153/7 00130: 35 37 2E 32 20 40 32 30 - 32 30 31 30 31 39 2E 31 : 57.2 @20201019.1 00140: 36 30 35 35 36 20 42 42 - 42 53 2F 4C 69 36 20 76 : 60556 BBBS/Li6 v 00150: 34 2E 31 30 20 54 6F 79 - 2D 34 0D 00 00 00 : 4.10 Toy-4....
There are *no* CRLF's in the packet.
--
digital man
Sling Blade quote #20:
Doyle: Hey is this the kind of retard that drools and rubs shit in his hair? Norco, CA WX: 58.8øF, 78.0% humidity, 4 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)