• Netmail issue

    From Alan Ianson@1:153/757 to All on Sat Oct 17 15:26:54 2020
    Hello All,

    I have recieved (with MBSE) 21:4/106 a netmail for a point (running Mystic) 21:4/106.2. This netmail keep bouncing between 4/106 and 4/106.2, it is addresses to 4/106.2. Looking inside the .pkt it contains ^M at the
    beginning of each line and I have never seen that before.

    Is there an MBSE developer who can look at that .pkt and see if they see anything wrong? I have also recieved mail via MBSE to BBBS. BBBS imported
    that netmail fine, but there was a blank line between sentences making me
    think there may be a problem with ^M that should not be there, or something like that.

    If you can please have a look at that .pkt.

    http://trmb.ca/mys_mbse.pkt

    Any ideas/input appreciated.

    Ttyl :-),
    Al

    ... Nothing is foolproof. Fools are too ingenious.

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Vincent Coen@2:250/1 to Alan Ianson on Sun Oct 18 17:06:34 2020
    Hello Alan!

    Saturday October 17 2020 15:26, you wrote to All:

    I have recieved (with MBSE) 21:4/106 a netmail for a point (running
    Mystic)
    21:4/106.2. This netmail keep bouncing between 4/106 and 4/106.2, it
    is addresses to 4/106.2. Looking inside the .pkt it contains ^M at the beginning of each line and I have never seen that before.

    Is there an MBSE developer who can look at that .pkt and see if they
    see anything wrong? I have also recieved mail via MBSE to BBBS. BBBS imported that netmail fine, but there was a blank line between
    sentences making me think there may be a problem with ^M that should
    not be there, or something like that.

    If you can please have a look at that .pkt.

    http://trmb.ca/mys_mbse.pkt

    Any ideas/input appreciated.

    IF you go to applewoodbbs.linkpc.net you can grab the file pktview-990727.zip


    just has the linux program pktview and to use supply the path and packet name to the program for a detailed on screen report.

    I.e., pktview var/inbound/ca123456.pkt

    Compiled under Linux - Magiea v7.1 X64 Note it is compiled for 64 bit Linux.


    Just tred it with your packet a lot of via lines - heavy data loop so skipping them :

    --
    mys_mbse.pkt:
    Detected Type 2+ packet
    -!- PACKET HEADER ---
    Packet version : 2
    Capability word : 0001
    Capability validation : 0100
    Product code : 17.254
    Product revision : 1.0
    Product specific info : 6500026573626D
    Date and time : 2020-10-17 15:01:05
    Originating zone : 21
    Originating net : 65535
    Originating node : 106
    Originating point : 2
    Destination zone : 21
    Destination net : 4
    Destination node : 106
    Destination point : 0
    Auxiliary net : 4
    Baudrate : 0
    Password : XXXXXXX
    -!- PACKED MESSAGE #1 ---
    Version : 106
    Originating net : 257
    Originating node : 1
    Destination net : 0
    Destination node : 4
    Cost : 20256
    Attributes : Pvt F/A I/T Hld (?) Rrq Cpt
    Date and time : ct 20 11:45:18
    From : Paul Hayton
    To : Alan Ianson
    Subject : Re: Test!
    Control information:
    ^AINTL 21:4/106 21:1/101

    ^ATOPT 2

    ^ATID: Mystic BBS 1.12 A46
    ^AMSGID: 21:1/101 1d15bc10

    ^AREPLY: 21:4/106.2 c55f7399

    ^ATZUTC: 1300

    ^AVia 21:1/100 @20201015.224530.UTC Mystic 1.12 A46

    ^AVia 21:4/100 @20201015.224559.UTC Mystic 1.12 A46

    ^AVia 21:4/106@fsxnet @20201015.224557.UTC mbfido 1.0.7.18

    ^AVia 21:4/106.2 @20201015.224607.UTC Mystic 1.12 A47
    --



    Seen some thing like this before and the sender is NOT in Fidonet so your routing table should have helped to reject (delete) it.


    Vincent

    --- Mageia Linux v7.1 X64/Mbse v1.0.7.17/GoldED+/LNX 1.1.5-b20180707
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Alan Ianson@1:153/757 to Vincent Coen on Sun Oct 18 15:36:09 2020
    Vincent Coen wrote to Alan Ianson:

    http://trmb.ca/mys_mbse.pkt

    Any ideas/input appreciated.

    Thanks for having a look.

    IF you go to applewoodbbs.linkpc.net you can grab the file pktview-990727.zip

    I do have pktinfo from the husky project. It doesn't give me any clues about what might be wrong.

    Just tred it with your packet a lot of via lines - heavy data loop so skipping them :

    Yes, this netmail is bouncing between 4/106 and 4/106.2

    Seen some thing like this before and the sender is NOT in Fidonet so your routing table should have helped to reject (delete) it.

    No!

    This is a legitimate netmail in zone 21 so we want to deliver it in a way
    that the reciever can toss it. We want to do that in all zones.

    Did you notice that netmail had lines beginning with a CRLF or ^M? I think
    that is a problem and might be the reason the netmail is not being tossed at the recieving node.

    I have seen this also in Fidonet when I recieve mail at my point
    1:153/757.2. In that case the netmail is tossed at point 2 but there is a
    blank line between every line.

    Ttyl :-),
    Al

    ... You cannot achieve the impossible without attempting the absurd.

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Sean Dennis@1:18/200 to Alan Ianson on Mon Oct 19 11:25:26 2020
    Hello Alan,

    Sunday October 18 2020 15:36, you wrote to Vincent Coen:

    Did you notice that netmail had lines beginning with a CRLF or ^M? I
    think that is a problem and might be the reason the netmail is not
    being tossed at
    the recieving node.

    Is the message originating on a Mystic BBS and being sent to a MBSE system?

    Blank lines, ones with CRLF, are normally ignored for processing and left as-is. I think there are other issues going on. Could you send me a copy of the message "as-is"? I can take a look at it here and see if I can see anything.

    Later,
    Sean

    --- GoldED/2 3.0.1
    * Origin: Outpost BBS * bbs.outpostbbs.net:10123 (1:18/200)
  • From Alan Ianson@1:153/757 to Sean Dennis on Mon Oct 19 15:41:34 2020
    Sean Dennis wrote to Alan Ianson:

    Did you notice that netmail had lines beginning with a CRLF or ^M? I think that is a problem and might be the reason the netmail is not being tossed at the recieving node.

    Is the message originating on a Mystic BBS and being sent to a MBSE system?

    Yes, the .pkt at http://trmb.ca/mys_mbse.pkt was sent to me from a Mystic system, I requested a test from that node in Z21.

    Blank lines, ones with CRLF, are normally ignored for processing and left as-is. I think there are other issues going on. Could you send me a copy

    of the message "as-is"? I can take a look at it here and see if I can see

    anything.

    Thanks for looking into it. I will create a fresh .pkt from BBBS to another point I have set up here and pass it through MBSE so you can see the input
    .pkt and also the output .pkt that MBSE creates.

    I'll attach those directly to your node in a zip file shortly.

    Ttyl :-),
    Al

    ... Why do we say something is out of whack? What is a whack?

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Andrew Leary@1:320/319 to Alan Ianson on Thu Oct 22 11:37:05 2020
    Hello Alan!

    19 Oct 20 15:41, you wrote to Sean Dennis:

    Thanks for looking into it. I will create a fresh .pkt from BBBS to another point I have set up here and pass it through MBSE so you can
    see the input .pkt and also the output .pkt that MBSE creates.

    I'll attach those directly to your node in a zip file shortly.

    Copy me on this also. I looked at your packet briefly, but it would help to see the packet that Mystic created when sending the message back to the MBSE system. My initial impression is that Mystic isn't detecting that the message is for it, and is thus sending it back to your MBSE system. MBSE sees that it is for the point system, and sends it back there.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: MBSE BBS Development (1:320/319)
  • From Alan Ianson@1:153/757 to Andrew Leary on Thu Oct 22 15:29:22 2020
    Andrew Leary wrote to Alan Ianson:

    I'll attach those directly to your node in a zip file shortly.

    Copy me on this also.

    I will do that here in a few minutes.

    I looked at your packet briefly, but it would help to see the packet that Mystic created when sending the message back to the MBSE system. My initial impression is that Mystic isn't detecting that the message is for it, and is thus sending it back to your MBSE system.

    Yes, I think that is what is happening. Looking at Mystic's log it seems to think that message is To: the node it came from. I'm not sure why that is.

    MBSE sees that it is for the point system, and sends it back there.

    Yes, MBSE is doing the right thing to send it back there. I can send a
    message to that point from my MBSE system and it is imported without any issues.

    Ttyl :-),
    Al

    ... Circular Definition: see Definition, Circular

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Andrew Leary on Thu Oct 22 16:24:38 2020
    Andrew Leary wrote to Alan Ianson:

    Copy me on this also.

    I have attached a zip with these packets to 1:320/319 but I am not getting a connect with your mailer, not sure why.

    Can you poll 1:153/757 and pick it up or would you like me to direct it to a different node?

    Ttyl :-),
    Al

    ... Error: The system has been taken over by sheep at line 19960

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Andrew Leary@1:320/319 to Alan Ianson on Thu Oct 22 20:03:00 2020
    Hello Alan!

    22 Oct 20 16:24, you wrote to me:

    I have attached a zip with these packets to 1:320/319 but I am not
    getting a connect with your mailer, not sure why.

    I'm getting "Network is unreachable" when trying to poll you from 1:320/319.

    Can you poll 1:153/757 and pick it up or would you like me to direct
    it to a different node?

    You can send it to me at 1:320/219; I'll be watching for it.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: MBSE BBS Development (1:320/319)
  • From Alan Ianson@1:153/757 to Andrew Leary on Thu Oct 22 18:04:08 2020
    Andrew Leary wrote to Alan Ianson:

    I have attached a zip with these packets to 1:320/319 but I am not getting a connect with your mailer, not sure why.

    I'm getting "Network is unreachable" when trying to poll you from 1:320/319.

    Hmm.. that's a problem but I'm not sure what it is.

    Can you poll 1:153/757 and pick it up or would you like me to direct it to a different node?

    You can send it to me at 1:320/219; I'll be watching for it.

    I did send it there. Thank you for looking this over and let me know if I
    can help in some way.

    Ttyl :-),
    Al

    ... You don't get once-in-a-lifetime offers like this every day.

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Andrew Leary@1:320/219 to Alan Ianson on Fri Oct 23 07:18:18 2020
    Hello Alan!

    22 Oct 20 18:04, you wrote to me:

    I'm getting "Network is unreachable" when trying to poll you from
    1:320/319.

    Hmm.. that's a problem but I'm not sure what it is.

    It seems to be a routing issue between our respective ISPs.

    I did send it there. Thank you for looking this over and let me know
    if I can help in some way.

    I will examine the packets and see if I can find any additional information.

    Andrew

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Sean Dennis@1:18/200 to Alan Ianson on Fri Oct 23 12:28:59 2020
    Hello Alan,

    Monday October 19 2020 15:41, you wrote to me:

    I'll attach those directly to your node in a zip file shortly.

    I will look at them this weekend. I have unfortunately been busy with personal issues this week and the BBSes have been needing attention.

    Later,
    Sean

    --- GoldED/2 3.0.1
    * Origin: Outpost BBS * bbs.outpostbbs.net:10123 (1:18/200)
  • From Sean Dennis@1:18/200 to Alan Ianson on Fri Oct 23 13:34:02 2020
    Yes, the .pkt at http://trmb.ca/mys_mbse.pkt was sent to me from a
    Mystic system, I requested a test from that node in Z21.

    I'll be looking at those packets later today but unfortunately Mystic has a
    bad track record of having a buggy mail system. Things eventually do get
    fixed but it seems to be only after there's a lot of people complaining
    about it. Then again, a misconfigured BBS is always a possibility.

    Thanks,
    Sean

    ___ MultiMail/Linux v0.52

    --- Maximus/2 3.01
    * Origin: Outpost BBS * bbs.outpostbbs.net:10123 (1:18/200)
  • From Sean Dennis@1:18/200 to Alan Ianson on Fri Oct 23 13:52:08 2020
    I'll attach those directly to your node in a zip file shortly.

    I agree with Andrew. It's an issue with Mystic that is seeming to be caught
    in a loop by recognizing mail that is originating from that system as being destined for that system.

    I have no clue what could be causing that, unfortunately.

    I'm sorry I couldn't be of more help. Other than that, I couldn't see any issues with the mail in question.

    Later,
    Sean

    ___ MultiMail/Linux v0.52

    --- Maximus/2 3.01
    * Origin: Outpost BBS * bbs.outpostbbs.net:10123 (1:18/200)
  • From Alan Ianson@1:153/757 to Sean Dennis on Sat Oct 24 00:44:17 2020
    Sean Dennis wrote to Alan Ianson:

    Yes, the .pkt at http://trmb.ca/mys_mbse.pkt was sent to me from a Mystic system, I requested a test from that node in Z21.

    I'll be looking at those packets later today but unfortunately Mystic has bad track record of having a buggy mail system.

    I'll take that up with James if there are problems with Mystic.

    My concern with MBSE is that packets it creates for my points contain lines beginning with a CRLF. MBSE is running well for me generally, netmail to or from my own node. This only seems to happen with netmail passing through
    MBSE to one of my points.

    I'm not sure if that is happening with all netmail passing through MBSE or
    if it just happens with points.

    Ttyl :-),
    Al

    ... I'm just looking at your nametag, honest!

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Sean Dennis@1:18/200 to Alan Ianson on Sat Oct 24 12:04:22 2020
    Hi Alan,

    bad track record of having a buggy mail system.

    I'll take that up with James if there are problems with Mystic.

    I want to clarify that I am not ripping on Mystic. There were problems with its BinkD server for quite a while and lately I have seen a lot of issues with mail involving Mystic. I have never used it so I am simply going by what I've read. I know James will get around to fixing things.

    I'm not sure if that is happening with all netmail passing through MBSE or if it just happens with points.

    When I last ran MBSE I had no issues with netmail but I didn't have any points to work with. Perhaps this is an issue we need to delve further into.

    I have been very slow with setting up MBSE again here with a lot of personal issues getting in the way. I am hoping to do some work later today in getting the mail system set up. I'm also working on getting DOSemu working right. I was using the FreeDOS binary that DOSemu comes with but it wasn't working right so I downloaded a MS-DOS 6.22 boot disk and am going to try to get that working. I have scaled down the number of doors on my BBS to about five or six (not counting my own Cheepware doors) so that shouldn't take long to fix.

    It's always something ...

    Later,
    Sean


    --- Maximus/2 3.01
    * Origin: Outpost BBS * bbs.outpostbbs.net:10123 (1:18/200)
  • From Vincent Coen@2:250/1 to Sean Dennis on Sat Oct 24 17:52:35 2020
    Hello Sean!

    Saturday October 24 2020 12:04, you wrote to Alan Ianson:

    I'm not sure if that is happening with all netmail passing
    through MBSE or if it just happens with points.

    When I last ran MBSE I had no issues with netmail but I didn't have
    any points to work with. Perhaps this is an issue we need to delve
    further into.

    I have at least one point system running here that is not me and am not having any reported or have seen any errors.



    Vincent

    --- Mageia Linux v7.1 X64/Mbse v1.0.7.17/GoldED+/LNX 1.1.5-b20180707
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Alan Ianson@1:153/757 to Vincent Coen on Sun Oct 25 02:15:57 2020
    Vincent Coen wrote to Sean Dennis:

    I have at least one point system running here that is not me and am not having any reported or have seen any errors.

    After doing a little testing with nodes I can confirm this is happening with all netmail passing through MBSE, not just points. I have never noticed this with mail to or from my own node.

    I dunno if that's really important or not, but I think that sums it up.

    Ttyl :-),
    Al

    ... Math problems? Call 1-800-10*(24+13)-(64-16)/2^14E2.

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Vincent Coen@2:250/1 to Alan Ianson on Sun Oct 25 12:46:50 2020
    Hello Alan!

    Sunday October 25 2020 02:15, you wrote to me:

    Vincent Coen wrote to Sean Dennis:

    I have at least one point system running here that is not me and
    am not having any reported or have seen any errors.

    After doing a little testing with nodes I can confirm this is
    happening with all netmail passing through MBSE, not just points. I
    have never noticed this with mail to or from my own node.

    I dunno if that's really important or not, but I think that sums it
    up.

    I cannot think of a reason why mbse a Linux product would create a Win/dos new line as that's the CRLF two bytes block as *nix ony uses one byte.

    Is this block being created from a msg created within mbse, i.e., say golded
    or other message editor ?


    Vincent

    --- Mageia Linux v7.1 X64/Mbse v1.0.7.17/GoldED+/LNX 1.1.5-b20180707
    * Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)
  • From Alan Ianson@1:153/757 to Vincent Coen on Sun Oct 25 11:32:27 2020
    Vincent Coen wrote to Alan Ianson:

    I cannot think of a reason why mbse a Linux product would create a Win/dos

    new line as that's the CRLF two bytes block as *nix ony uses one byte.

    I guess it's the DOS heritage of BBSing. Multimail and other QWK readers
    will wrap your text up with CRLF at the end of lines and I think MBSE does
    that with messages saved on the BBS also.

    CRLF has been a PITA since day one. It makes messages harder to format on a screen that is a different size than what it was saved on. It was great to format messages for an 80x25 screen when everyone was using that but not everyone uses that today.

    Is this block being created from a msg created within mbse, i.e., say golded or other message editor ?

    I'm looking at these messages inside of .pkt files. These lines start with a CRLF, it's completely out of place there.

    Ttyl :-),
    Al

    ... Always listen to experts, hear the impossible, then do it.

    --- MBSE BBS v1.0.7.18 (GNU/Linux-x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Alan Ianson@1:153/757 to Vincent Coen on Sun Oct 25 12:04:52 2020
    Hello Vincent,

    Is this block being created from a msg created within mbse, i.e.,
    say golded or other message editor ?

    I'm looking at these messages inside of .pkt files. These lines start
    with a CRLF, it's completely out of place there.

    Just to be a little more clear..

    Messages tossed by MBSE is adding the CRLF to .pkt's that it creates to send on to the destination node. Those CRLF's are not present in the input .pkt. Those messages are never tossed into the MBSE message base. As far as I know this is only happening with netmail that is being passed on to another node. I haven't noticed issues with netmail or echomail for my own node.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Rob Swindell@1:103/705 to Alan Ianson on Sun Oct 25 16:37:24 2020
    Re: Re: Netmail issue
    By: Alan Ianson to Vincent Coen on Sun Oct 25 2020 11:32 am

    Vincent Coen wrote to Alan Ianson:

    I cannot think of a reason why mbse a Linux product would create a Win/dos

    new line as that's the CRLF two bytes block as *nix ony uses one byte.

    I guess it's the DOS heritage of BBSing. Multimail and other QWK readers will wrap your text up with CRLF at the end of lines

    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. :-)

    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.

    CRLF has been a PITA since day one. It makes messages harder to format on a screen that is a different size than what it was saved on. It was great to format messages for an 80x25 screen when everyone was using that but not everyone uses that today.

    Right, and this is *one* thing that FidoNet actually got right:
    All linefeeds, 0AH, should be ignored. Systems which display message
    text should wrap long lines to suit their application.

    Is this block being created from a msg created within mbse, i.e., say golded or other message editor ?

    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.
    --
    digital man

    This Is Spinal Tap quote #25:
    Viv Savage: Have... a good... time... all the time. That's my philosophy. Norco, CA WX: 63.6øF, 67.0% humidity, 8 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Alan Ianson@1:153/757 to Rob Swindell on Sun Oct 25 20:41:11 2020
    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.

    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.

    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.

    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

    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.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Rob Swindell@1:103/705 to Alan Ianson on Sun Oct 25 21:49:59 2020
    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)