1. 24 Mar, 2020 1 commit
  2. 11 Mar, 2020 1 commit
  3. 23 Jan, 2020 1 commit
    • rswindell's avatar
      Fix bug introduced in rev 1.236 (April-3-2014): · 579119c9
      rswindell authored
      Areafix requests to unlink a node from an area would corrupt the list of
      linked nodes: the *last* listed node would always be removed. If this was
      not the node that submitted the areafix request, then 2 nodes would be
      removed from the list of linked-nodes for an echo.
      To simplify this, we're just going to not write the removed node back to
      the area file, but leave it in the in-memory list. So technically, the node
      won't be unlinked until the next run of SBBSecho when the area file is
      re-parsed. If that's a problem, we can always add run-time removal from
      the in-memory list later. Reported by Alterego (ALTERANT).
  4. 20 Jan, 2020 1 commit
  5. 03 Jan, 2020 1 commit
  6. 18 Nov, 2019 2 commits
  7. 30 Oct, 2019 1 commit
    • rswindell's avatar
      Even more loop-prevention paranoia: · 4fcf37b0
      rswindell authored
      If a packed messages contains no PATH or SEEN-BY lines, we can still detect
      and prevent a message loop by comparing the origin address in the packet header
      against the downlink's address and if it's a match, skip that downlink.
      It is still possible that a packed message header contains a different origin
      address than the packet header, and we're actually over-writing the packed
      messge header variable with the parsed Origin: line address (if there is one),
      so perhaps we'll want to compare the (actual) packed message header origin
      address too at some point in the future, if loops continue to be a problem.
  8. 27 Oct, 2019 1 commit
    • rswindell's avatar
      More loop prevention: check a message's PATH in addition-to its SEEN-BYs in · cc14d426
      rswindell authored
      If for some weird reason a downlink's address is in the PATH, but not in the
      SEEN-BYs, detect as a loop and don't send to (add to an outbound pkt for) the
      This is an experimental change to see if it addresses the issue reported by
      Richard Williamson and Mark Lewis with regards to dupes in the COOKING
      echo from point nodes off 1:396/45.
  9. 17 Oct, 2019 1 commit
  10. 08 Oct, 2019 1 commit
  11. 05 Oct, 2019 1 commit
  12. 17 Sep, 2019 1 commit
    • rswindell's avatar
      Added support for auto-detection of incoming UTF-8 messages (default: enabled). · 6942ba6b
      rswindell authored
      If an incoming message contains no CHRS/CHARSET control line *and* the message
      text contains valid UTF-8 character encodings, set the FTN charset value to
      UTF-8 so the message will be displayed/handled accordingly.
      I did not add checks for header fields (to/from/subject) - we should probably
      auto-detect UTF-8 in those as well, but for now, I don't see messages coming
      into FidoNet echoes with UTF-8 in the header fields.
      Incremented SBBSecho/EchoCfg version to 3.10.
  13. 30 Aug, 2019 1 commit
    • rswindell's avatar
      Revert last commit. The example packed message with the corrupted DateTime · 93bcd8a0
      rswindell authored
      was not a recoverable message header (e.g. the toUserName field was *not*
      at offset 0x22):
      xx 02 00 01 00 01 00 6A - 02 FE 01 00 00 00 00 30   : .......j.......0
      34 20 46 65 62 20 31 31 - 39 20 20 32 30 3A 32 36   : 4 Feb 119  20:26
      3A 33 32 04 00 4B 75 72 - 74 20 57 65 69 73 6B 65   : :32..Kurt Weiske
      So restore the DateTime field validation: the 20th byte must be null.
  14. 27 Aug, 2019 1 commit
    • rswindell's avatar
      Don't require that the last character of the "DateTime" field of packed · c0c60161
      rswindell authored
      messages is a null (0x00) byte. Some broken FidoNet software may include
      a full 20 usable characters in their DateTime header field, like so:
      "04 Feb 119  20:26:32" - representing February 4th, 2019.  Y2K. <sigh>
      The DateTime won't be parsed fully correct, but at least the packet won't be
      rejected outright because it is "Grunged". - for Alterego (ALTERANT)
  15. 22 Aug, 2019 3 commits
  16. 20 Aug, 2019 1 commit
  17. 18 Aug, 2019 1 commit
  18. 16 Aug, 2019 1 commit
  19. 06 Aug, 2019 1 commit
  20. 04 Aug, 2019 3 commits
  21. 03 Aug, 2019 2 commits
  22. 02 Aug, 2019 2 commits
  23. 30 Jul, 2019 2 commits
    • rswindell's avatar
      For Mark Lewis: · 2e591193
      rswindell authored
      When writing non-bundle file paths/names to BSO/FLO files, don't use the
      delete (^) prefix unless the message has the "Kill Sent" attribute set. This
      seems kind of wrong to me. The KFS "Kill File Sent" flag has been defined in
      FSC-0053 since 1992, that seems more likely the appropriate flag to determine
      if a message attachment should be deleted (or not) after being sent. But
      parsing/using the "Flags" control line flags isn't already in SBBSecho, so
      I'll just punt for now and do what Mark asked for. <shrug>
    • rswindell's avatar
      Remove unused variable. · a62b1982
      rswindell authored
  24. 26 Jul, 2019 2 commits
  25. 25 Jul, 2019 1 commit
  26. 23 Jul, 2019 1 commit
    • rswindell's avatar
      New option for SBBSecho to basically ignore any configured outboxes for · 55a2e1e4
      rswindell authored
      linked nodes: UseOutboxes (default: true)
      BinkIT will continue to outboxes even when this option is set to false, but
      SBBSecho won't place any mail files in the outboxes when this option is set to
      For PSI-Jack who was surprised that SBBSecho put mail files into outboxes.
      Since it appears BinkD supports both outboxes and normal outbound directories
      for linked nodes and BinkIT does as well, this shouldn't really make any
      difference - just a sysop preference.
  27. 22 Jul, 2019 1 commit
  28. 29 Jun, 2019 1 commit
  29. 22 Jun, 2019 1 commit
    • rswindell's avatar
      Bug-fix: Support [node:<addr>@<domain>] sections in AreaFix changes. · cae53945
      rswindell authored
      When processing area manager netmail messages, SBBSecho can modify
      (add/change) keys in the [node:*] section of the sbbsecho.ini file. Although
      SBBSecho would read node sections that had a domain (e.g. 5D address) just fine
      when processing area manager changes and writing those changes back to the
      sbbsecho.ini, only 4D addresses (no "@domain") were used in the section naming.
      This could result in duplicate node sections being created in the sbbsecho.ini
      file (one with a "@domain", one without) and then "bad things" could happen
      (e.g. BinkP authentication failures, packet authentication failures, etc.).
      Now, when SBBSecho writes linked-node setting to the sbbsecho.ini, it first
      checks for the full 5D address of the node and if that section exists, modify
      it, otherwise fall-through to the 3D/4D address of the node for the sectoin
  30. 28 May, 2019 1 commit
  31. 30 Apr, 2019 1 commit