src/sbbs3 sbbsecho.c 3.63 3.64
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv5466

Modified Files:
sbbsecho.c
Log Message:
New feature: when exporting FTN netmail from the "mail" base, if the message has a MIME-encoded file attachment, decode that attachment into a file and attach to the message FTN-style.
- This allows sending of FTN file attached netmail using your Internet email
client.
- Only a single attachment is supported (consistent with all attachment support
in SBBSecho).
create_netmail() enhancements:
Don't add the FLAGS control line if we're in FLO-mode - this line is not used by BSO/FLO mailers.
If there is a file attachment, but the message contains a subject, add a Subject: <original subject> line to the message body, since FTN requires the attached filename be placed in the subject.

--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.64 3.65
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv18641

Modified Files:
sbbsecho.c
Log Message:
When packetizing netmail, don't add the INTL kludge line if it already
exists in the message body.


--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.65 3.66
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20824

Modified Files:
sbbsecho.c
Log Message:
Fix AreaFix "HELP" command response, broken in rev 3.59, reported by
Rastus:
file_to_netmail() assumed the file pointer was at the end of the file.
This was not the case with the areamgr.hlp file (just opened, not read or seeked).
Also, added some more error logging in case of file_to_netmail() failure.


--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.66 3.67
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv25691

Modified Files:
sbbsecho.c
Log Message:
Don't trim trailing white-space off of incoming MSGID and REPLY (reply-id) values. Apparently since this behavior is not not universal, it causes
some systems to treat the 2 MSG-IDs (one with and one without trailing whitespace) as unique, causing potential dupes. Reported by Mark Lewis.


--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.67 3.68
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv30298

Modified Files:
sbbsecho.c
Log Message:
Address many (but not all) Coverity reported "issues".

--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.69 3.70
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv26643

Modified Files:
sbbsecho.c
Log Message:
Add BBS name and sysop name to PING netmail response message body.

--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.70 3.71
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv7753

Modified Files:
sbbsecho.c
Log Message:
Fix pong response bug introduced in previous commit.

--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.73 3.74
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv445

Modified Files:
sbbsecho.c
Log Message:
Bug-fix: The Auto-Add-Subs feature would not create the area file (areas.bbs) if it didn't already exist.


--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.74 3.75
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20684

Modified Files:
sbbsecho.c
Log Message:
Some status string (e.g. "Loading user names...") were being sent to stderr instead of stdout.


--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.75 3.76
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Log an error if ftouch() fails to create the outbound sem file.


--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.76 3.77
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Use GCC-assisted printf-style format/arg checking to find and fix instances
of lprintf() misuse.


--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.77 3.78
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1786

Modified Files:
sbbsecho.c
Log Message:
Attempt to address GCC v7 warnings raised by Nelgin:
warning: format not a string literal and no format arguments [-Wformat-security]

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.78 3.79
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv18475

Modified Files:
sbbsecho.c
Log Message:
Bug-fix: when exporting FTN netmail from SMB "mail" base, if the netmail included an "old-style" (not MIME-encoded) file attachment (where the file path is in the subject and the FILEATTACH aux-attribute flag is set), the corresponding netmail attribute flag would not be set in the stored msg (*.msg) file. Also simplified the create_netmail() function prototype/usage, removing the "file_attached" argument (use the hdr.auxattr instead).

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.79 3.80
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
write_flofile(): if the 'infile' path contains a drive letter prefix
(e.g. "C:"), skip it on *nix and if the path contains backslashes, convert
to forward-slashes (for all OSes). This resolves an issue of sending a
netmail file-attachment that was created on a Windows/MS-DOS type system
and then scanned/exported on a *nix system. The FTN "stored message"
convention is to have the full path of the attached file in the message subject.

Hopefully nobody wants to use outbound directory names beginning with "x:"
on *nix. :-)


--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.80 3.81
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv19737

