1. 07 Apr, 2020 1 commit
  2. 03 Apr, 2020 3 commits
  3. 24 Mar, 2020 1 commit
  4. 11 Mar, 2020 1 commit
  5. 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).
      579119c9
  6. 20 Jan, 2020 1 commit
  7. 03 Jan, 2020 1 commit
  8. 18 Nov, 2019 2 commits
  9. 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.
      4fcf37b0
  10. 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
      write_to_pkts():
      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
      downlink.
      
      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.
      cc14d426
  11. 17 Oct, 2019 1 commit
  12. 08 Oct, 2019 1 commit
  13. 05 Oct, 2019 1 commit
  14. 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.
      6942ba6b
  15. 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.
      93bcd8a0
  16. 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)
      c0c60161
  17. 22 Aug, 2019 3 commits
  18. 20 Aug, 2019 1 commit
  19. 18 Aug, 2019 1 commit
  20. 16 Aug, 2019 1 commit
  21. 06 Aug, 2019 1 commit
  22. 04 Aug, 2019 3 commits
  23. 03 Aug, 2019 2 commits
  24. 02 Aug, 2019 2 commits
  25. 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>
      2e591193
    • rswindell's avatar
      Remove unused variable. · a62b1982
      rswindell authored
      a62b1982
  26. 26 Jul, 2019 2 commits
  27. 25 Jul, 2019 1 commit
  28. 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
      true.
      
      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.
      55a2e1e4
  29. 22 Jul, 2019 1 commit