Hi

I'm attempting to add HEADERS.DAT support to the qwk networking function
of my BBS. I've got importing from VERT working ok (I'm ignoring most of
the headers - there's lots of them!)

I'm wondering about exporting REP packets though, will synchronet mind if
I don't supply all the headers it sends (ie will it just grab what's
missing from the VERT.MSG file like it would if HEADERS.DAT is missing).
This is the headers.dat in my test rep file (with only one message)

[80]
Subject: Test with a particularly long subject
To: All
Sender: apam


Is that enough?

I'm also working on adding the Message-ID and In-Reply-To fields, but I'm unsure of the accepted format. Can those fields be anything (I'm thinking
maybe I could reuse my message id code from FTN) or is does it need to be
a specific format? (I mean I'm guessing In-Reply-To is the "Message-ID"
of the message it's in reply to, but what about the Message-ID?)

Thanks,
Andrew


---
* MagickaBBS * The Fat Sandwich - sandwich.hopto.org:2023
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: HEADERS.DAT
By: apam to All on Wed Oct 31 2018 08:34 am

Hi

I'm attempting to add HEADERS.DAT support to the qwk networking function
of my BBS. I've got importing from VERT working ok (I'm ignoring most of
the headers - there's lots of them!)

I'm wondering about exporting REP packets though, will synchronet mind if
I don't supply all the headers it sends (ie will it just grab what's
missing from the VERT.MSG file like it would if HEADERS.DAT is missing).

Synchronet won't care if there are fewer than the maximum number of header fields.

This is the headers.dat in my test rep file (with only one message)

[80]
Subject: Test with a particularly long subject
To: All
Sender: apam

Is that enough?

Sure.

I'm also working on adding the Message-ID and In-Reply-To fields, but I'm unsure of the accepted format.

They're based on the RFC822: https://www.rfc-editor.org/rfc/rfc822.txt

Can those fields be anything (I'm thinking
maybe I could reuse my message id code from FTN) or is does it need to be
a specific format? (I mean I'm guessing In-Reply-To is the "Message-ID"
of the message it's in reply to, but what about the Message-ID?)

They can be anything, but should be unique. Due to short-comings in the FTN message-ID definition (FTS-9), I wouldn't reuse any "id code from FTN": http://wiki.synchro.net/faq:misc#ftn_msgid

digital man

Synchronet/BBS Terminology Definition #13:
CP437 = Code Page 437 (so-called IBM Extended ASCII)
Norco, CA WX: 69.2øF, 65.0% humidity, 0 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Synchronet won't care if there are fewer than the maximum number of
header fields.

Oh good, I didn't think it would, but am nervous when trying to interface
with other peoples networks. Better to be safe than sorry :)

They can be anything, but should be unique. Due to short-comings in
the FTN message-ID definition (FTS-9), I wouldn't reuse any "id code
from FTN": http://wiki.synchro.net/faq:misc#ftn_msgid

Hmm, well I attempted something but I'm not sure about it now. I have the
MSGID (which is generated from the time - or if multiple messages are
sent in the same second it's incremented by a counter and selects the
highest number) - which is what I used for FTN. Also the name of the jam
base and the address of the system.

<XXXXXXXX.jambase@sandwich.hopto.org>

where sandwich.hopto.org is the external address, jambase is the filename
of the base and XXXXXXX is the msg id. I noted in your msgids you seem to
also have the message number in the base (i think), but I'm not sure how
to do that with my setup. I'll have to think about it some more. Jam
bases could potentially be the same if they're stored in sub directories,
the default for my qwk setup is to use the qwk base number as a jam base filename.

Andrew

---
* MagickaBBS * The Fat Sandwich - sandwich.hopto.org:2023
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: RE: HEADERS.DAT
By: apam to Digital Man on Thu Nov 01 2018 01:08 am

Synchronet won't care if there are fewer than the maximum number of header fields.

Oh good, I didn't think it would, but am nervous when trying to interface with other peoples networks. Better to be safe than sorry :)

They can be anything, but should be unique. Due to short-comings in
the FTN message-ID definition (FTS-9), I wouldn't reuse any "id code from FTN": http://wiki.synchro.net/faq:misc#ftn_msgid

Hmm, well I attempted something but I'm not sure about it now. I have the MSGID (which is generated from the time - or if multiple messages are
sent in the same second it's incremented by a counter and selects the highest number) - which is what I used for FTN.

Unfortunately with FTN, you have that silly 32-bit limitation on the "serialno" field, so that is a problem (as a noted in that wiki article).

As for your method, it might be fine. Or it might have the potential to generate duplicate serialno's if you're not keeping track of the last one used or the time resolution is super-fine (not one-second intervals, ala time_t).

For Internet-standard message-IDs, use a long random number combined with the time or something (anything) that is very likely to always be unique, forever. Internet-standard message-IDs (the kind I also use internally in Synchronet/SMB and the QWK extensions) have no "serialno" concept and thus *any* amount and kind of text is valid.

digital man

Synchronet/BBS Terminology Definition #15:
CVS = Concurrent Versioning System
Norco, CA WX: 65.0øF, 25.0% humidity, 0 mph WSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

As for your method, it might be fine. Or it might have the potential
to generate duplicate serialno's if you're not keeping track of the
last one used or the time resolution is super-fine (not one-second intervals, ala time_t).

I do keep track of the last one used, and if that file is deleted it will choose the current time (and create the file). It's seconds too, at some
point the 32 bit limitation will overflow, and then count up to where it started, it would eventually create duplicates.

For Internet-standard message-IDs, use a long random number combined
with the time or something (anything) that is very likely to always
be unique, forever. Internet-standard message-IDs (the kind I also
use internally in Synchronet/SMB and the QWK extensions) have no
"serialno" concept and thus *any* amount and kind of text is valid.

If this is the case, I could use libuuid and just generate a uuid for
each message. libuuid is a bit of a black box to me, but I think it uses
time as well as other sources of uniqueness. It would look something
like:

<84949cc5-4701-4a84-895b-354c584a981b@sandwich.hopto.org>

Perhaps that would be better?

Andrew

---
* MagickaBBS * The Fat Sandwich - sandwich.hopto.org:2023
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: RE: HEADERS.DAT
By: apam to Digital Man on Thu Nov 01 2018 05:54 am

For Internet-standard message-IDs, use a long random number combined with the time or something (anything) that is very likely to always
be unique, forever. Internet-standard message-IDs (the kind I also
use internally in Synchronet/SMB and the QWK extensions) have no "serialno" concept and thus *any* amount and kind of text is valid.

If this is the case, I could use libuuid and just generate a uuid for
each message. libuuid is a bit of a black box to me, but I think it uses time as well as other sources of uniqueness. It would look something
like:

<84949cc5-4701-4a84-895b-354c584a981b@sandwich.hopto.org>

Perhaps that would be better?

Looks better at a glance. Better than just <time>@<host>.

digital man

Synchronet "Real Fact" #75:
Rob's alias "digital man" was inspired by a song on Rush's 1982 "Signals" album.
Norco, CA WX: 73.5øF, 13.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)