Synchronet v3.18b-Win32 (install) has been released (Sept-2020).

Synchronet v3.19a, now under development, requires libarchive-dev to build successfully.

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ref:qwk [2019/08/16 19:32]
digital man [HEADERS.DAT] Document utf8 field
ref:qwk [2021/07/23 12:32] (current)
digital man [See Also]
Line 5: Line 5:
 ===== Packet Naming ===== ===== Packet Naming =====
  
-A QWK packet filename is normally of the form: ''//​ID//​.QWK''​ (or ''//​ID//​.qwk''​),​ where //ID// is the unique ​QWK identifier (up to 8 valid MS-DOS filename characters, starting with an alphabetic character) of the system from where the messages were downloaded (received).+A QWK packet filename is normally of the form: ''//​ID//​.QWK''​ (or ''//​ID//​.qwk''​),​ where //ID// is the unique identifier (up to 8 valid MS-DOS filename characters, starting with an alphabetic character) of the system from where the messages were downloaded (received). This //ID// is commonly referred to as the "BBS ID" or "BOARD ID" in original QWK specifications and in Synchronet, often referred to as the system "​QWK-ID"​ or "​QWKnet ID".
  
 Similarly, a QWK Reply (REP) Packet filename is normally ''//​ID//​.REP''​ (or ''//​ID//​.rep''​) where //ID// is the QWK-ID of the destination system for which the REP packet is to be sent (uploaded). Similarly, a QWK Reply (REP) Packet filename is normally ''//​ID//​.REP''​ (or ''//​ID//​.rep''​) where //ID// is the QWK-ID of the destination system for which the REP packet is to be sent (uploaded).
Line 40: Line 40:
 | ''​HEADERS.DAT'' ​     | Synchronet | Text file (in [[config:​ini_files|.ini file format]]) containing detailed header information for every message in the packet | | ''​HEADERS.DAT'' ​     | Synchronet | Text file (in [[config:​ini_files|.ini file format]]) containing detailed header information for every message in the packet |
 | ''​VOTING.DAT'' ​      | Synchronet | Text file (in [[config:​ini_files|.ini file format]]) containing voting information (polls, ballots, up/​down-votes) contained in the packet | | ''​VOTING.DAT'' ​      | Synchronet | Text file (in [[config:​ini_files|.ini file format]]) containing voting information (polls, ballots, up/​down-votes) contained in the packet |
-| ''​CONTROL.DAT'' ​     | QWK      | CRLF text file containing metadata about the system (BBS) where the messages ​cam from including the names of the conferences where public messages may have originated |+| ''​CONTROL.DAT'' ​     | QWK      | CRLF text file containing metadata about the system (BBS) where the messages ​came from including the names of the conferences where public messages may have originated |
 | ''​DOOR.ID'' ​         | QWK      | CRLF text file containing metadata about the software that created the QWK packet | | ''​DOOR.ID'' ​         | QWK      | CRLF text file containing metadata about the software that created the QWK packet |
 | ''​NETFLAGS.DAT'' ​    | QWK      | Binary file containing a 'net status'​ indicator (0x00 or 0x01) for each message conference | | ''​NETFLAGS.DAT'' ​    | QWK      | Binary file containing a 'net status'​ indicator (0x00 or 0x01) for each message conference |
Line 167: Line 167:
  
 == Character Set == == Character Set ==
