On 10/25/17, bando said the following...

@TZUTC: 0000
@MSGID: 21:1/999 93485310
@REPLY: 21:1/101 50f81562
@TID: Mystic BBS 1.12 A35
@SEEN-BY: 1/100

And Hi for Northampton Northants in the UK

Geoff

=== Mystic BBS v1.12 A35 (Linux/64)
# Origin: BadTaste-BBS (21:1/999)
--- SBBSecho 3.01-Win32
* Origin: SpaceSST-BBS Fsxnet (21:1/129)

So this the first dupe nessage that arrived at 1/100 from 1/129 but interestingly it's presented to MUTIL as a packet from 1:249/206 and
contained 59 messages across several echos that were all dupes.

[snip]

+ Oct 26 23:31:30 Extracting 00f8006a.TH0
- Oct 26 23:31:30 unzip -oqqjC "c:\mystfsx\echomail\in\00f8006a.TH0"
"*.pkt" -d c:\mystfsx\temputil\
+ Oct 26 23:31:30 Importing 59f1b8e7.pkt (1:249/206 to 21:1/100)
+ Oct 26 23:31:30 Import #34282 to FSX_GEN
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/101@fsxnet
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/102@fsxnet
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/103@fsxnet
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/104@fsxnet

[snip]

+ Oct 26 23:31:34 Results: 59 echo, 0 net, 0 dupes, 5385 tossed in 4.17s
+ Oct 26 23:31:34 Shutdown Normal (0)

[snip]


So something is amiss om several levels.

1) 1/129 is burping a packet from 1:249/100 that is addressed to 21:1/100

2) 1/100 is accepting it and tossing it onwards

I suspect 2 may be due to the changes g00r00 has made to the A36 pre I amd testing... perhaps in freeing up the code to accept the Telegard packet that failed to toss from sPINOZa the other day it's opened the door too widely?

g00r00 I have a copy of the packet that did was tossed incorrectly if you
want it.

Pkt Ver 0002H
Header Type 2+
Product Ver v3.01
No password
Capability 0001H/0100H

I will also cross post this into FSX_MYS

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: fsxNet HUB (21:1/100)

On 10/27/17, Paul Hayton pondered and said...

On 10/25/17, bando said the following...

@TZUTC: 0000
@MSGID: 21:1/999 93485310
@REPLY: 21:1/101 50f81562
@TID: Mystic BBS 1.12 A35
@SEEN-BY: 1/100

And Hi for Northampton Northants in the UK

Geoff

=== Mystic BBS v1.12 A35 (Linux/64)
# Origin: BadTaste-BBS (21:1/999)
--- SBBSecho 3.01-Win32
* Origin: SpaceSST-BBS Fsxnet (21:1/129)

So this the first dupe nessage that arrived at 1/100 from 1/129 but interestingly it's presented to MUTIL as a packet from 1:249/206 and contained 59 messages across several echos that were all dupes.

[snip]

+ Oct 26 23:31:30 Extracting 00f8006a.TH0
- Oct 26 23:31:30 unzip -oqqjC "c:\mystfsx\echomail\in\00f8006a.TH0" "*.pkt" -d c:\mystfsx\temputil\
+ Oct 26 23:31:30 Importing 59f1b8e7.pkt (1:249/206 to 21:1/100)
+ Oct 26 23:31:30 Import #34282 to FSX_GEN
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/101@fsxnet
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/102@fsxnet
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/103@fsxnet
+ Oct 26 23:31:30 Export FSX_GEN #34282 to 21:1/104@fsxnet

[snip]

+ Oct 26 23:31:34 Results: 59 echo, 0 net, 0 dupes, 5385 tossed in 4.17s + Oct 26 23:31:34 Shutdown Normal (0)

[snip]

So something is amiss om several levels.

1) 1/129 is burping a packet from 1:249/100 that is addressed to 21:1/100

2) 1/100 is accepting it and tossing it onwards

I suspect 2 may be due to the changes g00r00 has made to the A36 pre I
amd testing... perhaps in freeing up the code to accept the Telegard packet that failed to toss from sPINOZa the other day it's opened the
door too widely?

g00r00 I have a copy of the packet that did was tossed incorrectly if you want it.

Pkt Ver 0002H
Header Type 2+
Product Ver v3.01
No password
Capability 0001H/0100H

I will also cross post this into FSX_MYS

Best, Paul

Excuse the excess quoting but it copies you into the whole thread I posted.

I got curious so I restored the 1/100 HUB back to A35 and re-ran the MUTIL import again using the suspicious packet.

[snip]

----------------- MUTIL v1.12 A35 Fri, Oct 27 2017 (loglevel 3)
+ Oct 27 21:12:48 Startup using mailin.ini