Modified Files:
sbbsecho.c
Log Message:
If a bundle file cannot be unpacked after 48-hours, if the file is 0-bytes in length, just delete it (don't rename to *.?_?).

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.81 3.82
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv32044

Modified Files:
sbbsecho.c
Log Message:
When exporting msgs that came from an FTN (e.g. during a rescan), don't convert existing tear/origin lines and don't add a new origin line.

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.82 3.83
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv2537

Modified Files:
sbbsecho.c
Log Message:
Add a ^ARESCANNED w:x/y.z control line to exported messages during a rescan (apparently this is a pseudo-standard supported by fastecho and other "old-school" tossers) - per mark lewis' request.

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.83 3.84
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv17065

Modified Files:
sbbsecho.c
Log Message:
Address RMH's issue:
When the local system has multiple AKAs for the same zone and we are picking a origin/source address suitable for the destination address, pick the AKA that matches both the zone and net of the destination address first (if there is such a local AKA). It's the same logic used in sbbs_t::netmail() to display
the originating address, so the AKA picking logic now matches what is shown
to the netmail author and what SBBSecho will actually use.

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.84 3.85
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv28074

Modified Files:
sbbsecho.c
Log Message:
Another improvement to create_netmail():
If the SMB header contains a source FTN address, use that as the origin address of the netmail and do not look-up a local AKA match for the destination address.
Also, fix what appears to have been a (currently harmless) bug in smsg_to_echostat_msg(): the msg.from_net.addr is not an ASCIIZ string when net.type == NET_FIDO. Currently, source FTN addresses aren't set in echomail message headers, where the echostats come from. Could just remove
these 2 lines.

--- SBBSecho 3.04-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.85 3.86
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv18682

Modified Files:
sbbsecho.c
Log Message:
When importing packets, don't export previously-rescanned messages
(messages which contain the RESCANNED control line) to downlinks.

Also renamed pkt_to_pkt() to write_to_pkts().


--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.87 3.88
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv12172

Modified Files:
sbbsecho.c
Log Message:
When adding a new sub-board to the area file, if the sub has a "newsgroup"
name specified, use that instead of the short name as the "Echo Tag"
(Area Tag) value.


--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.88 3.89
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv14995

Modified Files:
sbbsecho.c
Log Message:
Fix crash (segfault) reported in AreaFix handler for "-ALL", reported
by Ragnarok@DOCKSUD.


--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.89 3.90
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Log an error if one or more file attachments could not be deleted when attempted.


--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.90 3.91
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv13077

Modified Files:
sbbsecho.c
Log Message:
Don't delete netmail file attachments: just because the netmail was exported
to .msg file doesn't mean you should delete the file attachment! The .msg
file will still be pointing to that file and it needs to be there.
SBBSecho was silently failing to delete file attachments on my system, so
I didn't see this problem. Oops. Anyway, this explains Al's problem with netmail attachments.


--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.92 3.93
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv18679

Modified Files:
sbbsecho.c
Log Message:
Updated failure/error log messages for SMB library function call failures: always include the text description of the last error and the line number.
The logging of the smb.file string is probably redundant since that path
will likely be included in the last_error string.


--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.94 3.95
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv25420

Modified Files:
sbbsecho.c
Log Message:
Fix bug with AreaFix "ECHOSTATS" command: if the echotag specified was not found, it would be added to the list of echoes tracked in echostats.ini. Ideally, a negative-response message would be sent to requester in this case, but we're not doing that currently.


--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.96 3.97
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1311

Modified Files:
sbbsecho.c
Log Message:
Requested change by Mark Lewis:
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?

--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Oct 28 23:29:28, rswindell wrote to CVS commit:

Modified Files:
sbbsecho.c
Log Message:
Requested change by Mark Lewis:
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?

thank you... i'm guessing that the option in the config file toggles when links
change their statuses? glad to see the change wasn't very involved :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I generally prefer normal late-19th century cuisine. ML
---
* Origin: (1:3634/12.73)

Re: src/sbbs3/sbbsecho.c
By: mark lewis to Digital Man on Mon Oct 29 2018 12:56 pm

On 2018 Oct 28 23:29:28, rswindell wrote to CVS commit:

Modified Files:
sbbsecho.c
Log Message:
Requested change by Mark Lewis:
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?

thank you... i'm guessing that the option in the config file toggles when links
change their statuses? glad to see the change wasn't very involved :)

Right. That link setting is modifiable via areafix.

digital man

Synchronet/BBS Terminology Definition #19:
DOCSIS = Data Over Cable Service Interface Specification
Norco, CA WX: 76.9°F, 43.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.98 3.99
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv30801

Modified Files:
sbbsecho.c
Log Message:
Fuzzy Zone operation: make the implementation match the feature 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.


--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.99 3.100
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv17849

Modified Files:
sbbsecho.c
Log Message:
Log a notice-level message when adding a new area to the unknown/bad area list.


--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.100 3.101
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv18772

Modified Files:
sbbsecho.c
Log Message:
Change requested by Mark Lewis: accept area manager (areafix) netmail
requests sent to "SBBSecho" again. SBBSecho used to allow this back in
v3.02 (Nov-2017) and earlier versions, but was removed for loop-safety
since AreaMgr notifications and responses are sent from "SBBSecho", but
we have bot-loop protection built in, so that should be okay.


--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.102 3.103
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv8260

Modified Files:
sbbsecho.c
Log Message:
Longer, hopefully more helpful, "Authenticated EchoMail" warning log msg.


--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.104 3.105
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv3902

Modified Files:
sbbsecho.c
Log Message:
Restore the BRE inter-bbs netmail attachment work-around from SBBSecho v2:
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. :-)

--- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.106 3.107
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv23463

Modified Files:
sbbsecho.c
Log Message:
Fix the off-by-one error in the COLS kludge line parsing logic.
Don't store a columns value of 0 (the default).
Use SAFEPRINTF in place of sprintf() in parse_control_line().


--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.107 3.108
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv32444

Modified Files:
sbbsecho.c
Log Message:
Add "COLS" kludge line to EchoMail msgs too (not just NetMail) - oops.


--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.109 3.110
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv7631

Modified Files:
sbbsecho.c
Log Message:
Remove reference to removed/unused enum value: NET_FIDO_ASCII


--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.110 3.111
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv15890

Modified Files:
sbbsecho.c
Log Message:
Fix potential crash in create_netmail(), bug introduced in rev 3.108:
When responding to AreaFix requests, it's normal for create_netmail() to be called with a NULL 'msg' argument value - so don't try to dereference it
(for the "cols" header field value) if it's NULL. Thanks to Mark Lewis for the bug report.


--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.111 3.112
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv31205

Modified Files:
sbbsecho.c
Log Message:
Use FIDO_SOFT_CR (0x8d) rather than the magic number

--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.114 3.115
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv26186

Modified Files:
sbbsecho.c
Log Message:
Don't warn about free disk space for directories that don't exist.
Log free disk space errors to sbbsecho.log (as well as print to stdout).


--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.115 3.116
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv11356

Modified Files:
sbbsecho.c
Log Message:
Bug-fix: Support [node:<addr>@<domain>] sections in AreaFix changes.

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 naming.

--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Jun 22 15:27:42, rswindell wrote to CVS commit:

Modified Files:
sbbsecho.c
Log Message:
Bug-fix: Support [node:<addr>@<domain>] sections in AreaFix changes.

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.).

i've seen this! never was able to spend time to try to figure out the problem so was unable to report the bug... glad to know that it has been found and fixed! yay!

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 naming.

that's like what tickit is doing when it hunts for a system's tic password... look for this and if not found, then look for the other form of address...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Don't corner something meaner than you.
---
* Origin: (1:3634/12.73)

src/sbbs3 sbbsecho.c 3.116 3.117
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Don't need lzh.h here.


--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.120 3.121
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv21629

Modified Files:
sbbsecho.c
Log Message:
When importing fidonet mesages, if there's a Ctrl-A char which is *not* the start of a valid control paragraph (kludge line), then convert the Ctrl-A char to an '@'. This handles the situation where someone quotes control paragraphs with Ctrl-A chars, for example, we don't want those Ctrl-A chars being misinterpreted as Ctrl-A codes causing weird colors or pauses or whatever.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Jul 25 21:55:18, rswindell wrote to CVS commit:

When importing fidonet mesages, if there's a Ctrl-A char which is
*not* the start of a valid control paragraph (kludge line), then
convert the Ctrl-A char to an '@'. This handles the situation where someone quotes control paragraphs with Ctrl-A chars, for example, we
don't want those Ctrl-A chars being misinterpreted as Ctrl-A codes
causing weird colors or pauses or whatever.

