For anyone intersted, I just imported a few hundred more BBS retro BBS software
/ source packages on Xibalba.

Also added a few thousand mostly Amiga related scene releases, more retro mags,
etc.

Leech away!



--- ENiGMA 1/2 v0.0.8-alpha (linux; x64; 6.11.3)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

On 01/06/18, NuSkooler pondered and said...

For anyone intersted, I just imported a few hundred more BBS retro BBS software / source packages on Xibalba.

Also added a few thousand mostly Amiga related scene releases, more
retro mags, etc.

Cool thanks I will have a look in the coming days..

Sorry I have not checked packets yet, the day has ended and I am out of
time... so will check tomorrow.

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

On Sunday, January 7th Avon muttered...

Sorry I have not checked packets yet, the day has ended and I am out of time... so will check tomorrow.

No problem, I don't expect to be some sort of priority :D I appreciate you and g00r00 helping me with this stuff. I feel it must be close hehe..




--- ENiGMA 1/2 v0.0.8-alpha (linux; x64; 6.11.3)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

On 01/07/18, NuSkooler pondered and said...

On Sunday, January 7th Avon muttered...

Sorry I have not checked packets yet, the day has ended and I am out time... so will check tomorrow.

No problem, I don't expect to be some sort of priority :D I appreciate
you and g00r00 helping me with this stuff. I feel it must be close hehe..

Finally got some time.. here's what I see

[snip]

+ Jan 07 10:32:55 Importing 2fe840ff.pkt (21:1/121 to 21:1/100)
! Jan 07 10:32:55 AREAFIX received from unknown address 0:0/0

[snip]

A text dump from my packet viewing tools shows the following, the subject
line as been altered for obvious reasons :)

[snip]

------------------------------------------------------------------------------ Date: 06 Jan 18 14:26:57
From: NuSkooler, 1/121
To: AreaFix, 1/100
Subj: 1234567
Stat: Pvt Locl ------------------------------------------------------------------------------ @INTL 21:1/100 21:1/121
@MSGID: 69236.private_mail@21:1/121 4d90e4be
@TZUTC: -0700
@TID: ENiGMA1/2 0.0.8.a (linux; x64; 6.11.3)
@CHRS: UTF-8 4
%HELP
--- ENiGMA 1/2 v0.0.8-alpha (linux; x64; 6.11.3)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

[snip]

and earlier another packet

[snip]

+ Jan 06 19:31:27 Importing 060234ac.pkt (21:1/121 to 21:1/100)
! Jan 06 19:31:27 AREAFIX received from unknown address 0:0/0

[snip]

here's the text dump of that

[snip]

------------------------------------------------------------------------------ Date: 05 Jan 18 23:03:07
From: NuSkooler, 1/121
To: AreaFix, 1/100
Subj: 1234567
Stat: Pvt Locl ------------------------------------------------------------------------------ @INTL 21:1/100 21:1/121
@MSGID: 69144.private_mail@21:1/121 02022e60
@TZUTC: -0700
@TID: ENiGMA1/2 0.0.8.a (linux; x64; 6.11.3)
@CHRS: UTF-8 4
%HELP
--- ENiGMA 1/2 v0.0.8-alpha (linux; x64; 6.11.3)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

[snip]

Now's here's a dump of a Mystic generated packet I sent to you a few days ago.

[snip]

----------------------------------------

On 01/09/18, Avon said the following...

The things I notice are the @MSGID construction in Mystic is just senders address and unique generated id, but in your packets they seem much
longer with 69144.private_mail@ appended to the front of the senders FTN address. and 69236.private_mail@ appended to the start of the other. Perhaps this is an issue and if you strip yours back to look more like
the Mystic generated ones it may work?

Synchronet also uses a MSGID method like this, and netmail between Synchronet and Mystic seems to be fine, right?

Regards,
Nick

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

@MSGID: 69144.private_mail@21:1/121 02022e60

Perhaps this is an issue and if you strip yours back to look more like
the Mystic generated ones it may work?

Good eye! This is confirmed to be the cause. MSGID is basically telling Mystic its from no address, because the address format is incorrect. I think some in Fido land tried to warn about using that format a while back...

In this case, Enigma is saying that the address is "61231.private_mail" and the domain is "21:1/121". Obviously those are invalid, so it reports the invalid address 0:0/0. In echomail thats considered okay by Mystic, but in Netmail invalid addressing is an obvious deal-breaker... You get refused in the same way you'd get refused if you tried to put a "@" in the middle of an e-mail address (my@name@email.com isn't going anywhere and shouldn't be expected to)

When you convert this stuff to 5D you get a result that requires special coding specifically for this butchered format because its not compliant addressing:

2342.whatever@55:1/1.0@netone
5623.whatever@55:1/1.0@nettwo

