is there a tool available to read msg files in /sbbs/netmail and display the headers, attributes and control lines? i don't care about the message bodies...
i just want to make sure that routed netmails that have landed here have been processed and sent on... while i can look at the raw file, i can't easily see if the sent or received attributes have been set...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... They laughed at the Wright Brothers but they also laughed at Bozo.
---
* Origin: (1:3634/12.73)

Re: sbbs and ftn netmail routing
By: mark lewis to Digital Man on Sat Oct 06 2018 05:57 pm

is there a tool available to read msg files in /sbbs/netmail and display the headers, attributes and control lines? i don't care about the message bodies...

I have little program called msgdump (probably going to rename to fmsgdump). Run 'make msgdump' in src/sbbs3.

digital man

This Is Spinal Tap quote #26:
David St. Hubbins: They were still booing him when we came on stage.
Norco, CA WX: 72.0oF, 63.0% humidity, 10 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs and ftn netmail routing
By: Digital Man to mark lewis on Sat Oct 06 2018 15:51:43

I have little program called msgdump (probably going to rename to fmsgdump). Run 'make msgdump' in src/sbbs3.

that works...

i've forgotten a lot of C that i used to know... i did find and shove the following code in so that i could read the attributes easier... the code results in output like this... note the "Attr:" line...

Opening 1.msg
Subj: Re: Usenet feeds?
Attr: 0x0009 (00000000 00001001)
To : Rob Swindell (1.218/700.0)
From: Paul Hayton (3.770/100.0)
Time: 20 Sep 18 16:32:48

so now i know that that MSG has, reading from right to left, attributes FIDO_PRIVATE and FIDO_SENT... i'm hoping that in this case FIDO_SENT means that the message was sent on by sbbsecho to the next link (1:261/38) in the route from here to the destination... i chose this message because your system is the destination... i thought that you might confirm if it did arrive or not... it has MSGID: 3:770/100 7db1eea0...

and here's the patch... unfortunately, some lines (7) are wrapped...

----->8 snip 8<-----
$ diff -Naur msgdump.orig.c msgdump.c
-+- msgdump.orig.c 2018-09-06 22:49:30.000000000 -0400
+++ msgdump.c 2018-10-07 07:52:54.985185338 -0400
@@ -63,9 +63,36 @@
if(hdr.time[sizeof(hdr.time)-1] != 0)
fprintf(stderr,"%s Untermianted 'time' field\n", fname);

+/* --- PRINTF_BYTE_TO_BINARY macro's --- */
+#define PRINTF_BINARY_SEPARATOR " "
+#define PRINTF_BINARY_PATTERN_INT8 "%c%c%c%c%c%c%c%c"
+#define PRINTF_BYTE_TO_BINARY_INT8(i) \
+ (((i) & 0x80ll) ? '1' : '0'), \
+ (((i) & 0x40ll) ? '1' : '0'), \
+ (((i) & 0x20ll) ? '1' : '0'), \
+ (((i) & 0x10ll) ? '1' : '0'), \
+ (((i) & 0x08ll) ? '1' : '0'), \
+ (((i) & 0x04ll) ? '1' : '0'), \
+ (((i) & 0x02ll) ? '1' : '0'), \
+ (((i) & 0x01ll) ? '1' : '0')
+
+#define PRINTF_BINARY_PATTERN_INT16 \
+ PRINTF_BINARY_PATTERN_INT8 PRINTF_BINARY_SEPARATOR PRINTF_BINARY_PATTERN_INT8
+#define PRINTF_BYTE_TO_BINARY_INT16(i) \
+ PRINTF_BYTE_TO_BINARY_INT8((i) >> 8),
PRINTF_BYTE_TO_BINARY_INT8(i)
+#define PRINTF_BINARY_PATTERN_INT32 \
+ PRINTF_BINARY_PATTERN_INT16 PRINTF_BINARY_SEPARATOR PRINTF_BINARY_PATTERN_INT16
+#define PRINTF_BYTE_TO_BINARY_INT32(i) \
+ PRINTF_BYTE_TO_BINARY_INT16((i) >> 16),
PRINTF_BYTE_TO_BINARY_INT16(i)
+#define PRINTF_BINARY_PATTERN_INT64 \
+ PRINTF_BINARY_PATTERN_INT32 PRINTF_BINARY_SEPARATOR PRINTF_BINARY_PATTERN_INT32
+#define PRINTF_BYTE_TO_BINARY_INT64(i) \
+ PRINTF_BYTE_TO_BINARY_INT32((i) >> 32), PRINTF_BYTE_TO_BINARY_INT32(i)
+/* --- end macros --- */
+

