1. 26 Apr, 2020 1 commit
    • rswindell's avatar
      Fix bug reported by Mark Lewis (Rampage@SESTAR), when packing NetMail messages · 41ed7a56
      rswindell authored
      (from stored messages in .msg files into packets), the origin net/node within
      the  *packed message* header would be set to the local system's address
      net/node (for the destination zone), always. This is the appropriate action
      when packing EchoMail, but not for NetMail.
      Now, there are lot of other header fields in the packed message that contain
      the source/origin address (e.g. @FMPT, @INTL kludges) and those would reflect
      the original origin address still. And these fields take precedence over the
      orign net/node fields of the packed message header. So I'm not sure this bug
      would actually cause any problems anywhere, but it was a bug all the same.
  2. 22 Apr, 2020 1 commit
  3. 07 Apr, 2020 3 commits
  4. 03 Apr, 2020 3 commits
  5. 24 Mar, 2020 1 commit
  6. 11 Mar, 2020 1 commit
  7. 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).
  8. 20 Jan, 2020 1 commit
  9. 03 Jan, 2020 1 commit
  10. 18 Nov, 2019 2 commits
  11. 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.
  12. 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.
  13. 17 Oct, 2019 1 commit
  14. 08 Oct, 2019 1 commit
  15. 05 Oct, 2019 1 commit
  16. 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.
  17. 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.
  18. 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)
  19. 22 Aug, 2019 3 commits
  20. 20 Aug, 2019 1 commit
  21. 18 Aug, 2019 1 commit
  22. 16 Aug, 2019 1 commit
  23. 06 Aug, 2019 1 commit
  24. 04 Aug, 2019 3 commits
  25. 03 Aug, 2019 2 commits
  26. 02 Aug, 2019 2 commits
  27. 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
  28. 26 Jul, 2019 1 commit