1. 16 Aug, 2019 1 commit
  2. 06 Aug, 2019 1 commit
  3. 04 Aug, 2019 3 commits
  4. 03 Aug, 2019 2 commits
  5. 02 Aug, 2019 2 commits
  6. 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
  7. 26 Jul, 2019 2 commits
  8. 25 Jul, 2019 1 commit
  9. 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.
  10. 22 Jul, 2019 1 commit
  11. 29 Jun, 2019 1 commit
  12. 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
  13. 28 May, 2019 1 commit
  14. 30 Apr, 2019 2 commits
  15. 29 Apr, 2019 1 commit
  16. 15 Apr, 2019 1 commit
  17. 12 Apr, 2019 1 commit
  18. 10 Apr, 2019 1 commit
  19. 19 Mar, 2019 3 commits
    • rswindell's avatar
    • rswindell's avatar
      Fix the off-by-one error in the COLS kludge line parsing logic. · 3da89611
      rswindell authored
      Don't store a columns value of 0 (the default).
      Use SAFEPRINTF in place of sprintf() in parse_control_line().
    • rswindell's avatar
      Export/import the original message editor column width (when known) as a new · 3a1923d8
      rswindell authored
      FidoNet "Kludge line" (control line): "\1COLS: <columns>\r" where <columns>
      is a value between 0 and 255 and a value of 0 is special, meaning "unknown"
      and not normally specified (this is the default assumption when there is no
      "columns"/COLS header field). When a message editor column width is unknown,
      is is normally assumed to have been 80 columns for word-wrapping/re-wrapping
      purposes when displaying the message text.
      This feature has worked well for Synchronet's QWK networking (i.e. there are
      far fewer instances of word-wrapping/re-wrapping issues when viewing messages
      on DOVE-Net), so I decided to support this message header field over FTN
      (SBBSecho) as well. Hopefully other FidoNet software authors will notice and
      support this header field in the future as there are still numerous examples
      of word-wrap issues when viewing FidoNet messages. At least Synchronet <->
      Synchronet systems over FidoNet should be able to re-wrap and display all
      message text nicely when both ends support this kludge line.
      Incremented SBBSecho version number to 3.07.
  20. 12 Feb, 2019 1 commit
    • rswindell's avatar
      Restore the BRE inter-bbs netmail attachment work-around from SBBSecho v2: · a3b2f9e2
      rswindell authored
      If the attached file begins with a '^', ignore/skip that character in the file
      path. This should resolve the error reported by Ken  of Section One BBS:
      ERROR line 850, attachment file not found: ^C:/SBBS/XTRN/BRE777/...
      SBBSecho v2.x included this work-around and it was not included in the v3
      re-factoring/re-write. Of course, BRE is doing something wrong and is totally
      at fault here, but no one expects BRE to be fixed... ever. :-)
  21. 08 Feb, 2019 1 commit
    • rswindell's avatar
      Add/use new function findstr_list() which opens and returns a string list · 32051b32
      rswindell authored
      suitable for passing to findstr_in_list().
      SBBSecho peformance improvement: don't open/read the twitlist.cfg file for
      *each* imported message: just read it once during initialization (using the new
      findstr_list() function of course).
      Reversed course on the findstr()/trashcan() matching logic: significant leading
      white-space was not backwards compatible (and was the cause of recent lost
      messages in DOVE-Net) - so I decided to go a different route and support
      C-style character escape sequences (e.g. \r, \n, \t, \x##, etc.) in findstr
      comparison strings, so the new way to represent a leading space character
      in a filter file (e.g. twitlist.cfg, name.can) would be: "\ ". So to match (e.g.
      filter/disallow) all strings with a leading space: "\ *". "\x20 *" would also
      work (0x20 is ASCII for "space").
      Now, again, leading white-space in filter files (e.g. text/*.can, twitlist.cfg)
      is ignored. <sigh>
  22. 17 Jan, 2019 1 commit
  23. 11 Jan, 2019 1 commit
    • rswindell's avatar
      A partial retraction of the Ctrl-AZ interpretation changes introduced on · b2412964
      rswindell authored
      It turns out, PabloDraw actually inserts a Ctrl-AZ sequence at the end of .msg
      (and presumably Synchronet .asc) files it edits - before the SAUCE record.
      This resulted in a printed Ctrl-Z character (arrow pointing right) in most
      terminals when viewing text/menu files created or edited with PabloDraw. :-(
      So, now Ctrl-AZ (uppercase) will revert to the previous definition:
      premature end-of-file (EOF)
      and a Ctrl-Az (lowercase) will output a Ctrl-Z (substitute) character.
      I'm not a big fan of case-sensitive Ctrl-A codes, but frankly, running out of
      chars and I already started this pattern with the Ctrl-AF/f sequences.
      Hopefully there's no existing software that is/was putting Ctrl-Az (lowercase)
      in files, expecting that to trigger a premature EOF. I certainly was not.
  24. 18 Dec, 2018 2 commits
  25. 23 Nov, 2018 1 commit
    • rswindell's avatar
      Fuzzy Zone operation: make the implementation match the feature · e158ebc0
      rswindell authored
      description/documentation more closely. That is, if there is an INTL kludge
      line in the incoming netmail message, there will be no "fuzzy" zone matching.
      This means that Fuzzy Zone operation will only apply to netmail messages that
      do *not* have an INTL kludge line (which specifies the source and destination
      zones already). This solves the problem reported by Mark Lewis with
      unexpected Fuzzy Zone behavior (when enabled), it was over-riding the
      source zone number even though it was specified (via INTL kludge) in the
      original netmail message body.
  26. 06 Nov, 2018 1 commit
    • rswindell's avatar
      Don't generate FTN message-IDs for messages imported via FTN that are missing a · b1692861
      rswindell authored
      message-ID (e.g. when exporting from SBBSecho).
      This addresses compliance with this [editorialized] clause in FTS-9:
           No system
           should ever add an MSGID and/or REPLY to,  or modify an existing
           MSGID / REPLY contained in,  a message not originating on that [FTN]
      Messages gated from other networks (technically coming from another system,
      but originating into an FTN from this system) will still have an FTN Message-ID
      Since SBBSecho normally tosses to downlinks directly from packets, this adding
      of generated Message-IDs would no normally occur. However, if a downlink
      rescanned an area, any messages missing Message-IDs would get them generated
      automatically and they would appear to have originating on the local system.
      This was never the intention, so this is just a long standing but infrequently
      observed (and never reported) bug.
  27. 29 Oct, 2018 1 commit
    • rswindell's avatar
      Requested change by Mark Lewis: · 9ed98f0f
      rswindell authored
      can we get a slight change in the sbbsecho code or maybe in echocfg so that
      when a link is set to passive, areafix notices are NOT sent to them even if
      "send notices" is specifically set to yes?
  28. 17 Oct, 2018 1 commit
  29. 16 Oct, 2018 1 commit
  30. 15 Oct, 2018 1 commit