printf("Subj: %.*s\n", sizeof(hdr.subj)-1, hdr.subj);
- printf("Attr: %04hX\n", hdr.attr);
+ printf("Attr: 0x%04hX ("PRINTF_BINARY_PATTERN_INT16")\n", hdr.attr,PRINTF_BYTE_TO_BINARY_INT16(hdr.attr));
printf("To : %.*s (%u.%u/%u.%u)\n", sizeof(hdr.to)-1, hdr.to ,hdr.destzone, hdr.destnet, hdr.destnode, hdr.destpoint);
printf("From: %.*s (%u.%u/%u.%u)\n", sizeof(hdr.from)-1, hdr.from ----->8 snip 8<-----

i hope that's usable... i know it handles larger bitfields than are needed here but it works, was a relatively easy find and may be useful in other places with larger bitfields...

i found it at this link https://stackoverflow.com/questions/111928/is-there-a-printf-converter-to-print -in-binary-format
it is the post by Et7f3XIV toward the bottom of the page... it was one that i was kinda able to figure out faster than others and it was an easy one to throw into the msgdump.c code ;)

---
* Synchronet * SouthEast Star Mail HUB - SESTAR
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs and ftn netmail routing
By: waldo kitty to Digital Man on Sun Oct 07 2018 08:23 am

Re: sbbs and ftn netmail routing
By: Digital Man to mark lewis on Sat Oct 06 2018 15:51:43

I have little program called msgdump (probably going to rename to fmsgdump). Run 'make msgdump' in src/sbbs3.

that works...

i've forgotten a lot of C that i used to know... i did find and shove the following code in so that i could read the attributes easier... the code results in output like this... note the "Attr:" line...

Opening 1.msg
Subj: Re: Usenet feeds?
Attr: 0x0009 (00000000 00001001)
To : Rob Swindell (1.218/700.0)
From: Paul Hayton (3.770/100.0)
Time: 20 Sep 18 16:32:48

so now i know that that MSG has, reading from right to left, attributes FIDO_PRIVATE and FIDO_SENT...

Interesting.

i'm hoping that in this case FIDO_SENT means
that the message was sent on by sbbsecho to the next link (1:261/38) in the route from here to the destination... i chose this message because your system is the destination... i thought that you might confirm if it did arrive or not... it has MSGID: 3:770/100 7db1eea0...

That's my name but not my address (that is my uplink's address). My address is 1:103/705. I have not received the message.

and here's the patch... unfortunately, some lines (7) are wrapped...

Wouldn't it be more useful the names of set attributes were printed?

digital man

Synchronet "Real Fact" #17:
"Vertrauen" (ver-trow-en) translates to "trust" in German, and was a band name. Norco, CA WX: 75.3oF, 52.0% humidity, 14 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: sbbs and ftn netmail routing
By: waldo kitty to Digital Man on Sun Oct 07 2018 08:23 am

i hope that's usable... i know it handles larger bitfields than are needed here but it works, was a relatively easy find and may be useful in other places with larger bitfields...

I didn't use it, but I committed something similar (better?) to fmsgdump.c. Also added a '-c' option to only display control/kludge lines (and not other body text).

digital man

This Is Spinal Tap quote #15:
Review on "Shark Sandwich", merely a two word review: "Shit Sandwich".
Norco, CA WX: 75.0oF, 56.0% humidity, 12 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Oct 07 14:03:38, you wrote to waldo kitty:

so now i know that that MSG has, reading from right to left, attributes
FIDO_PRIVATE and FIDO_SENT...

Interesting.

it is one of the things that my previous setup was able to show me... since i am a star hub, i get quite a bit of routed netmail traveling through and need to make sure it heads on out from here in the proper direction...