+ Oct 27 21:12:48 Importing 59f1b8e7.pkt (1:249/206 to 21:1/100)
+ Oct 27 21:12:48 Import #34272 to FSX_GEN
+ Oct 27 21:12:48 Export FSX_GEN #34272 to 21:1/101@fsxnet
+ Oct 27 21:12:48 Export FSX_GEN #34272 to 21:1/102@fsxnet
+ Oct 27 21:12:48 Export FSX_GEN #34272 to 21:1/103@fsxnet
+ Oct 27 21:12:48 Export FSX_GEN #34272 to 21:1/104@fsxnet

+ Oct 27 21:12:53 Results: 59 echo, 0 net, 0 dupes, 5385 tossed in 5.09s
+ Oct 27 21:12:53 Shutdown Normal (0)

[snip]

So from this I learned

1) any changes to the pre-build of A36 are not directly involved in this issue

2) MUTIL seems to accept and toss packets from unknown echonodes from any ZONE:NET/NODE combo so long as they make it in to a secure directory (BinkP session with 1/129 allowed that) and are addressed to the 21:1/100 AKA (which these wonky ones from 1:249/206 were).

In the case of the .ini file associated with this import I did have

; Toss packets from unsecure directory in addition to inbound?

unsecure_dir = true

But that's a red herring I think, in that this was a packet that made it to
the secure directory so became trusted. Right?

Do you think there should be some safe guards that can be set to stop MUTIL from tossing echomail packets from echonodes not known to Mystic that land in the secure directory by whatever means?

Just a thought :)

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

g00r00 I have a copy of the packet that did was tossed incorrectly if you want it.

Sure please send it over and I'll take a look.

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/27/17, g00r00 pondered and said...

g00r00 I have a copy of the packet that did was tossed incorrectly if want it.

Sure please send it over and I'll take a look.

It's on it's way.

Packet 59f1b8e7

I have saved it with a .TXT extension to avoid it being tossed when it lands
at your end, just rename it.

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Packet 59f1b8e7

I have saved it with a .TXT extension to avoid it being tossed when it lands at your end, just rename it.

Thanks I have it now!

I'm not so sure how to handle this... Mystic enforces the "to address" being valid, but it doesn't enforce the from address because unsecure Netmail will break. There may be other situations as well where you may wish to accept a PKT from a node not in your echomail nodes too.

If you have any opinions please feel free to let me know!

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/27/17, g00r00 pondered and said...

I'm not so sure how to handle this... Mystic enforces the "to address" being valid, but it doesn't enforce the from address because unsecure Netmail will break. There may be other situations as well where you may wish to accept a PKT from a node not in your echomail nodes too.
If you have any opinions please feel free to let me know!

First question that springs to mind is, is there any technical
differentiation between echomail and netmail packets? If yes then it may be easier to allow unsecured netmail while enabling an option to allow/deny unsecure echomail.

Consider this option I've pinched from FastEcho

[snip]

FastEcho, independently from your mailer, has its own security sys-tem, based substantially upon two parameters: the addresses of the connected systems and the password that an ARCmail bundle may have (You ought know that the session password has really nothing to do with the ARCmail-level password: the first is the password that you may agree with a remote system to allow your mailer be really sure of recognizing it for what it appears to be, letting it go farther with mail exchange; the second, object of our discussion, is the password embedded in your ARCmail bundle ready to be processed). This switch could have three possible values: "None", "Normal" and "Full". When it's toggled to "None" all the security features will be disabled, so, all incoming mail packets will always be processed and tossed without any inspec-tion, when it's switched to "Normal then FastEcho will check the address proveneance of this (or these) mail packet(s). If their original address matches an address you defined in the "Node Manager" (We shall see later in "Node Manager" section) then the mail packets will be processed, otherwise they will be discarded and left in Inbound directory with the .SEC extension. The "Full" security option checks both the packet's address origin and the aforesasid "Packet-password" (you can de-fine this password in the "Passwords (ARCmail) 5.4.1.5.1" if necessary; we'll see later) in case one
of both fails the inspection, then the entire mail packet will be renamed to *.SEC and left in inbound directory.

[snip]

I'm not sure about the need for a 'Full' option in this day and age but I
like the idea of being able to set MUTIL to either toss echomail according to if the incoming address is a known echonode to Mystic or to rename the packet .SEC and place it in a defined directory for further inspection by the sysop.

I guess if that option were made available and the sysop subsequently wanted
to process the marked packet(s) there would still need to be a way to allow that. Either by override switch e.g. ignore the stated .ini setting or
another means.

I do struggle with the idea that echomail from an unknown system and a completely out of zone:net/node address to those stated in Mystic's echomail addresses can be accepted and tossed without challenge.

My 2 cents :)

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

First question that springs to mind is, is there any technical differentiation between echomail and netmail packets? If yes then it may be easier to allow unsecured netmail while enabling an option to allow/deny unsecure echomail.