-Header field values may each be up to 1024 US-ASCII characters length. When "high ASCII" characters are included in any header field values, the IBM CP437 character set is assumed unless there is an indication that the header fields are in UTF-8 format, in which case **all** header fields, for a particular message, with "high ASCII" characters must be in UTF-8 format. ​The indication of UTF-8 characters in the body text is done through ​the presence of either ​the ''​X-FTN-CHRS: UTF-8 4''​ header field or ''​Content-Type: ​text/*; charset=utf-8''​ header field.+Header field values may each be up to 1024 US-ASCII characters ​in length. When "high ASCII" characters are included in any header field values, the IBM CP437 character set is assumed unless there is an indication that the header fields are in UTF-8 format, in which case **all** header fields, for a particular message, with "high ASCII" characters must be in UTF-8 format. ​As with FidoNet messages, ​the message ​body text and header fields must share the same encoding. If the "​Utf8" ​''​HEADERS.DAT''​ header field value for message is set to "​true",​ then all the headers fields and the body text of that message are to be interpreted as though they were UTF-8 encoded.
  
 == Example == == Example ==
Line 192: Line 192:
 | Utf8           | Header fields and body text use the UTF-8 character set (when ''​true''​) rather than CP437 (the default) | | Utf8           | Header fields and body text use the UTF-8 character set (when ''​true''​) rather than CP437 (the default) |
 | Message-ID ​    | RFC822-style unique message identifier | | Message-ID ​    | RFC822-style unique message identifier |
 +| In-Reply-To ​   | RFC822-style message ID of message that this message is a reply to, if relevant |
 | WhenWritten ​   | Date/time (in ISO-8601 format) and timezone (in hexadecimal [[http://​cvs.synchro.net/​cgi-bin/​viewcvs.cgi/​src/​smblib/​smbdefs.h|SMB format]]) | | WhenWritten ​   | Date/time (in ISO-8601 format) and timezone (in hexadecimal [[http://​cvs.synchro.net/​cgi-bin/​viewcvs.cgi/​src/​smblib/​smbdefs.h|SMB format]]) |
 | WhenImported ​  | Date/​time/​zone message was imported into the originating system'​s message base | | WhenImported ​  | Date/​time/​zone message was imported into the originating system'​s message base |
Line 202: Line 203:
 | SenderProtocol | Name of protocol used by sender (e.g. "​Telnet",​ "​SSH",​ "​RLogin",​ "SMTP, "​NNTP",​ "​HTTP",​ etc.) | | SenderProtocol | Name of protocol used by sender (e.g. "​Telnet",​ "​SSH",​ "​RLogin",​ "SMTP, "​NNTP",​ "​HTTP",​ etc.) |
 | Organization ​  | Name of sender'​s organization (e.g. BBS) | | Organization ​  | Name of sender'​s organization (e.g. BBS) |
-| Reply-To ​      ​| ​Address ​to direct replies |+| Reply-To ​      ​| ​The network address ​to direct replies ​to this message ​|
 | Subject ​       | Message subject | | Subject ​       | Message subject |
 | To             | Message recipient name | | To             | Message recipient name |
Line 258: Line 259:
   - Message Ballots: contain an "​UpVote = true" or a "​DownVote = true" key/value pair   - Message Ballots: contain an "​UpVote = true" or a "​DownVote = true" key/value pair
  
-Poll ballots are to be applied to the open-poll referenced by the "​In-Reply-To"​ value. If the poll has been closed, then the ballots ​is ignored. The "​Votes"​ key value is a bit-field (normally in hexadecimal representation with "​0x"​ prefix), indicating which vote options the voter has selected (bit-0 = PollAnswer0,​ bit-1 = PollAnswer1,​ etc.).+Poll ballots are to be applied to the open-poll referenced by the "​In-Reply-To"​ value. If the poll has been closed, then the ballot ​is ignored. The "​Votes"​ key value is a bit-field (normally in hexadecimal representation with "​0x"​ prefix), indicating which vote options the voter has selected (bit-0 = PollAnswer0,​ bit-1 = PollAnswer1,​ etc.).
  
 Message ballots are simply up/​down-votes to be applied to a message'​s popularity score. The message being voted on is referenced by the "​In-Reply-To"​ message-ID value. If the referenced message doesn'​t exist, the vote is ignored. The "​Sender"​ key/value identifies the voter. Messages are never closed to new ballots, but voters should not be allowed to submit more than one ballot per message. ​ Message ballots are simply up/​down-votes to be applied to a message'​s popularity score. The message being voted on is referenced by the "​In-Reply-To"​ message-ID value. If the referenced message doesn'​t exist, the vote is ignored. The "​Sender"​ key/value identifies the voter. Messages are never closed to new ballots, but voters should not be allowed to submit more than one ballot per message. ​
 ==== NDX Files ==== ==== NDX Files ====
  
-The ''​.NDX''​ (index) files contained in QWK packets are of a notoriously bad format. These files contain byte offsets into the ''​MESSAGES.DAT''​ file, which is fine. But these offsets are stored as 32-bit real numbers in an obsolete "​Microsoft Binary Format"​. Additionally,​ each record ​contain ​a conference number, but that conference number is only 8-bit, limiting its usefulness to only 256 possible message areas.+The ''​.NDX''​ (index) files contained in QWK packets are of a notoriously bad format. These files contain byte offsets into the ''​MESSAGES.DAT''​ file, which is fine. But these offsets are stored as 32-bit real numbers in an obsolete "​Microsoft Binary Format"​. Additionally,​ each record ​contains ​a conference number, but that conference number is only 8-bits, limiting its usefulness to only 256 possible message areas.
  
-Some message ​reader ​do not require or can be configured to ignore these ''​.NDX''​ files. There is no unique information stored in the ''​.NDX''​ files, so it's entirely possible for any consumer of QWK packets to be programmed to create their own useful index information on-the-fly (e.g. the first time the packet is opened).+Some message ​readesr ​do not require or can be configured to ignore these ''​.NDX''​ files. There is no unique information stored in the ''​.NDX''​ files, so it's entirely possible for any consumer of QWK packets to be programmed to create their own useful index information on-the-fly (e.g. the first time the packet is opened).
  
-Synchronet does not parse or use ''​.NDX''​ files in any way.+Synchronet does not parse or use ''​.NDX''​ files in any way, although it can generate them (user'​s choice).
  
 ==== NETFLAGS.DAT === ==== NETFLAGS.DAT ===
Line 306: Line 307:
   * [[ftp://​vert.synchro.net/​modem.madness/​SMMOLMRS/​QWKDOCS.ZIP]]   * [[ftp://​vert.synchro.net/​modem.madness/​SMMOLMRS/​QWKDOCS.ZIP]]
   * [[ftp://​vert.synchro.net/​modem.madness/​SMMMAXIM/​MXMS_161.ZIP]]   * [[ftp://​vert.synchro.net/​modem.madness/​SMMMAXIM/​MXMS_161.ZIP]]
 +
 +==== Conference Names ====
 +
 +The message area (conference) names included in the ''​CONTROL.DAT''​ file are only used for reader information/​display purposes. The conference *numbers* are references used to identify specific message areas between the reader (or QWKnet node) and the host/hub BBS.
 +
 +=== Length ===
 +According to "QWK Mail Packet File Layout"​ (qwklay) by Patrick Y. Lee (version 1.6 - December 19, 1992), the conference names are limited to "13 characters or less".
 +
 +According to "The Mysterious QWK-File Format"​ by Jeffery Foy (April 25, 1991), the conference names are limited to "10 characters or less".
 +
 +According to "QWKE Specifications 1.02" by Peter Rocca, "​conference area names are no longer limited to 13 characters, they are limited to 255 characters now [in QWKE]"​.
  
 ===== Extended QWK (QWKE) Format ===== ===== Extended QWK (QWKE) Format =====
Line 315: Line 327:
   * [[network:​DOVE-Net]]   * [[network:​DOVE-Net]]
   * [[:​ref:​|Reference Library]]   * [[:​ref:​|Reference Library]]
 +  * [[https://​www.theregister.com/​2021/​07/​22/​qwk_swatting_death/​]]
  
 {{tag>​qwk}} {{tag>​qwk}}
  

In Other Languages