-
src/sbbs3/js_msgbase.c
From
rswindell@VERT to
CVS commit on Sat Apr 4 15:07:05 2020
src/sbbs3 js_msgbase.c 1.256 1.257
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv1155
Modified Files:
js_msgbase.c
Log Message:
Bug: a get_mg_header() followed by a put_msg_header() would add a header field (SMTPREVERSEPATH a.k.a. "reverse_path") if it didn't already have one.
That's because smb_getmsghdr() will point the msg.reverse_path convenience pointer to the from_net_addr if there was no explicit reverse-path (e.g. RFC822's
"return-path" header field). This could manifest itself in *any* change to a message header via JS failing with an "illegal header length increase" error if the added header field just happen to put the total header length over the allocation threshold of the pre-existing msg header.
Fix: only model a msg header "reverse_path" property if the header field actually existed (not based on the SMBLIB convenience pointer).
When the expand_fields option is used, the old behavior remains but expanded headers cannot be written back to the base, so no harm there.
Reported by Coz in #synchronet from failed runs of scrubmsgs.js. Thanks!
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Sun Apr 5 22:18:01 2020
src/sbbs3 js_msgbase.c 1.257 1.258
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv9320
Modified Files:
js_msgbase.c
Log Message:
MsgBase.open() would not, could not, actually create a message base.
It would create 3 0-byte files (*.shd, *.sdt, *.sid), but more is actually needed for a message base to be "created" (i.e. a call to smb_create()).
So, MsgBase.open() now uses smb_open_sub() rather than smb_open() to initialize theSMB status fields with the proper default values (based on the sysop configuration) and calls smb_crate() if the header file is empty.
Yes, normally, SCFG creates message bases, but it shouldn't have to
(e.g. a fresh install on *nix, doesn't actually start with any files in data/subs) and now that we have JavaScript-based message lister/readers, we really needed this support.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Thu Apr 23 22:08:03 2020
src/sbbs3 js_msgbase.c 1.259 1.260
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv8971
Modified Files:
js_msgbase.c
Log Message:
The RECIPIENTLIST header field would get removed (converted to an RFC822TO header field) when saving a message using the MsgBase class.
A similar problem existed with REPLYTOLIST/RFC822REPLYTO, but was not actually observed.
Since the following header fields were not populated in the msg header "field_list", if they existed in a message header that was modified using
the MsgBase class, they would be lost:
- RFC822TO
- RFC822CC
- RFC822ORG
- RFC822REPLYTO
- RFC822SUBJECT
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Thu May 7 12:29:10 2020
src/sbbs3 js_msgbase.c 1.260 1.261
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/tmp/cvs-serv3023
Modified Files:
js_msgbase.c
Log Message:
Allow an added or modified message header to have to/from/reply-to "net type" values of NET_NONE. This is a weird scenario, but it is technically possible (e.g. for nntpservice.js) to save a message with a to/from/treply-to "net address" header, but an associated net-type of NET_NONE. By saving the net-type NET_NONE, when saving a modified header, if the associated net address header field value cannot be parsed into a valid network address, there won't be any error reported, e.g.
Error -110 adding SENDERNETADDR field to message header
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
rswindell@VERT to
CVS commit on Thu May 7 14:58:38 2020
src/sbbs3 js_msgbase.c 1.261 1.262
Update of /cvsroot/sbbs/src/sbbs3
In directory cvs:/home/rswindell/sbbs/src/sbbs3
Modified Files:
js_msgbase.c
Log Message:
Populate the *_net_type fields, even when set to NET_NONE (0), when the corresponding *_net_addr field is present (not NULL).
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Rob Swindell@VERT to
Git commit to sbbs/master on Sun Nov 22 00:14:40 2020
-
From
Rob Swindell@VERT to
Git commit to main/sbbs/master on Sat May 22 21:44:37 2021
-
From
Rob Swindell@VERT to
Git commit to main/sbbs/master on Sat Jul 10 22:58:26 2021
https://gitlab.synchro.net/main/sbbs/-/commit/e53c5926508c739c27c4d67c
Modified Files:
src/sbbs3/js_msgbase.c
Log Message:
Ignore the PRIVATE message attribute for the "mail" base
When setting the value of a message's 'can_read' property, ignore the PRIVATE message attribute (which is sometimes set in FTN netmail messages) since it's assumed all messages in the mail base are private, no special destination (to) name matching is needed here.
This only popped up recently via msglist.js because of the recent addition of checking each messages's 'can_read' property.
As reported by <Diehard> via IRC PM.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Rob Swindell (on Windows 11)@VERT to
Git commit to main/sbbs/master on Thu Aug 8 12:38:17 2024
https://gitlab.synchro.net/main/sbbs/-/commit/8fc08f0db09c8c8203657580
Modified Files:
src/sbbs3/js_msgbase.c
Log Message:
Fix CID 508260: Null pointer dereference
And really, more importantly, the msg header field_list array length would always be interpretted as 0-length!
... introduced in commit 54523145
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
-
From
Rob Swindell (on Windows 11)@VERT to
Git commit to main/sbbs/master on Wed Nov 13 19:49:03 2024
https://gitlab.synchro.net/main/sbbs/-/commit/37ca25a5c73a308ae3e84006
Modified Files:
src/sbbs3/js_msgbase.c
Log Message:
Document the editor property (field) of the message header object
there are still other undocumented fields/properties, but this one for sure
was missing.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net