No, not at the PKT level. A PKT can (and does) contain a mix of echomail and netmail.

I do struggle with the idea that echomail from an unknown system and a completely out of zone:net/node address to those stated in Mystic's echomail addresses can be accepted and tossed without challenge.

I think maybe the PKT security needs to stay the way it is now, where the security is based around PKT passwords and authentication by the mailer.

I could add an option like what BBBS has where it will look at the "To" address in each individual message and refuse to toss it if its not a valid echomail node. This doesn't really comply with the FTSC definition of what can be contained in that field though, but if its an option like BBBS has then I suppose it could be the proper solution.

The downside to this is that it will increase tossing time a bit and possibly increase memory usage a bit...

But if I did the FastEcho method, it'd refuse packets from unsecure netmail that you might want. You're sort of stuck with "all or nothing" with
FastEcho.

The BBBS method would allow us to apply that address check only to each individual echomail message, so anything that actually IS valid within the PKT will still get properly processed, including crashed netmail.

I think I like the way BBBS does it better than FastEcho.

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/27/17, g00r00 pondered and said...

I think maybe the PKT security needs to stay the way it is now, where the security is based around PKT passwords and authentication by the mailer.

OK

I could add an option like what BBBS has where it will look at the "To" address in each individual message and refuse to toss it if its not a valid echomail node. This doesn't really comply with the FTSC
definition of what can be contained in that field though, but if its an option like BBBS has then I suppose it could be the proper solution.

Just trying to process this... so if in the case of the example packet we're looking at that started this thread the 'to' is 21:1/100 and that's the AKA
the 1/100 HUB flies.. then it would toss?

The downside to this is that it will increase tossing time a bit and possibly increase memory usage a bit...

In the great scheme of things I'd say the overhead impact would be nominal.

But if I did the FastEcho method, it'd refuse packets from unsecure netmail that you might want. You're sort of stuck with "all or nothing" with FastEcho.

We definitely want unsecured netmail to always make it in to Mystic I think.

The BBBS method would allow us to apply that address check only to each individual echomail message, so anything that actually IS valid within
the PKT will still get properly processed, including crashed netmail.

I don't fully understand the BBBS system as yet but if your gut says it's the way to go, then I'd trust it :) After all it can always be revised at a later time if things seemingly go awry despite best efforts.

I think I like the way BBBS does it better than FastEcho.

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Just trying to process this... so if in the case of the example packet we're looking at that started this thread the 'to' is 21:1/100 and
that's the AKA the 1/100 HUB flies.. then it would toss?

As it stands now, the PKT itself has a from and to address. Mystic only checks that the "To" address is a valid AKA of your system. There is also a PKT password and of course the authentication surrounding your mailer for security.

Then there is a from and to address in each message. I was trying to say that I could check the From address to make sure it is a valid configured echomail node address when tossing echomail. This is what BBBS does but the FTSC document states that the From address in messages doesn't not HAVE to be the immediate address that sent the PKT, so it will be an optional feature for this reason. I have not seen any tossers though that do not put the "senders" address in the message though, so it should work.

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/28/17, g00r00 pondered and said...

Then there is a from and to address in each message. I was trying to
say that I could check the From address to make sure it is a valid configured echomail node address when tossing echomail. This is what
BBBS does but the FTSC document states that the From address in messages doesn't not HAVE to be the immediate address that sent the PKT, so it
will be an optional feature for this reason. I have not seen any
tossers though that do not put the "senders" address in the message though, so it should work.

Gotcha... thanks, this makes more sense to me and is a clear explanation of your thinking. I like the idea.

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Hello all. Quick question. Do I have to add a Dupes message area for all
the dupes to go in? If so, how do I do that for all my networked message areas? Thanks.

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/64)
* Origin: Necronomicon BBS - necrobbs.strangled.net (21:1/122)

I did, in fact I used Paul's (Avon) video to set it up.. Nothing is ever in
it, but it's there...

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: The Wrong Number Family Of BBS' - Wrong Number ][ (21:4/131)

On 09/18/18, Necromaster said the following...

Hello all. Quick question. Do I have to add a Dupes message area for
all the dupes to go in? If so, how do I do that for all my networked message areas? Thanks.

No, you don't need to create a dupemail area. Only if you'd like to
see/view/or read them. (I rarely ever have any dupes) All your networks dupes will be added to the dupemail index# only if you create it. mutil.ini states..

[ImportEchoMail]

; If you want to save duplicated / bad messages to a certain message
; base, then set this value to the *INDEX* of the message base (viewable
; at the top of the msgbase editor). Otherwise, set this value to -1
; or leave it commented out and they will be ignored. Meaning...

dupe_msg_index = -1 (will be ignored) same as..
;dupe_msg_index = (commented out)