thanks for this! i see similar with pipe codes, too... they're used in the fidonet software listings published in the fidonet or fidogazette newsletters... i've written a note to the maintainer of that list but they are apparently busy in RL and have not gotten back to me... basically the pipe codes are being interpreted in the same manner as the ^A codes... i'm not sure how to handle it, though, other than disabling pipe codes in all fidonet areas via the template area...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them.
... A bachelor lives like a king and dies like a beggar.
---
* Origin: (1:3634/12.73)

Re: src/sbbs3/sbbsecho.c
By: mark lewis to digital man on Fri Jul 26 2019 12:10 pm

On 2019 Jul 25 21:55:18, rswindell wrote to CVS commit:

When importing fidonet mesages, if there's a Ctrl-A char which is
*not* the start of a valid control paragraph (kludge line), then convert the Ctrl-A char to an '@'. This handles the situation where someone quotes control paragraphs with Ctrl-A chars, for example, we don't want those Ctrl-A chars being misinterpreted as Ctrl-A codes causing weird colors or pauses or whatever.

thanks for this! i see similar with pipe codes, too... they're used in the fidonet software listings published in the fidonet or fidogazette newsletters... i've written a note to the maintainer of that list but they are apparently busy in RL and have not gotten back to me... basically the pipe codes are being interpreted in the same manner as the ^A codes... i'm not sure how to handle it, though, other than disabling pipe codes in all fidonet areas via the template area...

