1. 03 Jan, 2020 1 commit
  2. 18 Nov, 2019 2 commits
  3. 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.
  4. 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.
  5. 17 Oct, 2019 1 commit
  6. 08 Oct, 2019 1 commit
  7. 05 Oct, 2019 1 commit
  8. 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.
  9. 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.
  10. 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)
  11. 22 Aug, 2019 3 commits
  12. 20 Aug, 2019 1 commit
  13. 18 Aug, 2019 1 commit
  14. 16 Aug, 2019 1 commit
  15. 06 Aug, 2019 1 commit
  16. 04 Aug, 2019 3 commits
  17. 03 Aug, 2019 2 commits
  18. 02 Aug, 2019 2 commits
  19. 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
  20. 26 Jul, 2019 2 commits
  21. 25 Jul, 2019 1 commit
  22. 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.
  23. 22 Jul, 2019 1 commit
  24. 29 Jun, 2019 1 commit
  25. 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
  26. 28 May, 2019 1 commit
  27. 30 Apr, 2019 2 commits
  28. 29 Apr, 2019 1 commit
  29. 15 Apr, 2019 1 commit
  30. 12 Apr, 2019 1 commit