i'm hoping that in this case FIDO_SENT means that the message was sent
on by sbbsecho to the next link (1:261/38) in the route from here to
the destination... i chose this message because your system is the
destination... i thought that you might confirm if it did arrive or
not... it has MSGID: 3:770/100 7db1eea0...

That's my name but not my address (that is my uplink's address). My address is 1:103/705. I have not received the message.

ok... hummm... is it possible that you logged into your uplink's system and wrote an echomail or netmail message from there that the sender is netmailing a
response to?

and here's the patch... unfortunately, some lines (7) are wrapped...

Wouldn't it be more useful the names of set attributes were printed?

absolutely! but that was all i was able to do at the time... i saw where you've
renamed the tool and added some enhancements to it... i'll have to update again
and see what fun we can have with the newer stuff :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Love is the triumph of imagination over intelligence.
---
* Origin: (1:3634/12.73)

On 2018 Oct 07 14:55:06, you wrote to waldo kitty:

i hope that's usable... i know it handles larger bitfields than are
needed here but it works, was a relatively easy find and may be useful
in other places with larger bitfields...

I didn't use it, but I committed something similar (better?) to fmsgdump.c. Also added a '-c' option to only display control/kludge
lines (and not other body text).

cool! i'm sure what you did was much better than what i was able to fling together :lol:

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... At least this isn't a bloody French tagline.
---
* Origin: (1:3634/12.73)

Re: sbbs and ftn netmail routing
By: mark lewis to Digital Man on Sun Oct 07 2018 07:17 pm

On 2018 Oct 07 14:03:38, you wrote to waldo kitty:

so now i know that that MSG has, reading from right to left, attributes
FIDO_PRIVATE and FIDO_SENT...

Interesting.

it is one of the things that my previous setup was able to show me... since i am a star hub, i get quite a bit of routed netmail traveling through and need to make sure it heads on out from here in the proper direction...

i'm hoping that in this case FIDO_SENT means that the message was sent
on by sbbsecho to the next link (1:261/38) in the route from here to
the destination... i chose this message because your system is the
destination... i thought that you might confirm if it did arrive or
not... it has MSGID: 3:770/100 7db1eea0...

That's my name but not my address (that is my uplink's address). My address is 1:103/705. I have not received the message.

ok... hummm... is it possible that you logged into your uplink's system and wrote an echomail or netmail message from there that the sender is netmailing a
response to?

Nope. I sent Avon (Paul) a netmail from my 1:103/705 address (on my BBS) weeks ago. I assume that's his reply, stuck.

and here's the patch... unfortunately, some lines (7) are wrapped...

Wouldn't it be more useful the names of set attributes were printed?

absolutely! but that was all i was able to do at the time... i saw where you've
renamed the tool and added some enhancements to it... i'll have to update again and see what fun we can have with the newer stuff :)

K, let me know how it goes.

digital man

This Is Spinal Tap quote #25:
Viv Savage: Have... a good... time... all the time. That's my philosophy. Norco, CA WX: 71.8oF, 64.0% humidity, 13 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Oct 07 17:05:54, you wrote to me:

ok... hummm... is it possible that you logged into your uplink's system
and wrote an echomail or netmail message from there that the sender is
netmailing a response to?

Nope. I sent Avon (Paul) a netmail from my 1:103/705 address (on my
BBS) weeks ago. I assume that's his reply, stuck.

yeah, looks like it might be... as far as "stuck" i think the SENT attribute is
saying that sbbsecho did route it on toward the destination via the specified link... i'll have to trawl back through the sbbsecho log and see if i can determine if that is what happened... in any case, it was sent to the wrong final destination address...

absolutely! but that was all i was able to do at the time... i saw
where you've renamed the tool and added some enhancements to it... i'll
have to update again and see what fun we can have with the newer stuff
:)

K, let me know how it goes.

i keep having to adjust my script but everything is working well... before my next update, i can remove the specific sections for fmsgdump and pktdump... i have specific sections for sexpots, syncview, uedit and umonitor... some of these tools get built during install but not during subsequent rebuilds (eg: adding USE_DOSEMU=1) so i've added specific sections to my rebuild script for them...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... GELATIN: A disgusting extraction made from boiled calves feet.
---
* Origin: (1:3634/12.73)