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



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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



---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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)


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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


---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 echomail

At the request of alterego (ALTERANT), if a sub-board has a "post semaphore" configured, signal (touch) it whenever a message is imported via SBBSecho into that sub-board.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 msgs

Apparently, some versions or configurations of Mystic BBS will include an Origin 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't attempt to parse any Origin Lines. Secondly, fix up the Origin Line parse
code a bit better detect the case when no FTN address is actually present.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 address

There's no new opt-in option for this new feature - maybe there should be.
For geneb.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 msgs

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 QWKnet

Update to previous commit.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 origaddr

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/a9967b46fc2be2e0d08efb49
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix memcmp() usage problem introduced in previous commit

Caught by GCC.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/a1bead7cc4e295514a5c1b18
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Eliminate a large pass-struct-by-value

Caught by Coverity.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 error

Caught by Coverity - ftell[o] can return negative.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/f3e4a6e498c8c206e087da88
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Use SAFECAT() instead of strcat() for more safety.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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-board

It was recently pointed out to me that a downlink could link to the '*' echo via Area Manager (AreaFix) request. This was not intentional.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 area file created (with mkstemp) had mode 0600 (owner read/write only). The sysop very possibly had different permission flags they want to keep for their area file, so copy the mode flags from the original area file to the temp/new area file.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 zones

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 configured

When 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/705

I'd perform this check in EchoCfg, but:
1. echocfg doesn't read the BBS's configuration files (where the local FTN addresses are configured), and
2. some sysops just directly edit their sbbsecho.ini file

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 SBBSecho

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/27dfa4f6b9ebc59e1c4f097e
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve gcc warning

warning: format `%lx' expects argument of type `long unsigned int'

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/55962a410034e3633fe3ff09
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Disable libarchive support for creating/appending bundles

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

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c4b6a79d6f3a6b217cb87a1b
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Add subject.can (Subject filter file) support

For Trikester (DOVEMOD/BSMNTQQ)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e530a12cf6268ef9ab47f36c
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Fix CID 174355: Big parameter passed by value

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bf3da76e32fbc8cd7785fa1f
Modified Files:
src/sbbs3/sbbsecho.c
Log Message:
Resolve GCC warnings

Fixes isue #388 - no change in behavior

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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 Win32

e.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 in lprintf() call (otherwise, the upper 4 bytes of the offset are interpreted
as the string address for the corresponding '%s' argument, the filename).

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 cfg

This is a weird one: sbbsecho ran right as I was saving msgs.cnf via
SCFG and it seems like it loaded 0-byte msgs.cnf into memory and this
segfault 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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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 msgs

Some of the errors could be pretty vague since they looked the same and
we were depending on the path/file attempted to be opened in the log msg
to clue us into what exactly was being attempted. But some of these file
paths are sysop-configurable, and they can put unexpected things in there
that make it difficult to determine exactly what file was trying to be
opened and for what purpose. This should help a little bit.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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!

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net