Pipe code support can only be enabled/disabled (in Synchronet) globally. :-(

digital man

Synchronet/BBS Terminology Definition #27:
FOSSIL = Fido/Opus/SEAdog Standard Interface Layer
Norco, CA WX: 90.5°F, 37.0% humidity, 4 mph N wind, 0.00 inches rain/24hrs
--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Digital Man to mark lewis on Fri Jul 26 2019 11:47 am

Re: src/sbbs3/sbbsecho.c
By: mark lewis to digital man on Fri Jul 26 2019 12:10 pm

On 2019 Jul 25 21:55:18, rswindell wrote to CVS commit:

When importing fidonet mesages, if there's a Ctrl-A char which is *not* the start of a valid control paragraph (kludge line), then convert the Ctrl-A char to an '@'. This handles the situation where someone quotes control paragraphs with Ctrl-A chars, for example, we don't want those Ctrl-A chars being misinterpreted as Ctrl-A codes causing weird colors or pauses or whatever.

thanks for this! i see similar with pipe codes, too... they're used in the fidonet software listings published in the fidonet or fidogazette newsletters... i've written a note to the maintainer of that list but they are apparently busy in RL and have not gotten back to me... basically the pipe codes are being interpreted in the same manner as the ^A codes... i'm not sure how to handle it, though, other than disabling pipe codes in all fidonet areas via the template area...

Pipe code support can only be enabled/disabled (in Synchronet) globally. :-(

Before today... :-)

digital man

Synchronet/BBS Terminology Definition #40:
IMAP = Internet Message Access Protocol
Norco, CA WX: 94.5°F, 34.0% humidity, 4 mph NNE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.122 3.123
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv8880

Modified Files:
sbbsecho.c
Log Message:
Remove unused variable.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.123 3.124
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv10902

Modified Files:
sbbsecho.c
Log Message:
For Mark Lewis:
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>


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Jul 29 22:25:52, rswindell wrote to CVS commit:

Modified Files:
sbbsecho.c
Log Message:
For Mark Lewis:
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.

you are correct... it is wrong... the main thing i wanted/needed was for sbbsecho to not kill file attaches... their deletion appeared to be being triggered by the KillSent bit...

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,

exactly...

so I'll just punt for now and do what Mark asked for. <shrug>

the main thing is the files are no longer killed... attached files really should be uncoupled from the KillSent bit completely... they should only be killed if the KFS flag is set if/when sbbsecho implements the Flags control line... yes, i was slightly confused and kept thinking about the KFS flag... plus my brain was burnt from fixing makenl's C code... it has been a long time since i've done any C stuff like that and once i got it figured out, the fix was only like 8 lines added and 2 changed :lol:

)\/(ark

Once men turned their thinking over to machines in the hope that this would set
them free. But that only permitted other men with machines to enslave them.
... But if the handwriting on the wall is a forgery?
---
* Origin: (1:3634/12.73)

Re: src/sbbs3/sbbsecho.c
By: mark lewis to digital man on Wed Jul 31 2019 08:30 pm

On 2019 Jul 29 22:25:52, rswindell wrote to CVS commit:

Modified Files:
sbbsecho.c
Log Message:
For Mark Lewis:
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.

you are correct... it is wrong... the main thing i wanted/needed was for sbbsecho to not kill file attaches... their deletion appeared to be being triggered by the KillSent bit...

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,

exactly...

so I'll just punt for now and do what Mark asked for. <shrug>

the main thing is the files are no longer killed...

They will be if the KILLSENT flag is sent (which is normal).

attached files really
should be uncoupled from the KillSent bit completely... they should only be killed if the KFS flag is set if/when sbbsecho implements the Flags control line... yes, i was slightly confused and kept thinking about the KFS flag... plus my brain was burnt from fixing makenl's C code... it has been a long time since i've done any C stuff like that and once i got it figured out, the fix was only like 8 lines added and 2 changed :lol:

Okay. I'll probably just add the KFS flag checking and remove the checking of the KILLSENT attr bit for that logic.

digital man

Synchronet/BBS Terminology Definition #9:
BSO = Binkley Style Outbound
Norco, CA WX: 66.2°F, 87.0% humidity, 0 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.124 3.125
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv19947

Modified Files:
sbbsecho.c
Log Message:
If SBBSecho imports a message with a "CHRS" control line with a value of "UTF-8", set the msg's auxattr MSG_HFIELDS_UTF8 flag because FTS-5003 states:
"The character set identifier applies to all parts of the message,
including the header information and the control lines like origin
and tear line."


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.125 3.126
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv29414

Modified Files:
sbbsecho.c
Log Message:
Use the \1FLAGS KFS (parsed crudely from netmail .msg body text) to trigger file-attachment deletion in write_flofile() - not the KILLSENT attribute flag. Export the SMB MSG_KILLSENT auxattr from SMB mail to FTN netmail \1FLAGS KFS.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.126 3.127
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv22270

Modified Files:
sbbsecho.c
Log Message:
Export a default CHRS: (charset) value of "UTF-8" when any of the header fields contain UTF-8 characters.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.127 3.128
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv2831

Modified Files:
sbbsecho.c
Log Message:
Same as previous commit, but for EchoMail this time (!).


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.128 3.129
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv30083

Modified Files:
sbbsecho.c
Log Message:
Revamp the 0-byte inbound bundle handling:
- Don't ever try to unpack a 0-byte file.
- Don't log anything or try delete if the file is < 24 hours old.
- Try to delete the file if it's >= 24 hours old (and log a msg, INFO-level).



--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.129 3.130
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv4469

Modified Files:
sbbsecho.c
Log Message:
If failure to find a .msg netmail file attachment, don't bail (immediately exit), just log the error and continue processing. Reported by wkitty42.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.130 3.131
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Add missing %s printf args.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.131 3.132
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv17560

Modified Files:
sbbsecho.c
Log Message:
Log the process-ID (PID) on the debug-level log lines: "invoked" and "exiting" Always log the "exiting" line when exiting with a non-zero error level.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.132 3.133
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv10170

Modified Files:
sbbsecho.c
Log Message:
When importing FTN TZUTC values, don't get fancy trying to convert to a US standard time-zone (e.g. -0300 == EST) as this is not accurate when daylight saving time is in effect (-0400 == EDT or AST?).


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.133 3.134
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv10866

Modified Files:
sbbsecho.c
Log Message:
Fix possible NULL-dereference in pack_netmail(), likely the problem that Alterego reported, would cause a crash if the netmail message did *not* have
a FLAGS kludge line.


--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Sun Aug 18 2019 12:04 pm

Fix possible NULL-dereference in pack_netmail(), likely the problem that Alterego reported, would cause a crash if the netmail message did *not* have a FLAGS kludge line.

Ahh, you might have found it?

I'll rebuild and try with the same message anyway...
...δεσ*

... Nursing Law: All the IV trees are at the other end of the hall.

---
■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Alterego to Digital Man on Mon Aug 19 2019 08:21 am

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Sun Aug 18 2019 12:04 pm

Fix possible NULL-dereference in pack_netmail(), likely the problem that Alterego reported, would cause a crash if the netmail message did *not* have a FLAGS kludge line.

Ahh, you might have found it?

I think so.

I'll rebuild and try with the same message anyway...

Thanks!

digital man

Synchronet "Real Fact" #37:
Synchronet's Windows Control Panel is built with Borland C++ Builder.
Norco, CA WX: 84.4°F, 46.0% humidity, 15 mph NE wind, 0.00 inches rain/24hrs --- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.134 3.135
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv28445

Modified Files:
sbbsecho.c
Log Message:
Using the new lookup_user() function for destinatino user name look-ups.

--- SBBSecho 3.08-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.136 3.137
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Beautify the "Adding sub-board" log message a bit.


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.137 3.138
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Log a notice-level msg if the configured areafile can't be opened.


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.138 3.139
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv6532

Modified Files:
sbbsecho.c
Log Message:
Don't require that the last character of the "DateTime" field of packed 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)


--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.139 3.140
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv23255

Modified Files:
sbbsecho.c
Log Message:
Revert last commit. The example packed message with the corrupted DateTime
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.



--- SBBSecho 3.09-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.142 3.143
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27640

Modified Files:
sbbsecho.c
Log Message:
When exporting NetMail from data/mail.* to netmail/*.msg, map the SMB
aux/net attributes to FidoNet msg header attributes:
- CRASH
- FILEREQUEST (FREQ)
- RECEIPTREQ (RRREQ)

This should fix the FREQ netmail issue reported by Richard Williamson (RICHARDF). Thanks for the bug report!


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.143 3.144
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv15382

Modified Files:
sbbsecho.c
Log Message:
Attempt to re-create outbound directories in mutex (.bsy) file lock loop, just in case something (e.g. Argus mailer) deleted it while we were waiting our
turn to use it. As reported by Alterego (ALTERANT)


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.144 3.145
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv398

Modified Files:
sbbsecho.c
Log Message:
More loop prevention: check a message's PATH in addition-to its SEEN-BYs in 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.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.145 3.146
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv3751

Modified Files:
sbbsecho.c
Log Message:
Even more loop-prevention paranoia:
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.


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.146 3.147
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv19001

Modified Files:
sbbsecho.c
Log Message:
Enhancement for Alterego (ALTERANT):
Don't ever route netmail when the destination zone/net/node matches a local
AKA (ignoring the point value).


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Sun Nov 17 2019 04:31 pm

Don't ever route netmail when the destination zone/net/node matches a local AKA (ignoring the point value).

Actually, what will happen to it?

I'm assuming if the point is defined in sbbsecho.ini, it will be packed for the
downstream point.

But what will happen otherwise? Perhaps it could be re-addressed to the sysop of the AKA, so that they are aware?
...δεσ*

... When two Englishmen meet their first talk is of the weather.

---
■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Alterego to Digital Man on Mon Nov 18 2019 12:27 pm

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Sun Nov 17 2019 04:31 pm

Don't ever route netmail when the destination zone/net/node matches a local AKA (ignoring the point value).

Actually, what will happen to it?

Normal processing, just not routed.

I'm assuming if the point is defined in sbbsecho.ini, it will be packed for the downstream point.

Yup.

But what will happen otherwise? Perhaps it could be re-addressed to the sysop of the AKA, so that they are aware?

I don't follow.

digital man

This Is Spinal Tap quote #44:
It really, it does disturb me, but i'll rise above it; I'm a professional. Norco, CA WX: 75.1°F, 18.0% humidity, 0 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Digital Man to Alterego on Sun Nov 17 2019 07:02 pm

But what will happen otherwise? Perhaps it could be re-addressed to
the sysop of the AKA, so that they are aware?

I don't follow.

What will happen to the incoming netmail where the point doesnt exist.

IE: Somebody sends a netmail to 1:2/3.4 - and .4 is not configured in sbbsecho.ini, will:
* The netmail still packed up into the outbound for when a .4 does eventually connect, or
* The netmail will be discard
* The packet will be renamed ".bad"...

?

I'm wanting to know what will happen to the netmail and how will the sysop of 1:2/3 know about an incoming netmail destined for a point that has not been configured.
...δεσ*

... I think sex is better than logic, but I can't prove it.

---
■ Synchronet ■ Alterant | an SBBS in Docker on Pi!
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Alterego to Digital Man on Mon Nov 18 2019 02:17 pm

Re: src/sbbs3/sbbsecho.c
By: Digital Man to Alterego on Sun Nov 17 2019 07:02 pm

But what will happen otherwise? Perhaps it could be re-addressed to
the sysop of the AKA, so that they are aware?

I don't follow.

What will happen to the incoming netmail where the point doesnt exist.

IE: Somebody sends a netmail to 1:2/3.4 - and .4 is not configured in sbbsecho.ini, will:
* The netmail still packed up into the outbound for when a .4 does eventually connect, or
* The netmail will be discard
* The packet will be renamed ".bad"...

?

I'm wanting to know what will happen to the netmail and how will the sysop of 1:2/3 know about an incoming netmail destined for a point that has not been configured.

The change I made was in pack_netmail(), so the netmail message would still be packed for the destination node, just as if there was no "route" entry matching
its address. If the ".4" node ever does connect, it should get the packet with the netmail inside.

digital man

Synchronet "Real Fact" #83:
Donations to the Synchronet project are welcome @ http://wiki.synchro.net/donate
Norco, CA WX: 70.3°F, 21.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.147 3.148
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Update to previous commit: always read/use the destination node config,
(e.g. for Hold status) even if/when it's a point off of us.


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.149 3.150
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Log any error reading message header when exporting NetMail (from SMB to *.msg).


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.150 3.151
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Fix bug introduced in rev 1.236 (April-3-2014):
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).


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.151 3.152
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1945

Modified Files:
sbbsecho.c
Log Message:
Move debug log message ("NOT EXPORTING previously-rescanned message from: <addr>")
to before the actual export, so that if an area has no downlinks, you won't actually see this errorneous but harmless log message. Also include the "export-to" address in the message.


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.152 3.153
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv25668

Modified Files:
sbbsecho.c
Log Message:
Include the echo Title (from an echolist), if found, in the echostats.ini.
This makes this file more suitable for import into SCFG->Message Areas (something I'll work on soon), i.e. as an alternative to importing badareas.lst

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.153 3.154
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv5966

Modified Files:
sbbsecho.c
Log Message:
When writing badareas.lst, don't space-pad the areatags needlessly:
calculate the longest tag first, then use that value for the padding.


--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.154 3.155
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv9012

Modified Files:
sbbsecho.c
Log Message:
Reduce unnecessary padding of AreaTags in AreaFix responses.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.156 3.157
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv29346

Modified Files:
sbbsecho.c
Log Message:
Added some debug and error level log output to help Angel Ripoll figure out
why his messages aren't being exported to packets.
Don't increment the per-area-export counter when write_to_pkts() returns false.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.157 3.158
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27213

Modified Files:
sbbsecho.c
Log Message:
Modify a single log message, the new "Added <area> message from x to packets": Track and log the packet-export exceptions (link packets that were *not* exported-to) and detail those exceptions (number of seen-bys, paths, origin address, etc.) which were triggered.
This requires latest xpdev/str_list.*

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.158 3.159
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv27706

Modified Files:
sbbsecho.c
Log Message:
Make use of strListIsEmpty() - optimization.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.159 3.160
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv6003

Modified Files:
sbbsecho.c
Log Message:
Remove attributes CRASH, HOLD, and LOCAL from the headers of netmail messages be unpacked into stored messages (.msg). Debug-level log message indicating that one or more attributes were removed (and which ones, in hex).
This set of stripped attribute flags could easily be configurable, if that turns out to be desirable.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.160 3.161
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv31899

Modified Files:
sbbsecho.c
Log Message:
Fix bug reported by Mark Lewis (Rampage@SESTAR), when packing NetMail messages (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.

--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.162 3.163
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
Fix bug in previous commit, 0-initialize the usernumber so that messages imported for robots actually have a 'to' index value of 0.


--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.164 3.165
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3

Modified Files:
sbbsecho.c
Log Message:
An extra debug-level log message when exporting a netmail from SMB.
Don't add another tear-line (---) if one already exists, when creating
netmail (.msg) stored messages.


--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.165 3.166
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv29169

Modified Files:
sbbsecho.c
Log Message:
MKDIR -> mkpath

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.166 3.167
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1773

Modified Files:
sbbsecho.c
Log Message:
When exporting netmail from SMB->.msg, always set the "SENT" net-attribute
and clear the "IN-TRANSIT" net-attribute of the original message, even if we're flagging it for deletion (the delete attribute could always be toggled off).

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.167 3.168
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv28557

Modified Files:
sbbsecho.c
Log Message:
When import netmail for robots, don't perform duplicate message body-text checking.

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.168 3.169
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv11388

Modified Files:
sbbsecho.c
Log Message:
When importing messages into a local msgbase that contained an origin line
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.

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.169 3.170
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv20270

Modified Files:
sbbsecho.c
Log Message:
Remove unnecessary typecasts.

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Wed Apr 29 2020 21:34:37

Modified Files:
sbbsecho.c
Log Message:
When importing messages into a local msgbase that contained an origin
line 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.

i'm glad you found this! i had thought to go rummaging through the code looking
to see if there was such in place but the TODO list is quite long... i've been noticing a difference in the formatting of posts when compared to how they arrive via QWK and when they're gated to FTN... i'm curious to see if they're now more similar or exact to the QWK arrivals when seen on the FTN side... they
should be, now, with this forced 80 column formatting removed :)


)\/(ark

---
■ Synchronet ■ The SouthEast Star Mail HUB - SESTAR
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/sbbs3/sbbsecho.c
By: Rampage to digital man on Thu Apr 30 2020 07:56 am

Re: src/sbbs3/sbbsecho.c
By: rswindell to CVS commit on Wed Apr 29 2020 21:34:37

Modified Files:
sbbsecho.c
Log Message:
When importing messages into a local msgbase that contained an origin line 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.

i'm glad you found this!

If someone had asked, I would have said that SBBSecho did not do that.

i had thought to go rummaging through the code
looking to see if there was such in place but the TODO list is quite long... i've been noticing a difference in the formatting of posts when compared to how they arrive via QWK and when they're gated to FTN... i'm curious to see if they're now more similar or exact to the QWK arrivals when seen on the FTN side... they should be, now, with this forced 80 column formatting removed :)

Cool, let me know what you find.

digital man

Synchronet "Real Fact" #45:
Synchronet External "Plain Old Telephone System" support was introduced in 2007.
Norco, CA WX: 73.9°F, 69.0% humidity, 0 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.170 3.171
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv14414

Modified Files:
sbbsecho.c
Log Message:
Always delete exported netmail if there's no SENDEREXT (from_ext) as this could
result in orphaned sent-mail otherwise.

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.171 3.172
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv23694

Modified Files:
sbbsecho.c
Log Message:
Resolve weird Clang warning: format specifies type 'unsigned short' but the argument has type 'int'

So a (ushort&ushort) == int? That makes no sense.When in doubt, typecast!

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.172 3.173
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv953

Modified Files:
sbbsecho.c
Log Message:
Fix issue reported by Alterego:
Don't auto-add sub-boards to the area file if the echotag is already in the area file (but marked as pass-through or associated with a different sub-board already). This configuration could result in the same sub-board(s) being auto-added to the area file for every invocation of sbbsecho.

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.173 3.174
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv22900

Modified Files:
sbbsecho.c
Log Message:
If an export netmail message has MSGID/REPLY header fields, add those as kludges (needed for including message-IDs in exported netmail).

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.174 3.175
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1776

Modified Files:
sbbsecho.c
Log Message:
Extra log level message (INFO, WARNING, and DEBUG) when moving netamil file attachments (attached files) - for debugging the issue reported by
alterego (ALTERANT)

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

src/sbbs3 sbbsecho.c 3.175 3.176
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv10832

Modified Files:
sbbsecho.c
Log Message:
import_netmail(): Safer string handline and a bit more/consistent log output around attached file handling (especially if mv() fails).

--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/57afc83c4a58a1a7f6af05ee
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Signal the sub-board's configured semaphore file when importing echomailAt the request of alterego (ALTERANT), if a sub-board has a "post semaphore"configured, signal (touch) it whenever a message is imported via SBBSecho intothat sub-board.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/ddba8d7cec9cd0367d7e0480
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix previous commit: we need to use mycmdstr(), not cmdstr().
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/da486a78c63293a86718c78d
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Don't attempt to parse origin addr from origin lines in NetMail msgsApparently,
some versions or configurations of Mystic BBS will include anOrigin Line in FTN
NetMail messages. That would've been okay for SBBSecho,except these origin lines do not contain an FTN address (in parenthesis).So, firstly: when importing NetMail messages (subnum=INVALID_SUB), don'tattempt to parse any Origin Lines. Secondly, fix up the Origin Line parsecode a bit better detect the case when no FTN address is actually present.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/6380257eb617c61048195583
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Support forwarding FTN netmail to user's forward-to netmail addressThere's no new opt-in option for this new feature - maybe there should be.For geneb.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/796c3db7d2e5fdb81b1c4dff
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
A better check of a user's netmail-forwarding address.is_supported_netmail_addr() actually takes the system configuration and
QWK routing table into account. No sense forwarding to a non-deliverable address.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/efbb1b5d5577a05515f1f6e5
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Revert "A better check of a user's netmail-forwarding address."This reverts commit 796c3db7d2e5fdb81b1c4dff884e15d66718063c.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/sbbs/sbbs/-/commit/cbda86ec8738498c14ae87fb
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix netmail forwarding (new feature)The recipient net-addr/type was always being over-ridden a bit further down in the code. Don't do that.Also, log a message (sbbsecho.log) indicating that a message was forwarded ("Forwarding message ...").For geneb.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/a1e127841841087fb51e1c32
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Don't repeate mail "comment" headers in exported netmail msgssmb_getmsgtxt() returns any "comment" headers as part of the message body text, and has since 2003.When I added mail->netmail (stored message) export support to SBBSecho v3,
I duplicated this logic, so comment headers were added *twice* to exported netmail messages. Oops. I didn't notice until today when playing with forwarding-to-netmail (FTN).Also noticed and fixed: any comment headers in posted messages (unlikely/uncommon) would not be exported to EchoMail messages.
Use the correct smb_getmsgtxt() mode flags ("NO_TAILS" instead of "BODY_ONLY") - I know, not great names.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/c590c437c7dee6de8531217b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Use QWKnet ID of originating system when imported via QWKnetUpdate to previous commit.
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/53d3103177986398c19564a3
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
When replying to PING netmails, use the destination addr as the origaddrAs tested and reported in FIDONEWS by Michiel van der Vlist, 2:280/5555, SBBSecho would use the "best match" FidoNet AKA for the originating address when replying to PING netmail messages and not necessarily the original destination address of the ping request. For systems that have multiple addresses (AKAs) that could be considered appropriate originating addresses for the requesting node address (e.g. multiple addresses in the same zone or zone/net), this could
cause a confusion for the PING requester.The create_netmail() function now accepts an optional source (orig) address parameter and the PING response logic
passes the netmail's destination address for the reply message's originating (source) address.I noticed that AreaMgr responses also follow the same logic as
PING responses (just use the best-fit AKA, not necessarily the same address as the original request's destination address) - but I did not choose to address that "issue" at this time.
--- SBBSecho 3.12-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/a9967b46fc2be2e0d08efb49
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix memcmp() usage problem introduced in previous commitCaught by GCC.
--- SBBSecho 3.13-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/a1bead7cc4e295514a5c1b18
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Eliminate a large pass-struct-by-valueCaught by Coverity.
--- SBBSecho 3.13-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/160606e4ce35305a55819266
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Print error and return NULL from getfmsg() upon ftell errorCaught by Coverity -
ftell[o] can return negative.
--- SBBSecho 3.13-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f3e4a6e498c8c206e087da88
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Use SAFECAT() instead of strcat() for more safety.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/1031d0f6e01686c5a8dda583
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Replace tempnam() usage with the suggested mkstemp()Since we're cleaning up warnings... this will break the Windows build for now.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/0f262d8ab2a6bd870adbb428
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Don't allow downlinks (AreaFix add) of our "Unknown echoes" sub-boardIt was recently pointed out to me that a downlink could link to the '*' echo via Area Manager (AreaFix) request. This was not intentional.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/7f0390149d84d79a3b7bfb10
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Keep the same area file (areas.bbs) mode flags (permissions)When executing area
manager requests that alter the area file, the temp areafile created (with mkstemp) had mode 0600 (owner read/write only). The sysopvery possibly had different permission flags they want to keep for their areafile, so copy the mode flags from the original area file to the temp/new areafile.
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/9a8c8e6d414c2bfe503aa841
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Microsoft doesn't have fchmod(), so use chmod() on the closed file
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/ccc0e4019838ce4021c16b0e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
When packing netmail (stored messages), don't discard non-zero zonesAs reported
by Ragnarok (DOCKSUD) via DOVE-Net, when packing (packetizing) netmail messages, the source and destination zones from the netmail header were discarded (since they are defined as "optional" in FTS-1) and the zone values were replaced with the system's primary/default zone number. If the netmail message included an INTL kludge, the source and destination zone values would be parsed from that kludge line and this issue would not be noticed. So the fix
is: Only if the netmail message header contains a source or destination zone number of 0, replace that zone with the system's primary/default zone number. As before, the INTL kludge zone information can override the header fields.Also, there's no reason to force the point numbers from the header to zero, since if they were not valid (e.g. "fill" in the original FTS-1 specification), they would be already zero. So use the source and destination point numbers, as is, from the netmail header too (with the FMPT and TOPT kludge override support left in-tact).
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/5012efb1eb3d2d20289a01c1
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log an error and exit immediately when a local linked-node is configuredWhen a linked-node (in echocfg->Linked Nodes) contains one of the local system's FTN addresses, display/log an error and exit immediately, e.g.:Configuration ERROR:
Linked node #20 is your own address: 1:103/705I'd perform this check in EchoCfg, but:1. echocfg doesn't read the BBS's configuration files (where the local FTN addresses are configured), and2. some sysops just directly edit their
sbbsecho.ini file
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e10b39d1aee183a16a3d9458
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Generate a MSGID kludge for netmail messages created by SBBSechoThe "serialno" field is a bad/naive one (a time_t value), but this is really just an experiment for Ragnarok to see if this fixes issue #306 (with hotdoged receiving AreaFix responses/notices).
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/27dfa4f6b9ebc59e1c4f097e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve gcc warningwarning: format ΓÇÿ%lxΓÇÖ expects argument of type ΓÇÿlong unsigned intΓÇÖ
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/55962a410034e3633fe3ff09
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Disable libarchive support for creating/appending bundleslibarchive apparently cannot be used for in-place modification of (e.g. adding files to) existing archives, so if a bundle already exists, this code would over-write it with a new archive containing just the latest packet. Issue reported by acn (IMZADI) via DOVE-Net.I could and might create an update_archive() function which extracts and re-creates an archive with additional files, but since I don't have that yet, just disable this for now and always use an external archive utility to create or update bundles (so again, an "Archive" configuration is required in your sbbsecho.ini file, which you most likely already have).
--- SBBSecho 3.14-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/4ec5647c783a5f5af9d68611
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve some Coverity-discovered issueswith lseek() argument types, ftell() return type, etc.Likely none of these would be actual issues with files < 2GiB in size.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f9a681ac286284fe57f7f5c2
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix possible negative offset to fseeko()CID 350353
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/c4b6a79d6f3a6b217cb87a1b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add subject.can (Subject filter file) supportFor Trikester (DOVEMOD/BSMNTQQ) --- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e530a12cf6268ef9ab47f36c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix CID 174355: Big parameter passed by value
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/726223ee8d8a7dde927fc833
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
For sub-boards configured to export "ASCII Only", convert UTF-8 correctlyThis converts the body text as well as the to, from, and subject headerfields (first
to CP437, then to ASCII).This should address the issue raised in issue #386 with exporting UTF-8sequences to some message networks.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/bf3da76e32fbc8cd7785fa1f
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve GCC warningsFixes isue #388 - no change in behavior
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 4/3/22 16:51, Rob Swindell wrote:

https://gitlab.synchro.net/main/sbbs/-/commit/726223ee8d8a7dde927fc833 Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
For sub-boards configured to export "ASCII Only", convert UTF-8 correctly

This converts the body text as well as the to, from, and subject header fields (first to CP437, then to ASCII).

This should address the issue raised in issue #386 with exporting UTF-8 sequences to some message networks.

Maybe adding a "CP437/DOS Only" option? Not sure what the underlying
value is though.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
￭ Synchronet ￭ Roughneck BBS - roughneckbbs.com
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/414d34ec8bc2c13601ce476a
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix packet filename in "Gruned message" log entry on Win32e.g. "Grunged message
(type 2) from 4:80/1 at offset 58 in packet: (null)"off_t is 64-bit, but long in 32-bit (on Win32), so needs a typecast here inlprintf() call (otherwise, the
upper 4 bytes of the offset are interpretedas the string address for the corresponding '%s' argument, the filename).
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/2962e4a5bf733e4b0c3869c4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix segfault when printing Bad-echo name after failing to load cfgThis is a weird one: sbbsecho ran right as I was saving msgs.cnf viaSCFG and it seems like it loaded 0-byte msgs.cnf into memory and thissegfault was a result of trying to print sub[INVALID_SUB]->code.The use of [f]nopen() with proper share perms should have prevented this(truncated msgs.cnf read) from happening, so there's something else afoot here.
--- SBBSecho 3.15-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/6fb20b919003c805a40c207c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve signed/unsigned compare warning with MSVC
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/ccfad124e104b09bf825392e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
More consistent 'exact' parameter values to findnodecfg() - e.g. false, not 0No
functional change.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/15b230af547ff5932c6073e5
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Rework NetMail routing logic to handle point destinations betterWith this commmit, the logic is now:If the NetMail destination is a point and there's no linked-node for it and the boss node for this point is not one of our AKAs then route to the boss node (no linked-node match needed) if the boss node matches a linked-node with a route configuration then route to that configured route destination (2-levels of routing and thus 2 "Routing NetMail" msgs will be logged in this scenario)If the NetMail destination is a point and there is a linked-node for it then the netmail will not be routed unless that linked node has a route configurationNetMail destined for non-points are treated the same as before thiscommit.No change in the routing of echomail for points.I think this change fixes issue #520 which can be traced back to commit45ced2a3b for poindexter FORTRAN (REALITY), 2 years ago almost to theday, where that change added point->boss routing, but only if the bosshad a matching linked-node configuration (for both echomail andnetmail).This commit also re-thinks commit ffe69b43623d (for Alterego) whichwould not route a point netmail if any our local AKAs matched thedestination address, igorining the point value. I think what wasintended here (I coudln't locate the original enhancmenet request orissue), was to not route if a local AKA was the *boss* of the point.And with this commit, that's now how it now works.As before, "test results appreciated".
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

To: Rob Swindell (on ChromeOS)
@MSGID: <63F18D47.12151.dove.sync_c@realitycheckbbs.org>
@REPLY: <63F13C32.46548.syncprog@vert.synchro.net>
@TZ: 41e0
Re: src/sbbs3/sbbsecho.c
By: Rob Swindell (on ChromeOS) to Git commit to main/sbbs/master on Sat Feb 18 2023 12:59 pm

As before, "test results appreciated".

Thanks for doing this. I'm relying on the nightlies, so I'll download them tomorrow and test.
---
■ Synchronet ■ .: realitycheckbbs.org :: scientia potentia est :.
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/227e2f4986eb0b04c05cc6ea
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Stop classifying msgs for unknown areas as security violationsWhen Secure EchoMail is enabled and a Bad Echo Area (*) is defined in thearea file (areas.bbs), but the packet source address is *not* listed as alink to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknownareas in such a packet
would cause the pkt to be considered a bad packetwith a security violation. Instead, the message should just be skipped.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/b185201161cd35dea8273d84
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Strip the "in-transit" attribute flag from imported packed-messagesLog a warning message when either the "local" or "in-transit" flag has beenstripped from ("Sanitized") imported packed-messages.Keyop reported a chksmb warning on a FidoNet message that contained the'in-transit' attribute:<Keyop> Message flagged as 'In Transit' (?): 1<Keyop> fidonet_fidosoft Message Base has Errors!The message in question appears just to be a corrupted echomail msg comingfrom HPT:Sender '56:43 'To Tommi KoivulaSubject
testX-FTN-AREA FIDOSOFT.HUSKYX-FTN-TID hpt/os2-wc 1.9.0-cur
2021-03-14SBBSecho didn't use to convert/import the "in-transit" flag on importednetmail or echomail messages, ... until commit 446ab0ef7e09e5c61cf, whichwas needed to support the TickFix robot. So now, let's just sanitize thepacked-message attributes a little sooner in the import process and log awarning when such sanitization has taken place.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/d6eadf369e7ed75248b1819c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Truncate trailing whitespace from FidoNet message header fieldsIt's unclear whether trailing whitespace is supposed to be significant or not(FidoNet specs don't say), but I don't see any reason why "John Doe" and"John Doe " should be considered unique senders or recipients. Remove anytrailing whitespace from message subjects too.This change makes the trailing whitespace truncation in SMB hash functionsunnecessary (at least for SBBSecho-imported messages), but most (all?) othermessage transports don't allow for this nonsense in the first place.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/e76fafaae4580941b343253b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix type 2.2 packet header generationAs reported by Deon on DOVE-Net: type 2.2 packet generation was not (sinceSBBSecho v3.0) setting the origin and destination point values correctly:was leaving the packet type 2.0 date values in these fields.Also, zero-out the reserved bytes in the type 2.2 packet header
(don't leavethe type 2.0 date values in there).Thanks for the report Deon!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/68df9812f31add3f94430d77
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Always delete the AREASxxxxxx temp fileWhen there are no changes (areas added or removed) via an areafix message, thedata/AREASxxxxxx temp file would be left
behind. The file was only removed ifareas were added or removed from the area file via areafix message.The orphaned data/AREASxxxxxxx files were reported via
DOVE-Net by Gamgee (PALANTIR)If you have these stale files, you can safely delete them.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/f9b0dda5a1cac371a50f9f3f
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add more detail (e.g. line number) to various "error opening" log msgsSome of the errors could be pretty vague since they looked the same andwe were depending on the path/file attempted to be opened in the log msgto clue us into
what exactly was being attempted. But some of these filepaths are sysop-configurable, and they can put unexpected things in therethat make it difficult to determine exactly what file was trying to beopened and for what purpose. This should help a little bit.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/43fb687f2e138e183f841a42
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix issue when packing netmails for multiple different linked-nodes

Introduced in commit 15b230af (9 months ago), the first linked-node config (including packet password!) for the first packed netmail message would be reused for subsequent packed netmail messages.

Thank you to Wilfred van Velzen (2:280/464) for reporting this problem!

Additional debug-level log message when using a packet password for a newly created packet.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/28e435bdc2e909f38032afd4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Combine the "new packet" and "password-protected" debug-log lines

... to de-clutter the log

Also, don't log the packet passwords. Folks copy and post sbbsecho.log lines and that could seriously compromise the security of the Interwebs if those super-secret passwords were ever leaked!
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/fc9d641054b36d9a84cc87da
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix typo in previous commit
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/6e1118af6abf0c55ca608a29
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Don't use wildcard node packet password (if one exists)

This also addresses the addresses with 65535 in them in the new debug-level
log messages "New packet (type x) created for linked-node" .
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/c2f663c30ab71c7493babab4
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Log message attributes in human-readable form (not just hexadecimal)
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/623613492036f9806c225436
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Expand sole-LFs in message text (shouldn't normally be there)

Expanded to CRLF or just CR (if strip LFs is enabled).

It is possible for someone to stuff LF-terminated text in a message, so let's account for that possibility upon export to FTNs where LFs are supposed to be ignored.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/20aecd3a4d979af82e3f509b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix more warnings...

It looks like we may need a set of PRI?TIME macros for printf()ing
a time_t.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/9b28769f4b669763409f0435
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Bugfix: actually use the SMB netattr 'HOLD' attribute flag

... when exporting from SMB to .msg ("stored message") file
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/4c7a908f8ee55161faf3be71
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Insure buf is null-terminated in getzpt(), resoving CID 488308
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/5a2a73ae1b20ddf3563c23fe
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix typo in previous commit to this file
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)