dupe_msg_index = 5 (index #5 here) it pretty much stays empty.

Üܲ±ßÞÜÝ ÞÜÜ Ü²Þ²ÜÜ ÜÝ °Ü Ý ! b7 member board
Þ²ÜÜÜ Þ² ÜÞ²Ý Þ²ÝÞÝ޲ݰÜÜ²Ý ÜÜ dA flupHly squirrel ate my nuts!
Þ²Ý ß߲ܲÝßÛܲÝÞ²Ýßß Þ²ÝÞ²Ý²Ý @ http://fluph.bbsnexus.com

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: flupH | fluph.araknet.xyz (21:1/105)

On 09/18/18, Necromaster said the following...

Hello all. Quick question. Do I have to add a Dupes message area for
all the dupes to go in? If so, how do I do that for all my networked message areas? Thanks.

you make a bad message base

|08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
|08 øù|05ú|13ùø |13øù|05ú|08ùø
|11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/64)
* Origin: |08--[|15!|07dreamland BBS bbs.dreamlandbbs.org (21:1/163)

* An ongoing debate between Necromaster and All rages on ...

Hello all. Quick question. Do I have to add a Dupes message area for
all the dupes to go in? If so, how do I do that for all my networked message areas? Thanks.

Just add a new area, but make sure the Type is local (not echomail). I called mine badmail (file name badmail) and I zip them up daily for prosperity {chuckle} Just set mine up & it works great!


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet|ssh://cmech.dynip.com |
| |
| vvvvvv Email: fido4cmech(at)lusfiber.net |
| { O O } Home page: http://cmech.dynip.com/homepage/ |
| __m___oo___m__ |
`--| | | |- WildCat! BBS 24/7 +1-337-984-4794 any BAUD 8,N,1 -'

... All documents with puns will be drawn and quoted.
--- GoldED+/W32-MSVC v1.1.5-g20180902 + Mystic BBS v1.12 A39
* Origin: FSXNet - Positronium: telnet://cmech.dynip.com (21:2/117)

Something is amiss

I created a new system NET 5 and sent an areafix from it to NET 1 for a full rescan of all echos.

When they landed at NET 5 MUTIL tossed them in but also exported them
straight back to NET 1 - not good.

Here's a small snip of the NET 5 logs

! Dec 27 15:01:36 Area FSX_MYS does not exist
+ Dec 27 15:01:36 Created area FSX_MYS
+ Dec 27 15:01:36 Import #1 to FSX_MYS
+ Dec 27 15:01:36 Import #2 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #2 to 21:1/100@fsxnet
+ Dec 27 15:01:36 Import #3 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #3 to 21:1/100@fsxnet
+ Dec 27 15:01:36 Import #4 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #4 to 21:1/100@fsxnet
+ Dec 27 15:01:36 Import #5 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #5 to 21:1/100@fsxnet
+ Dec 27 15:01:36 Import #6 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #6 to 21:1/100@fsxnet
+ Dec 27 15:01:36 Import #7 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #7 to 21:1/100@fsxnet
+ Dec 27 15:01:36 Import #8 to FSX_MYS
+ Dec 27 15:01:36 Export FSX_MYS #8 to 21:1/100@fsxnet

[snip]

+ Dec 27 15:03:18 Results: 94051 echo, 1 net, 38 dupes, 91033 tossed in 122.99s
+ Dec 27 15:03:18 Shutdown Normal (0)

--- Mystic BBS v1.12 A40 2018/12/25 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I created a new system NET 5 and sent an areafix from it to NET 1 for a full rescan of all echos.

When they landed at NET 5 MUTIL tossed them in but also exported them straight back to NET 1 - not good.

Isn't that the default behavior to any node listed in the "Export To" section of the echo config? As NET5 will see them all as new echomail and forward
them on?

Shouldn't you have removed all "Export To" addresses from NET5, done your rescan, then set up the "Export To" addresses?

--- Mystic BBS v1.12 A40 2018/12/25 (Raspberry Pi/32)
* Origin: Fusion BBS ~ Newcastle, Australia (21:4/132)

On 12/27/18, Michael Borthwick pondered and said...

Isn't that the default behavior to any node listed in the "Export To" section of the echo config? As NET5 will see them all as new echomail
and forward them on?

Shouldn't you have removed all "Export To" addresses from NET5, done your rescan, then set up the "Export To" addresses?

In NET 5 I had 21:1/100 echonode defined but not linked to any of the fsx bases, there were none created

When I sent and got the rescanned packets from 1/100 sent to 5/100 Mystic
auto created the bases using the default settings I had created.

In creating those bases it links the echonode that sent the messages as an export. But it should not be exporting the very same messages it just
ingested from the sending system right back to it.

--- Mystic BBS v1.12 A40 2018/12/25 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)