1. 30 Apr, 2020 1 commit
    • rswindell's avatar
      When importing messages into a local msgbase that contained an origin line · 4364fd73
      rswindell authored
      but no tear line, I noticed that the initial space before "* Origin" was absent
      from the tail. It turns out the missing space character was being appended to
      the end of the body text. While investigating why that was, I was dismayed at
      the cruftiness of code but totally suprised that there was 80-column word-wrap
      logic in here (!). Removed that word-wrap logic <blush> and fixed the origin
      thing. More clean-up coming up next.
      4364fd73
  2. 28 Apr, 2020 2 commits
  3. 27 Apr, 2020 4 commits
  4. 26 Apr, 2020 2 commits
    • rswindell's avatar
      Add support for "robots": Right now, robots are for receiving netmail messages · 8df3c6b7
      rswindell authored
      only (e.g. areamgr requests or whatever). In the future, they could be extended
      to echomail areas too, if that's desirable.
      
      For now, it's really intended for ticket-FileFix.
      
      Anyway, NetMail can be received for the robot-name@<your-ftn-address> and
      the mail message will be stored in the Synchronet "mail" base. The recipient
      extension will be absent since there is no valid user account associated with
      the robot. Robot names supercede other user names/aliases for received netmail.
      If one or more netmail messages were imported for a robot and that robot has
      a semaphore path/filename specified (e.g. to trigger a timed event), then that
      semaphore will be "touched" before SBBSecho exits.
      One weird anomly with this is if attached files are received for robots, those
      files will be stored in data/user/0000.in. The altnerative is to just ignore
      file attachments sent to robots.
      
      The echofg supprot for robots is still yet to be added. In the mean time, you
      can add robots to your sbbsecho.ini like so:
      [robot:<name>]
      semfile=/path/to/semfile
      
      Incremented version to 3.11.
      8df3c6b7
    • 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.
      41ed7a56
  5. 22 Apr, 2020 1 commit
  6. 07 Apr, 2020 3 commits
  7. 03 Apr, 2020 3 commits
  8. 24 Mar, 2020 1 commit
  9. 11 Mar, 2020 1 commit
  10. 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
  11. 20 Jan, 2020 1 commit
  12. 03 Jan, 2020 1 commit
  13. 18 Nov, 2019 2 commits
  14. 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
  15. 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
  16. 17 Oct, 2019 1 commit
  17. 08 Oct, 2019 1 commit
  18. 05 Oct, 2019 1 commit
  19. 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
  20. 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
  21. 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
  22. 22 Aug, 2019 3 commits
  23. 20 Aug, 2019 1 commit
  24. 18 Aug, 2019 1 commit
  25. 16 Aug, 2019 1 commit
  26. 06 Aug, 2019 1 commit
  27. 04 Aug, 2019 2 commits