• i've been duped ... or was i?

    From Maurice Kinal@1:153/7001 to All Fourone on Thursday, December 03, 2020 00:03:25
    Hey All!

    I am going to "crosspost" this msg in LINUX. I haven't seen any real traffic there in awhile so I don't believe it will have an negative effects. Besides it probably won't get past my uplink if indeed MSGIDs are universal and not just limited to the AREA as far as dupe checking goes.

    What are the odds?

    Life is good,
    Maurice

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Alan Ianson@1:153/757 to Maurice Kinal on Wednesday, December 02, 2020 17:09:08
    Hello Maurice,

    I am going to "crosspost" this msg in LINUX. I haven't seen any real traffic there in awhile so I don't believe it will have an negative effects. Besides it probably won't get past my uplink if indeed
    MSGIDs are universal and not just limited to the AREA as far as dupe checking goes.

    What are the odds?

    About 50/50 I'd say.

    I just see one copy of this message in here. If any dupes did arrive they would be discarded as long as my tosser sees it as a dupe.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Maurice Kinal@1:153/7001 to Alan Ianson on Thursday, December 03, 2020 01:37:01
    Hey Alan!

    What are the odds?

    About 50/50 I'd say.

    Not from this angle. The dupe that isn't really a dupe is the one you replied to in this AREA:LINUX.

    I just see one copy of this message in here.

    The original is in ASIAN_LINK. Check in there and then reply.

    If any dupes did arrive they would be discarded as long as my
    tosser sees it as a dupe.

    Check ASIAN_LINK. I see both the original in ASIAN_LINK and the so-called dupe in LINUX and they are EXACTLY the same other than AREA. Also confirm that the MSGID is EXACTLY the same in both. They both show up on the EuroPoint which means that they both got tossed by my uplink there -> 2:280/464. Since 2:280/464 tossed them both then they both got tossed by you since your node is the first tosser both those msgs saw. Also they were both packed here -> 1:153/7001, in the same pkt so it isn't like there were multiple files to deal with. In other words dupe checking looks to be limited to AREA. No? Without knowing for sure I am guessing that is supposed to happen. If not then there is another bug.

    Life is good,
    Maurice

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Alan Ianson@1:153/757 to Maurice Kinal on Wednesday, December 02, 2020 18:11:54
    Hello Maurice,

    Check ASIAN_LINK. I see both the original in ASIAN_LINK and the
    so-called dupe in LINUX and they are EXACTLY the same other than AREA. Also confirm that the MSGID is EXACTLY the same in both.

    Yes, I see that message in ASIAN_LINK also and it looks the same. The same date, time, content and MSGID.

    They both show up on the EuroPoint which means that they both got
    tossed by my uplink there -> 2:280/464. Since 2:280/464 tossed them
    both then they both got tossed by you since your node is the first
    tosser both those msgs saw. Also they were both packed here -> 1:153/7001, in the same pkt so it isn't like there were multiple files
    to deal with. In other words dupe checking looks to be limited to
    AREA. No?

    That's what it seems at least here and 280/464.

    Without knowing for sure I am guessing that is supposed to happen. If
    not then there is another bug.

    I would use a unique MSGID even when cross posting. They seem to get tossed OK here and 280/464 but you never know what could happen along the way. There might be a tosser in the wild that will see an identical message with an identical MSGID that will toss it aside.

    Ttyl :-),
    Al

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Maurice Kinal@1:153/7001 to Alan Ianson on Thursday, December 03, 2020 03:18:52
    Hey Alan!

    but you never know what could happen along the way

    The story of my life.

    Life is good,
    Maurice

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Kai Richter@2:240/77 to Maurice Kinal on Thursday, December 03, 2020 11:19:12
    Hello Maurice!

    03 Dec 20, Maurice Kinal wrote to All Fourone:

    I am going to "crosspost" this msg in LINUX.

    Besides it probably won't get past my uplink if indeed MSGIDs are universal and not just limited to the AREA as far as dupe checking
    goes.

    FTN dupe handling is based on "per area". There is no universial dupecheck.

    For example every squish messagebase *.sqd file has it's own *.dqd dupedatabase file.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Maurice Kinal on Thursday, December 03, 2020 11:43:38
    * Originally in LINUX
    * Crossposted in FORTESTINGONLY

    Hello Maurice!

    03 Dec 20, Maurice Kinal wrote to Alan Ianson:

    In other words dupe checking looks to be limited to AREA. No?
    Without knowing for sure I am guessing that is supposed to happen.

    Yes. You are talking about two different mechansims. Crossposts and dupechecks.

    Crossposting is an editor function. The "Crossposted in" line above is set by my editor but there is no kludge for the tosser that this mail is crossposted.

    The dupecheck is for breaking routing loops and to keep away dupes from the echoarea users. It isn't designed for universal traffic reduction.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Maurice Kinal@1:153/7001 to Kai Richter on Thursday, December 03, 2020 14:03:13
    Hey Kai!

    FTN dupe handling is based on "per area". There is no universial dupecheck.

    So far I agree with the above 100% given that both my uplinks tossed both msgs without any issues. I see them on the EuroPoint as unaltered, not counting PATH and SEEN_BY of course, from what I know to be a fact is the original msg given that I created it. They are all identical other than the AREA.

    For example every squish messagebase *.sqd file has it's own
    *.dqd dupedatabase file.

    I've used squish for ages but it is overkill from a single user perspective.

    Life is good,
    Maurice

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Wilfred van Velzen@2:280/464 to Maurice Kinal on Thursday, December 03, 2020 15:31:16
    Hi Maurice,

    On 2020-12-03 14:03:13, you wrote to Kai Richter:

    FTN dupe handling is based on "per area". There is no universial
    dupecheck.

    So far I agree with the above 100% given that both my uplinks tossed both msgs without any issues.

    It doesn't matter that you agree with it. ;-)

    It's not the standard, so it might cause problems on other systems with different tossers...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Kees van Eeten@2:280/5003.4 to Maurice Kinal on Thursday, December 03, 2020 16:06:28
    Hello Maurice!

    03 Dec 20 14:03, you wrote to Kai Richter:

    Hey Kai!

    FTN dupe handling is based on "per area". There is no universial
    dupecheck.

    So far I agree with the above 100% given that both my uplinks tossed
    both msgs without any issues. I see them on the EuroPoint as
    unaltered, not counting PATH and SEEN_BY of course, from what I know
    to be a fact is the original msg given that I created it. They are
    all identical other than the AREA.

    If the dupecheck was universal, crossposting would have to generate
    different message id's.

    Kees

    --- GoldED+/LNX 1.1.5--b20180707
    * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
  • From Kai Richter@2:240/77 to Maurice Kinal on Thursday, December 03, 2020 17:36:32
    Hello Maurice!

    03 Dec 20, Maurice Kinal wrote to Kai Richter:

    FTN dupe handling is based on "per area". There is no universial
    dupecheck.

    So far I agree with the above 100% given that both my uplinks tossed
    both msgs without any issues. I see them on the EuroPoint as
    unaltered, not counting PATH and SEEN_BY of course, from what I know
    to be a fact is the original msg given that I created it. They are
    all identical other than the AREA.

    For example every squish messagebase *.sqd file has it's own
    *.dqd dupedatabase file.

    I've used squish for ages but it is overkill from a single user perspective.

    I wasn't talking about the software squish. Any squish messagebase compatible tosser should be able to use the *.sq? and *.dqd files.

    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)

    Maybe i didn't noticed the background of your question. If that is the editor that creates the complete message and you are looking for confirmation that it does everything correct, then i could tell that golded does not create the same MSGIDs for the crossposted message:

    5fc90f4d
    5fc90f4c

    The crossposting does have +1. Which is the "failsafe" behavior for msgid-based dupecheck procedures.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Maurice Kinal@1:153/7001 to Kees Van Eeten on Thursday, December 03, 2020 21:41:00
    Hey Kees!

    If the dupecheck was universal, crossposting would have to
    generate different message id's.

    "If" being the operative word. So far that doesn't appear to be the case. Then again how would anyone know for sure unless someone catches and reports it.

    Life is good,
    Maurice

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Maurice Kinal@1:153/7001 to Kai Richter on Thursday, December 03, 2020 21:49:32
    Hey Kai!

    Maybe i didn't noticed the background of your question.

    It was not a question on my part so you didn't really miss anything. However your answer has been most informative. Thank you.

    For my part I am attempting to make 1:153/7001 a potential wireless access point for offline readers and am going to keep everything to a bare minimum. So far it looks like only the MSGID is required to successfully transverse the whole of fidonet. Thus a point-like setup between 1:153/7001 and any user on the wireless should have the user's app generate it's own MSGID that will ensure uniqueness no matter if another user on the wireless generates the EXACT same serialno since the origaddr will ensure uniqueness due to the point part of the origaddr. This isn't that far off from a numbered userbase on a BBS where by default the sysop is listed as number 1. Thus whether universal or AREA based any half-assed dupechecker should have no issues with the output.

    For the record I am using the "^AMSGID: origaddr serialno" format as specified in fts-0009.001.

    Life is good,
    Maurice

    ... Monig mon hæfð micel feax on foran heafde, 7 wyrð færlice calu.
    Many a man has plenty of hair on his head, and suddenly goes bald.
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Kai Richter@2:240/77 to Maurice Kinal on Friday, December 04, 2020 05:38:14
    Hello Maurice!

    03 Dec 20, Maurice Kinal wrote to Kai Richter:

    For my part I am attempting to make 1:153/7001 a potential wireless
    access point for offline readers and am going to keep everything to a
    bare minimum.

    Offline Readers is a another chapter and i do not know much about that.

    So far it looks like only the MSGID is required to successfully
    transverse the whole of fidonet. Thus a point-like setup between 1:153/7001 and any user on the wireless should have the user's app generate it's own MSGID that will ensure uniqueness no matter if
    another user on the wireless generates the EXACT same serialno since
    the origaddr will ensure uniqueness due to the point part of the
    origaddr.

    As far as i remember offline readers like QWK are an interface to a BBS and act like online BBS users. And like online BBS users they are operating with the main aka of the BBS.

    This isn't that far off from a numbered userbase on a BBS where by
    default the sysop is listed as number 1.

    I can't remember how QWK uses the usernumber index. Maybe that was part of the BBS responsibilties.

    Thus whether universal or AREA based any half-assed dupechecker
    should have no issues with the output.

    For the record I am using the "^AMSGID: origaddr serialno" format as specified in fts-0009.001.

    If you're going to use point numbers then you do not have an offline reader - it's a point software. "Offline reader" could be used even for fully featured node systems too, just because fidonet is an offline network. It's basics are store and forward if connected and disconnect after packages sent.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Rob Swindell@1:103/705 to Kai Richter on Thursday, December 03, 2020 22:09:17
    Re: i've been duped ... or was i?
    By: Kai Richter to Maurice Kinal on Fri Dec 04 2020 05:38 am

    This isn't that far off from a numbered userbase on a BBS where by default the sysop is listed as number 1.

    I can't remember how QWK uses the usernumber index.

    It doesn't. :-)

    Maybe that was part of the BBS responsibilties.

    Yup. Just confirming for ya,
    --
    digital man

    Synchronet/BBS Terminology Definition #63:
    SAUCE = Standard Architecture for Universal Comment Extensions (ACiD)
    Norco, CA WX: 58.0øF, 13.0% humidity, 0 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tony Langdon@3:633/410 to Kai Richter on Friday, December 04, 2020 18:53:00
    On 12-04-20 05:38, Kai Richter wrote to Maurice Kinal <=-

    As far as i remember offline readers like QWK are an interface to a BBS and act like online BBS users. And like online BBS users they are operating with the main aka of the BBS.

    Yeah, offline mail is accessed through an ordinary user account, not a point system, so messages posted by offline users (like this message) appear the same as locally online posted messages, for all intents and purposes. :)

    This isn't that far off from a numbered userbase on a BBS where by
    default the sysop is listed as number 1.

    I can't remember how QWK uses the usernumber index. Maybe that was part
    of the BBS responsibilties.

    You talking about QWK mail posted by a user? That's posted from within the user's account, so it's the BBS's responsibility. QWK networked messages, OTOH, arrive from multiple users, but they're not offline mail (even though they use the same format), they are network messages, more like FTN, except there's no FTN address, kludges, routing information, etc. There is some QWK networking information though, especially on Synchronet based networks, thanks to DM's QWK estensions.

    If you're going to use point numbers then you do not have an offline reader - it's a point software. "Offline reader" could be used even for fully featured node systems too, just because fidonet is an offline network. It's basics are store and forward if connected and disconnect after packages sent.

    Network wise, a point system is more like a fully fledged FTN node (with some differences in handling SEENBYs, because those are only 2D).


    ... And on the 8th day God said, "Murphy, you're in charge."
    === MultiMail/Win v0.51
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Maurice Kinal@1:153/7001.4013 to Kai Richter on Friday, December 04, 2020 00:35:38
    Hey Kai!

    If you're going to use point numbers then you do not have an
    offline reader - it's a point software.

    I'll go along with that ... for now.

    Life is good,
    Maurice

    ... Sceal þegna gehwilc geþylde nimon.
    Every man must acquire patience.
    --- GNU bash, version 5.0.18(1)-release (aarch64-unknown-linux-android)
    * Origin: Little Mikey's ARM - Ladysmith BC, Canada (1:153/7001.4013)
  • From Benny Pedersen@2:230/0 to Maurice Kinal on Monday, December 07, 2020 01:53:34
    Hello Maurice!

    03 Dec 2020 03:18, Maurice Kinal wrote to Alan Ianson:

    but you never know what could happen along the way
    The story of my life.

    what life ?

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^

    nice cow :)


    Regards Benny

    ... too late to die young :)

    --- Msged/LNX 6.1.2 (Linux/5.9.12-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Benny Pedersen@2:230/0 to Kai Richter on Monday, December 07, 2020 01:54:46
    Hello Kai!

    03 Dec 2020 11:19, Kai Richter wrote to Maurice Kinal:

    For example every squish messagebase *.sqd file has it's own *.dqd dupedatabase file.

    in husky it can be global dupedatabase for all areas, but i only use it non global pr area as default


    Regards Benny

    ... too late to die young :)

    --- Msged/LNX 6.1.2 (Linux/5.9.12-gentoo-x86_64 (x86_64))
    * Origin: I will always keep a PC running CPM 3.0 (2:230/0)
  • From Maurice Kinal@1:153/7001 to Benny Pedersen on Monday, December 07, 2020 03:18:15
    Hey Benny!

    what life ?

    It ain't much but I call it home.

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^

    nice cow :)

    You know darn well that it's an ascii depiction of the mythical Magnulv the Møøse just before he ascended into Valhalla to take his rightful place on the shores of Gwillim Lake.

    Life is good,
    Maurice

    ... Gold geriseþ on guman sweorde... sinc on cwene.
    Gold is fitting for a man's sword, precious things for a woman.
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
  • From Robert Wolfe@1:116/18 to Maurice Kinal on Monday, January 11, 2021 16:16:49
    On 03 Dec 2020, Maurice Kinal said the following...

    Hey All!

    I am going to "crosspost" this msg in LINUX. I haven't seen any real traffic there in awhile so I don't believe it will have an negative effects. Besides it probably won't get past my uplink if indeed MSGIDs are universal and not just limited to the AREA as far as dupe checking goes.

    What are the odds?

    Life is good,
    Maurice

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

    Looks fine here :)

    --- Mystic BBS v1.12 A47 2021/01/05 (Linux/64)
    * Origin: Omicron Theta * Horn Lake MS * linux.winserver.org (1:116/18)
  • From Robert Wolfe@1:116/18 to Maurice Kinal on Monday, January 11, 2021 16:17:28
    On 03 Dec 2020, Maurice Kinal said the following...

    If any dupes did arrive they would be discarded as long as my
    tosser sees it as a dupe.

    I swear! It wasn't my fault this time! :)

    --- Mystic BBS v1.12 A47 2021/01/05 (Linux/64)
    * Origin: Omicron Theta * Horn Lake MS * linux.winserver.org (1:116/18)
  • From Maurice Kinal@1:153/7001 to Robert Wolfe on Monday, January 11, 2021 22:41:39
    -={ 2021-01-11 22:41:39.898111909+00:00 }=-

    Hey Robert!

    ^-^-^-@@-^-^-^
    (..)-----;
    ||---||
    ^^ ^^
    ... A Møøse once bit my sister ...
    --- GNU bash, version 5.0.18(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

    Looks fine here :)

    It sure does. I see the utf-8 characters survived despite the lack of a CHRS kludge. Gotta love it.

    I haven't heard from you in ages. Where have you been hiding?

    Life is good,
    Maurice

    ... Don't cry for me I have vi.
    --- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
    * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)