• Binkd with Fastecho...

    From Andrew Leary@1:320/219 to Nick Boel on Sat Dec 7 06:18:41 2024
    Hello Nick!

    03 Dec 24 17:18, you wrote to all:

    No, unfortunately binkd is doing it wrong by default. Fastecho
    implements 5D BSO correctly according to the FTSC standard. And yes,
    using a non-existing zone (e.g. 1) as the default zone for the
    domain is a proper workaround.

    I guess it's time for me to re-read the standard, then. I could have
    sworn 4d uses the hex value extensions (ie outbound.001, and 5d didn't
    (ie outbound).

    5D BSO support uses the hex zone number extension for all but the primary zone in that domain. binkd is actually flexible enough to work around many mail packages that do it wrong. FastEcho, for example, always uses the hex zone number extension for domain directories.

    ie: micronet.26a for Micronet zone 618, even though 618 is the primary zone in that domain.

    Thus, by lying to binkd that the primary zone for all domains is 1, you can force binkd to use the hex zone extension for all of your added domains, which is exactly what FastEcho produces.

    Andrew

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)
  • From Nick Boel@1:154/700 to Andrew Leary on Sat Dec 7 06:51:04 2024
    Hello Andrew,

    On Sat, Dec 07 2024 05:18:41 -0600, you wrote ..

    Thus, by lying to binkd that the primary zone for all domains is 1, you can force binkd to use the hex zone extension for all of your added domains, which
    is exactly what FastEcho produces.

    So, I'm in the same book, just the wrong page? :)

    Either way, I was certain it was binkd using 'workarounds' to be able to adapt to most tossers that do things slightly different. The default zone being set to "1" for all domains was definitely one of them.

    Regards,
    Nick

    ... He who laughs last, thinks slowest.
    --- SBBSecho 3.23-Linux
    * Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)
  • From Oli@2:280/464.47 to Andrew Leary on Sun Dec 8 17:17:17 2024
    Andrew wrote (2024-12-07):

    5D BSO support uses the hex zone number extension for all but the primary zone in that domain.

    In BSO the hex zone number extension is omitted for the default outbound only, which is the default zone in the first domain. Every other outbound directory has a zone extension.

    From FTS-5005.003:

    For example, if your default outbound is C:\BINK\OUTBOUND
    for the outbound holding area (and you are in FidoNet), Amiganet
    (zone 39) outbound mail would be held in the C:\BINK\AMIGANET.027
    directory instead. Note that outbound areas for domains other than
    your primary will ALWAYS have a zone extension, and that zone
    extensions are always specified in Hexadecimal, up to .FFF (4095).

    The outbound holding areas (for Zone 1 FidoNet) would then be as
    follows:

    c:\bink\outbound (Default Outbound)
    c:\bink\outbound.002 (FidoNet Zone 2)
    c:\bink\outbound.003 (FidoNet Zone 3)
    c:\bink\outbound.004 (FidoNet Zone 4)
    c:\bink\amiganet.027 (Amiganet Zone 39)
    c:\bink\agoranet.02e (Agoranet Zone 46)
    c:\bink\dbnet.0c9 (Dbnet Zone 201)

    binkd is actually flexible enough to work around
    many mail packages that do it wrong. FastEcho, for example, always uses the hex zone number extension for domain directories.

    binkd never implemented it correctly. What you call a workaround is a workaround for a binkd bug. The narrative that all the other mailers do it wrong and binkd is the one software that does it right is just an alternative fact. BSO 5D was used before binkd even existed. BinkleyTerm had no problems with 5D outbound from Fastecho, Squish, Crashmail and other mailers .

    ---
    * Origin: No REPLY kludge - no reply (2:280/464.47)