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?)
Synchronet won't care if there are fewer than the maximum number of
header fields.
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
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.
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.
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?
One other quick question,
What is the c1e0 at the end of the whenwritten field in headers.dat?
WhenWritten: 20190807093601-0700 c1e0
I'm looking to get the correct Timezone for exported messages, and figure this header is how.
If you just want the UTC offset, the ISO date/time string has it too.
If you just want the UTC offset, the ISO date/time string has it too.
I was more concerned about the messages I'm sending out to dovenet, as I logged into Freeway, and it showed my messages as being from the future
(my local time with a UTC offset - which should be +10:00)
So I was thinking I should set the WhenWritten field (and when imported/exported while at it) but will synchronet be happy with just the ISO date/time or will i need to implement that location based timezone
bit on the end too?
I'm looking at: http://wiki.synchro.net/ref:qwk
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 41:43:55 |
| Calls: | 508 |
| Messages: | 220029 |