Anyway, A39 will handle this better but if there are older 5D tossers that care about MSGID, they may not be able to handle that wonky 5D addressing without code change (many of which probably can't be changed at this point).

Who knows how many strict 5D tossers there are that even care about MSGID though, I imagine its only a few. Maybe Mystic is the only one.

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

Accession wrote to Avon on 01-08-18 16:44 <=-

On 01/09/18, Avon said the following...

The things I notice are the @MSGID construction in Mystic is just senders address and unique generated id, but in your packets they seem much
longer with 69144.private_mail@ appended to the front of the senders FTN address. and 69236.private_mail@ appended to the start of the other. Perhaps this is an issue and if you strip yours back to look more like
the Mystic generated ones it may work?

Synchronet also uses a MSGID method like this, and netmail between Synchronet and Mystic seems to be fine, right?

There was an issue between myself and Dan Richter with routed netmail. His system would address the reply to the node doing the routing rather than to the sending node. Dan was supposed to inquire about this but in all honesty, we never discussed it past that time.


--

Bill

Telnet: tequilamockingbirdonline.net
Web: bbs.tequilamockingbirdonline.net
FTP: ftp.tequilamockingbirdonline.net:2121
IRC: irc.tequilamockingbirdonline.net Ports: 6661-6670 SSL: +6697
Radio: radio.tequilamockingbirdonline.net:8010/live


... Look Twice... Save a Life!!! Motorcycles are Everywhere!!!
--- MultiMail/Win32 v0.50
* Origin: TequilaMockingbird Online - Badlands of NJ (21:2/141)

On 01/08/18, g00r00 pondered and said...

@MSGID: 69144.private_mail@21:1/121 02022e60

Perhaps this is an issue and if you strip yours back to look more lik the Mystic generated ones it may work?

Good eye! This is confirmed to be the cause. MSGID is basically telling Mystic its from no address, because the address format is incorrect. I

Good stuff thanks. I think it sounds like you will revise Mystic code to
accept this format and Nu may wish to revise how his end creates the MSGID
but that's his call to make. Either way it sounds like we're collectively making headway with this issue - thanks :)

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

On Monday, January 8th g00r00 muttered...

Good eye! This is confirmed to be the cause. MSGID is basically telling Mystic its from no address, because the address format is incorrect. I think some in Fido land tried to warn about using that format a while back...

Some of them did, but I ignored them :D To Accession's point, Sync does this and AFAIK there are no issues between Sync and Mystic for NetMail.

Curious as to why MSGID would matter for NetMail (but not EchoMail) or even matter when there is a e.g. INTL field?

Either way, the real question for me is why Sync works but Enig doesn't - as AFAIK we're using the same-ish format:
* Sync: <msgNum>.<subCode>@<ftnAddr> <serial>
* Enig: <msgNum>.<enigArea>@<ftnAddr> <serial>

Maybe that <enigArea> is not numeric?

I could change the format, but I've not seen it as cause issues with any systems EchoMail wise (and the Sync question thing). Enig uses this to map to local message ID's, which can be much larger than <serial> can hold. If <enigArea> as alpha is a problem, I could easily change that without breakage.

Thanks for the find Avon, the info g00r00, and the reminder that Sync uses this
format Assession!








--- ENiGMA 1/2 v0.0.8-alpha (linux; x64; 6.11.3)
* Origin: Xibalba -+- xibalba.l33t.codes:44510 (21:1/121)

On 01/08/18, NuSkooler pondered and said...

Thanks for the find Avon, the info g00r00, and the reminder that Sync
uses this format Assession!

Team effort :)

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

Some of them did, but I ignored them :D To Accession's point, Sync does this and AFAIK there are no issues between Sync and Mystic for NetMail.

There are at least two areas where I've had to code specifically for Synchronet, so there have been some issues.

Curious as to why MSGID would matter for NetMail (but not EchoMail) or even matter when there is a e.g. INTL field?

I think your question should be reversed: Why SHOULD Mystic accept private messages with invalid addressing in it? People WANT security in their echo/netmail. Netmail is a private message system, based on addressing... Echomail is not.

Do you think we should accept Internet email from bogus addresses or should those be refused? They should be refused/blocked. Why should that be different with Netmail?

There are cases where you mix Netmail and Echomail, such as forwarding Netmail to Echomail or replying to echomail via Netmail. MSGID is your link between them. Its not that MSGID is required (it's not), its that yours is seen as having an invalid address.

Either way, the real question for me is why Sync works but Enig doesn't
- as AFAIK we're using the same-ish format:
* Sync: <msgNum>.<subCode>@<ftnAddr> <serial>
* Enig: <msgNum>.<enigArea>@<ftnAddr> <serial>

I doubt it does work, are you operating on assumption or have you tested it? I've not tested it personally but I probably should.

1234.asdf@1:1/1.0@fidonet should be seen an invalid address format by anything not specifically coded to work with Synchronet-style addressing. It shouldn't matter where it comes from.

I could change the format, but I've not seen it as cause issues with any systems EchoMail wise (and the Sync question thing). Enig uses this to

Well you are literally seeing it causing issues right now with quite possibly the most used echomail suite in FTN, one which has no known issues with any other software besides those using this non-standard format. :)

Reply by Netmail is probably the most common thing it breaks in echomail based on my assumptions. That was also broken specifically with messages sourced from Synchronet, as someone reported here about a month ago. Fixed in A39.

Either way, the next version of Mystic should clean it up. I'll try to get a version to Paul soon-ish so we can test. If you are curious you could try to send a Netmail with no MSGID at all to see if that goes through.

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