1033 lines
49 KiB
Plaintext
1033 lines
49 KiB
Plaintext
|
|
QWK Mail Packet File Layout
|
|
by Patrick Y. Lee
|
|
|
|
Version 1.0 - February 23, 1992
|
|
First release.
|
|
Version 1.1 - March 15, 1992
|
|
Minor fixes here and there to make everything just right.
|
|
Version 1.2 - May 31, 1992
|
|
Added a few items to the DOOR.ID file that is being supported by
|
|
Qmail DeLuxe2 version 1.25.
|
|
Version 1.3 - July 6, 1992
|
|
Added changes to the QWK format adopted by Qmail door. Specifi-
|
|
cally line 10 of CONTROL.DAT file and bytes 126-127 of MESSAG-
|
|
ES.DAT file. Please refer to the appropriate section for the
|
|
changes.
|
|
Version 1.4 - July 18, 1992
|
|
Fixed a few minor mistakes in the documentation (thanks to Cody
|
|
Gibson). Nothing really major. Also completed the Netmail sec-
|
|
tion of the documentation.
|
|
Version 1.5 - July 30, 1992
|
|
Added off-line commands for Cam-Mail door. Fixed error in the
|
|
status flag section. The descriptions for `*' and `+' are incor-
|
|
rect. Thanks to Bob Blaylock for bringing this up.
|
|
|
|
This document is Copyright 1992 by Patrick Y. Lee.
|
|
The QWK-format is Copyright 1987 by Sparkware.
|
|
|
|
All program names mentioned in this document are either Copyright or
|
|
Trademark of respective owners.
|
|
|
|
The author provides this file as-is without warranty of any kind,
|
|
either expressed or implied. You are using the information in this
|
|
file at your own discretion. The author assumes no responsibilities
|
|
for damages, either physically or financially, from the use of this
|
|
information.
|
|
|
|
This document may be freely distributed by any means (electronically,
|
|
paper, etc.), provided that it is distributed in its entirety. Por-
|
|
tions of this document may be reproduced without credit.
|
|
|
|
The latest version of this file can always be found on Aardvark BBS
|
|
(New York, NY) at (212) 496-8324 with an USR HST DS/v.32bis modem. It
|
|
can also be found in the Lunatic Fringe BBS (Plano, TX) at (214) 422-
|
|
2936 USR HST DS. First time caller can download on both boards.
|
|
|
|
Table of Contents
|
|
|
|
1. Introduction
|
|
1.1. Intent
|
|
1.2. History
|
|
1.3. Questions, corrections, etc.
|
|
2. Conventions & overview
|
|
2.1. The BBS ID
|
|
2.2. Packet compression
|
|
2.3. Packet transfer & protocols
|
|
2.4. Limitations
|
|
3. QWK files
|
|
3.1. Naming convention
|
|
3.2. Control file (CONTROL.DAT)
|
|
3.3. Welcome file
|
|
3.4. Goodbye file
|
|
3.5. News file
|
|
3.6. Qmail DeLuxe2 menu file
|
|
3.7. New uploads listing (NEWFILES.DAT)
|
|
3.8. Bulletin file(s) (BLT-x.y)
|
|
3.9. Message file (MESSAGES.DAT)
|
|
3.10. Index files (*.NDX)
|
|
3.10.1. Conference indices
|
|
3.10.2. Personal index (PERSONAL.NDX)
|
|
3.11. Pointer file
|
|
3.12. SESSION.TXT
|
|
4. REP files
|
|
4.1. Naming convention
|
|
4.2. Message file (BBSID.MSG)
|
|
4.3. Door control messages
|
|
4.3.1. DOOR.ID file
|
|
4.3.2. Qmail
|
|
4.3.3. MarkMail
|
|
4.3.4. KMail
|
|
4.3.5. RoseMail
|
|
4.3.6. Complete Mail Door
|
|
4.3.7. The MainMail System
|
|
4.3.8. BGQWK
|
|
4.3.9. UltraBBS
|
|
4.3.10. TriMail
|
|
4.3.11. Cam-Mail
|
|
4.4. Turning off the echo flag
|
|
4.5. Tag-lines
|
|
5. Net mail
|
|
A. Credits & contributions
|
|
B. Sample Turbo Pascal and C code
|
|
C. Sample message
|
|
D. Sample index file
|
|
|
|
To search for a specific section, look for "[x.x]" using your editor
|
|
or viewer. For example, to jump to the tag-lines portion of this
|
|
file, search for "[4.5]" with your editor or text viewer.
|
|
|
|
[1] Introduction
|
|
|
|
[1.1] Intent
|
|
|
|
This document is written to facilitate programmers who want to write
|
|
QWK-format mail doors or readers. It is intended to be a comprehen-
|
|
sive reference covering all areas of QWK-format mail processing.
|
|
Detailed break down of each file is included, as are implementation
|
|
information. In addition, door and reader specific information may be
|
|
included, when such information are available to me.
|
|
|
|
[1.2] History
|
|
|
|
The QWK-format was invented by Mark "Sparky" Herring in 1987. It was
|
|
based on Clark Development Corporation's PCBoard version 12.0 message
|
|
base format. Off-line mail reading has become popular only in recent
|
|
years. Prior to summer of 1990, there were only two QWK-format off-
|
|
line mail reader programs. They were Qmail DeLuxe by Mark Herring and
|
|
EZ-Reader by Eric Cockrell. Similarly for the doors, there were only
|
|
two -- Qmail by Mark Herring and MarkMail by Mark Turner. They were
|
|
both for PCBoard systems.
|
|
|
|
A lot has changed in both off-line reader and mail door markets since
|
|
summer 1990. Now, there are more than a dozen off-line mail readers
|
|
for the PC. Readers for the Macintosh, Amiga, and Atari exist as
|
|
well. There are over a half dozen doors for PCBoard, and QWK-format
|
|
doors exist for virtually all of the popular BBS softwares. All of
|
|
these happened in less than two years! More readers and doors are in
|
|
development as I write this, keep up the excellent work. In addition
|
|
to doors, some BBS softwares has QWK-format mail facility built in.
|
|
|
|
Off-line mail reading is an integral part of BBS calling. Conference
|
|
traffic and selection on all networks have grown dramatically in re-
|
|
cent years that on-line reading is a thing of the past. Off-line mail
|
|
reading offers an alternative to reading mail on-line -- It offers
|
|
speed that cannot be achieved with on-line mail reading.
|
|
|
|
The reason why QWK-format readers and doors seem to have gained popu-
|
|
larity is probably dued to its openness. The format is readily avail-
|
|
able to any programmer who wishes to write a program that utilize it.
|
|
Proprietary is a thing of the past, it does not work! Openness is
|
|
here to stay and QWK-format is a part of it.
|
|
|
|
[1.3] Questions, corrections, etc.
|
|
|
|
Most of the message networks today have a conference/echo devoted to
|
|
discussion of off-line readers and mail doors. The ones I know are on
|
|
FidoNet, ILink, Intelec, and RIME. If you have questions after read-
|
|
ing anything in here, feel free to drop by any of the above conference
|
|
/echo and I am sure other QWK authors will try to help.
|
|
|
|
I can be reached at:
|
|
|
|
CompuServe: >INTERNET:p.lee@green.cooper.edu
|
|
FidoNet: Off-line echo
|
|
ILink: Off-line, Shareware conferences
|
|
Intelec: Off-line conference
|
|
Internet: p.lee@green.cooper.edu
|
|
PlanoNet: Reviews conference
|
|
RIME: ->RUNNINGB, Off-line, Common, Net Admin., Shareware, New Users,
|
|
Turbo Pascal, and Session Manager conferences
|
|
|
|
Any corrections, extensions, comments, and criticisms are welcomed.
|
|
Messages from Internet and RIME will probably be answered first. But
|
|
I do check mail on all other places at least once a week.
|
|
|
|
[2] Conventions & overview
|
|
|
|
All offsets referenced in this document will be relative to 1. I am
|
|
not a computer, I start counting at one, not zero!
|
|
|
|
Words which are enclosed in quotes should be entered as-is. The quota-
|
|
tions are not part of the string unless noted.
|
|
|
|
You may have noticed I use the phrase "mail program" or "mail facili-
|
|
ty" instead of mail doors. This is because some BBS softwares offer
|
|
the option of creating QWK-format mail packets right from the BBS.
|
|
With those, there is no need for an external mail door.
|
|
|
|
[2.1] The BBS ID
|
|
|
|
The BBS ID (denoted as BBSID) is a 1-8 characters word that identifies
|
|
a particular BBS. This identifier should be obtained from line 5 of
|
|
the CONTROL.DAT file (see section 3.2.1).
|
|
|
|
[2.2] Packet compression
|
|
|
|
Most mail packets are compressed when created by the mail door in
|
|
order to save download time and disk space. However, many off-line
|
|
reader programs allow the user to unarchive a mail packet outside of
|
|
the reader program, so the reader will not have to unarchive it. Upon
|
|
exit, the reader will not call the archiver to save it. It is up to
|
|
the user to archive the replies. This is useful if the user has limit-
|
|
ed memory and cannot shell out to DOS to run the unarchive program.
|
|
For readers based on non-PC equipment, the user may be using less
|
|
common compression program that does not have command line equivalent.
|
|
|
|
[2.3] Packet transfer & protocols
|
|
|
|
There is no set rule on what transfer protocol should be used. Howev-
|
|
er, it would be nice for the mail program on the BBS to provide the
|
|
Sysop with options as to what to offer. This should be a configura-
|
|
tion option for the user.
|
|
|
|
[2.4] Specifications & limitations
|
|
|
|
There aren't many known limits in the QWK specification. However,
|
|
various networks seem to impose artificial limits. On many of the PC-
|
|
based networks, 99-lines appears to be the upper limit for some soft-
|
|
wares. However, most of the readers can handle more than that. Read-
|
|
er authors reading this may want to offer the option to split replies
|
|
into n lines each (the actual length should be user definable so when
|
|
the network software permits, the user can increase this number).
|
|
|
|
[3] QWK files
|
|
|
|
[3.1] Naming convention
|
|
|
|
Generally, the name of the mail packet is BBSID.QWK. However, this
|
|
does not have to be the case. When the user downloads more than one
|
|
mail packet at one time, either the mail program or the transfer pro-
|
|
tocol program will rename the second and subsequent mail packets to
|
|
other names. They will either change the file extension or add a
|
|
number to the end of the filename. In either case, you should not
|
|
rely on the name of the QWK file as the BBSID. The BBSID, as men-
|
|
tioned before, should be obtained from line 5 of the CONTROL.DAT file.
|
|
In addition, mail packets do not have to end with QWK extension ei-
|
|
ther. The user may choose to name them with other file extensions.
|
|
|
|
[3.2] Control file (CONTROL.DAT)
|
|
|
|
The CONTROL.DAT file is a simple ASCII file. Each line is terminated
|
|
with a carriage return and line feed combination. All lines should
|
|
start on the first column.
|
|
|
|
Line #
|
|
1 My BBS BBS name
|
|
2 New York, NY BBS city and state
|
|
3 212-555-1212 BBS phone number
|
|
4 John Doe, Sysop BBS Sysop name
|
|
5 20052,MYBBS Mail door registration #, BBSID
|
|
6 01-01-1991,23:59:59 Mail packet creation time
|
|
7 JANE DOE User name (upper case)
|
|
8 Name of menu for Qmail, blank if none
|
|
9 0 ? Seem to be always zero
|
|
10 999 Total number of messages in packet
|
|
11 121 Total number of conference minus 1
|
|
12 0 1st conf. number
|
|
13 Main Board 1st conf. name (13 characters or less)
|
|
14 1 2nd conf. number
|
|
15 General 2nd conf. name
|
|
.. 3 etc. onward until it hits max. conf.
|
|
.. 123 Last conf. number
|
|
.. Amiga_I Last conf. name
|
|
.. HELLO Welcome screen file
|
|
.. NEWS BBS news file
|
|
.. SCRIPT0 Log off screen
|
|
|
|
Some mail doors, such as MarkMail, will send additional information
|
|
about the user from here on.
|
|
|
|
0 ?
|
|
25 Number of lines that follow this one
|
|
JANE DOE User name in uppercase
|
|
Jane User first name in mixed case
|
|
NEW YORK, NY User city information
|
|
718 555-1212 User data phone number
|
|
718 555-1212 User home phone number
|
|
108 Security level
|
|
00-00-00 Expiration date
|
|
01-01-91 Last log on date
|
|
23:59 Last log on time
|
|
999 Log on count
|
|
0 Current conference number on the BBS
|
|
0 Total KB downloaded
|
|
999 Download count
|
|
0 Total KB uploaded
|
|
999 Upload count
|
|
999 Minutes per day
|
|
999 Minutes remaining today
|
|
999 Minutes used this call
|
|
32767 Max. download KB per day
|
|
32767 Remaining KB today
|
|
0 KB downloaded today
|
|
23:59 Current time on BBS
|
|
01-01-91 Current date on BBS
|
|
My BBS BBS network tag-line
|
|
0 ?
|
|
|
|
Some mail doors will offer the option of sending an abbreviated confer-
|
|
ence list. That means the list will contain only conferences the user
|
|
has selected. This is done because some mail readers cannot handle
|
|
more than n conferences at this time. Users using those readers will
|
|
need this option if the BBS they call have too many conferences.
|
|
|
|
[3.3] Welcome file
|
|
|
|
This file usually contains the log on screen from the BBS. The exact
|
|
filename is specified in the CONTROL.DAT file, after the conference
|
|
list. This file may be in any format the Sysop chooses it be -- usu-
|
|
ally either in plain ASCII or with ANSI screen control code. Some
|
|
Sysops (notably PCBoard Sysops) may use BBS-specific color change code
|
|
in this file as well. Current mail programs seem to handle the trans-
|
|
lations between BBS-specific code to ANSI based screen control codes.
|
|
|
|
Even if the CONTROL.DAT file contains the filename of this file, it
|
|
may not actually exist in the mail packet. Sometimes, users will
|
|
manually delete this file before entering the mail reader. Some off-
|
|
line readers offer the option to not display this welcome screen; some
|
|
will display this file regardless. Some doors, similarly, will offer
|
|
option to the user to not send this file.
|
|
|
|
[3.4] Goodbye file
|
|
|
|
Similar to the welcome file above, the filename to the goodbye file is
|
|
in the CONTROL.DAT file. This is the file the BBS displays when the
|
|
user logs off the board. It is optional, as always, to send this file
|
|
or to display it.
|
|
|
|
[3.5] News file
|
|
|
|
Many mail doors offer the option to send the news file from the BBS.
|
|
Most will only send this when it has been updated. Like the welcome
|
|
and goodbye files, the filename to the news file is found in the CON-
|
|
TROL.DAT file. It can be in any format the Sysop chooses, but usually
|
|
in either ASCII or ANSI. Like the welcome screen, current mail facili-
|
|
ties seem to handle translation between BBS-specific control codes to
|
|
ANSI screen control codes.
|
|
|
|
[3.6] Qmail DeLuxe2 menu file
|
|
|
|
This file is of use only for Qmail DeLuxe2 mail reader by Sparkware.
|
|
The filename is found on line 8 of the CONTROL.DAT file.
|
|
|
|
[3.7] New uploads listing (NEWFILES.DAT)
|
|
|
|
Most mail programs on the BBS will offer the option to scan new files
|
|
uploaded to the BBS. The result is found in a file named
|
|
NEWFILES.DAT. The mail program, if implementing this, should update
|
|
the last file scan field in the user's profile, if there is such a
|
|
field, as well as other information required by the BBS. The mail
|
|
program should, of course, scan new files only in those areas the user
|
|
is allowed access.
|
|
|
|
[3.8] Bulletin files (BLT-x.y)
|
|
|
|
Most mail programs will also offer the option to include updated bulle-
|
|
tin files found on the BBS in the mail packet. The bulletins are
|
|
named BLT-x.y, where x is the conference/echo the bulletin came from,
|
|
and y the bulletin's actual number. The mail program will have to
|
|
take care of updating the last read date on the bulletins in the user
|
|
record.
|
|
|
|
[3.9] Message file (MESSAGES.DAT)
|
|
|
|
The MESSAGES.DAT file is the most important. This is where all of the
|
|
messages are contained in. The QWK file format is based on PCBoard
|
|
12.0 message base format from Clark Development Corporation (maker of
|
|
PCBoard BBS software).
|
|
|
|
The file has a logical record length of 128-bytes. The first record
|
|
of MESSAGES.DAT always contain a copyright notice saying "Produced by
|
|
Qmail...Copyright (c) 1987 by Sparkware. All Rights Reserved". The
|
|
rest of the record is space filled. Actual messages consist of a 128-
|
|
bytes header, plus one or more 128-bytes block with the message text.
|
|
Actual messages start in record 2. The header block is layed out as
|
|
follows:
|
|
|
|
Offset Length Description
|
|
------ ------ ----------------------------------------------------
|
|
1 1 Message status flag (unsigned character)
|
|
' ' = public, unread
|
|
'-' = public, read
|
|
'*' = private, read by someone but not by intended
|
|
recipient
|
|
'+' = private, read by official recipient
|
|
'~' = comment to Sysop, unread
|
|
'`' = comment to Sysop, read
|
|
'%' = sender password protected, unread
|
|
'^' = sender password protected, read
|
|
'!' = group password protected, unread
|
|
'#' = group password protected, read
|
|
'$' = group password protected to all
|
|
2 7 Message number (in ASCII)
|
|
9 8 Date (mm-dd-yy, in ASCII)
|
|
17 5 Time (24 hour hh:mm, in ASCII)
|
|
22 25 To (uppercase, left justified)
|
|
47 25 From (uppercase, left justified)
|
|
72 25 Subject of message (mixed case)
|
|
97 12 Password (space filled)
|
|
109 8 Reference message number (in ASCII)
|
|
117 6 Number of 128-bytes blocks in message (including the
|
|
header, in ASCII; the lowest value should be 2, header
|
|
plus one block message; this number may not be left
|
|
flushed within the field)
|
|
123 1 Flag (ASCII 225 means message is active; ASCII 226
|
|
means this message is to be killed)
|
|
124 2 Conference number (unsigned word)
|
|
126 2 Logical message number in the current packet; i.e.
|
|
this number will be 1 for the first message, 2 for the
|
|
second, and so on. (unsigned word)
|
|
128 1 Indicates whether the message has a network tag-line
|
|
or not. A value of '*' indicates that a network tag-
|
|
line is present; a value of ' ' (space) indicates
|
|
there isn't one. Messages sent to readers (non-net-
|
|
status) generally leave this as a space. Only network
|
|
softwares need this information.
|
|
|
|
Fields such as To, From, Subject, Message #, Reference #, and the like
|
|
are space padded if they are shorter than the field's length.
|
|
|
|
The message text starts in the next record. You can find out how many
|
|
blocks make up one message by looking at the value of "Number of 128
|
|
byte blocks". Instead of carriage return and line feed combination,
|
|
each line in the message end with an ASCII 227 (pi character) symbol.
|
|
There are reports that some (buggy) readers have problems with messag-
|
|
es which do not end the last line in the message with an ASCII 227.
|
|
If a message does not completely occupy the 128-bytes block, the re-
|
|
mainder of the block is padded with space or null.
|
|
|
|
Note that there seems to exist old doors which will use one byte to
|
|
represent the conference number and pad the other one with an ASCII 32
|
|
character. The program reading this information will have to deter-
|
|
mine whether the ASCII 32 in byte 125 of the header is a filler or
|
|
part of the unsigned word. One method is to look in the CONTROL.DAT
|
|
file to determine the highest conference number.
|
|
|
|
Even though most mail programs will generate MESSAGES.DAT files that
|
|
appear in conference order, this is not always the case. Tomcat!
|
|
(mail door for Wildcat! BBS) generates MESSAGES.DAT that is not in
|
|
conference order. This is due to how Wildcat! itself stores mail on
|
|
the BBS. Another known system that behaves this way is Auntie, which
|
|
has its mail door QWiKer.
|
|
|
|
Note that some mail doors offer the option of sending a mail packet
|
|
even though there may be no messages to send -- thus an empty
|
|
MESSAGES.DAT file. This was tested with Qmail 4.0 door and it sent a
|
|
MESSAGES.DAT file that contains a few empty 128-bytes blocks. Other
|
|
mail doors seem to be able to produce QWK files without the MESSAG-
|
|
ES.DAT file at all! Apparently, there was no standard established in
|
|
this procedure.
|
|
|
|
[3.10] Index files (*.NDX)
|
|
|
|
[3.10.1] Conference indices
|
|
|
|
The index files contain a list of pointers pointing to the beginning
|
|
of messages in the MESSAGES.DAT file. The pointer is in terms of the
|
|
128-bytes block logical record that the MESSAGES.DAT file is in. Each
|
|
conference has its own xxx.NDX file, where xxx is the conference num-
|
|
ber left padded with zeroes. Some mail programs offer the user the
|
|
option to not generate index files. So the mail readers need to cre-
|
|
ate the index files if they are missing.
|
|
|
|
EZ-Reader 1.xx versions will convert the NDX files from Microsoft MKS
|
|
format into IEEE long integer format. The bad part about this is that
|
|
the user may store those index files back into the QWK file. When
|
|
another reader reads the index files, it will be very confused!
|
|
|
|
Special note for BBSes with more than 999 conferences: Index files for
|
|
conferences with four digit conference numbers is named xxxx.NDX,
|
|
where xxxx is the conference number (left padded with zeroes). The
|
|
filenames for three digit conferences are still named xxx.NDX on these
|
|
boards. I would assume filenames for conferences in the five digit
|
|
range is xxxxx.NDX, but I have not seen a BBS with 10,000 or more
|
|
conferences yet!
|
|
|
|
Each NDX file uses a five bytes logical record length and is formatted
|
|
to:
|
|
|
|
Offset Length Description
|
|
------ ------ ------------------------------------------------------
|
|
1 4 Record number pointing to corresponding message in
|
|
MESSAGES.DAT. This number is in the Microsoft MKS$
|
|
BASIC format.
|
|
5 1 Conference number of the message. This byte should
|
|
not be used because it duplicates both the filename of
|
|
the index file and the conference # in the header. It
|
|
is also one byte long, which is insufficient to handle
|
|
conferences over 255.
|
|
Please refer to appendix B for routines to deal with MKS numbers.
|
|
|
|
[3.10.2] Personal index (PERSONAL.NDX)
|
|
|
|
There is a special index file named PERSONAL.NDX. This file contains
|
|
pointers to messages which are addressed to the user, i.e. personal
|
|
messages. Some mail door and utility programs also allow the selec-
|
|
tion of other messages to be flagged as personal messages.
|
|
|
|
[3.11] Pointer file
|
|
|
|
Pointer file is generally included so that the user can reset the last
|
|
read pointers on the mail program, in case there is a crash on the BBS
|
|
or some other mishaps. There should be little reason for the reader
|
|
program to access the pointer file.
|
|
|
|
The pointer files I have seen are:
|
|
|
|
KMail BBSID.PNT
|
|
MarkMail BBSID.PNT
|
|
Qmail BBSID.PTR
|
|
QWiKer HMP.PTR
|
|
SFMailQwk BBSID.SFP
|
|
|
|
Additions to this list are welcomed.
|
|
|
|
[3.12] SESSION.TXT
|
|
|
|
This file, if included, will contain the message scanning screen the
|
|
user sees from the door.
|
|
|
|
[4] REP files
|
|
|
|
[4.1] Naming convention
|
|
|
|
The reply file is named BBSID.MSG, where BBSID is the ID code for the
|
|
BBS found on line 5 of the CONTROL.DAT file. Once this file has been
|
|
created, the mail reader can archive it up into a file with REP exten-
|
|
sion.
|
|
|
|
[4.2] Message file (BBSID.MSG)
|
|
|
|
Replies use the same format as the MESSAGES.DAT file, except that
|
|
message number field will contain the conference number instead. In
|
|
other words, the conference number will be placed in the two bytes
|
|
(binary) starting at offset 124, as well as the message number field
|
|
(ASCII) at offset 2.
|
|
|
|
A private message is indicated by '*' in the message status flag. For
|
|
some reason, most mail doors only accept '*' as a private message and
|
|
not '+'.
|
|
|
|
The first 128-bytes record of the file is the header. Instead of the
|
|
copyright notice, it contains the BBSID of the BBS. This 1-8 charac-
|
|
ter BBSID must start at the very first byte and must match what the
|
|
BBS has. The rest of the record is space padded. The replies start
|
|
at record 2. Each reply message will have a 128-bytes header, plus
|
|
one or more for the message text; followed by another header, and so
|
|
on.
|
|
The mail program must check to make sure the BBSID in the first block
|
|
of the BBSID.MSG file matches what the BBS has!
|
|
|
|
[4.3] Door control messages
|
|
|
|
These messages allow the user to change their setup on the BBS by
|
|
simply entering a message. The goal is to allow the user to be able
|
|
to control most areas of the BBS via the mail door. Different mail
|
|
doors have different capabilities. Most all of them offer the ability
|
|
to add and drop a conference, as well as reset the last read pointers
|
|
in a conference.
|
|
|
|
[4.3.1] DOOR.ID file
|
|
|
|
The DOOR.ID file was first introduced by Greg Hewgill with Tomcat!
|
|
mail door and SLMR mail reader. Since then, many other authors have
|
|
picked up this idea and use the format. This file provides the neces-
|
|
sary identifiers a reader needs to send add, drop, etc. messages to
|
|
the mail door. It tells the reader who to address the message to and
|
|
what can be put in the subject line.
|
|
|
|
DOOR = <doorname> This is the name of the door that creat-
|
|
ed the QWK packet, i.e. <doorname> =
|
|
Tomcat.
|
|
VERSION = <doorversion> This is the version number of the door
|
|
that created the packet, i.e.
|
|
<doorversion> = 2.9.
|
|
SYSTEM = <systemtype> This is the underlying BBS system type
|
|
and version, i.e. <systemtype> = Wildcat
|
|
2.55.
|
|
CONTROLNAME = <controlname> This is the name to which the reader
|
|
should send control messages, eg.
|
|
<controlname> = TOMCAT.
|
|
CONTROLTYPE = <controltype> This can be one of ADD, DROP, REQUEST,
|
|
or others. ADD and DROP are pretty
|
|
obvious (they work as in MarkMail), and
|
|
REQUEST is for use with BBS systems that
|
|
support file attachments. Try out SLMR
|
|
with CONTROLTYPE = REQUEST and use the Q
|
|
function. (This seems to be a Wildcat!
|
|
BBS feature.)
|
|
RECEIPT This flag indicates that the door/BBS is
|
|
capable of return receipts when a mes-
|
|
sage is received. If the first three
|
|
letters of the subject are RRR, then the
|
|
door should strip the RRR and set the
|
|
'return-receipt-requested' flag on the
|
|
corresponding message.
|
|
MIXEDCASE = YES If this line is found then the reader
|
|
will let you use upper and lower case
|
|
names and subjects. This is first found
|
|
in Qmail DeLuxe2 1.25 version. Most
|
|
other QWK readers permit the use of
|
|
mixed case subject lines but force the
|
|
names to upper case only.
|
|
FIDOTAG = YES If this line is found then the reader
|
|
will automatically use FidoNet compliant
|
|
tag-lines.
|
|
|
|
None of the lines are actually required and they may appear in any
|
|
order. Of course, you would need a CONTROLNAME if you have any
|
|
CONTROLTYPE lines.
|
|
|
|
[4.3.2] Qmail
|
|
|
|
Send a message addressed to "QMAIL" with a subject of "CONFIG". Then,
|
|
enter any of the commands listed below inside the text of your mes-
|
|
sage. Remember to use one command per line.
|
|
|
|
ADD <confnum> Add a conference into the Qmail Door scanning
|
|
list. "YOURS" can also be added to the com-
|
|
mand if the user wishes to receive messages
|
|
only addressed them. i.e. "ADD 1 YOURS"
|
|
DROP <confnum> Drop a conference from the Qmail Door scan-
|
|
ning list.
|
|
RESET <confnum> <value> Resets a conference to a particular value.
|
|
The user can use "HIGH-xxx" to set the con-
|
|
ference to the highest message in the base.
|
|
CITY <value> Changes the "city" field in the user's
|
|
PCBoard entry.
|
|
PASSWORD <value> Changes the user's login password.
|
|
BPHONE <value> Business/data phone number
|
|
HPHONE <value> Home/voice phone number
|
|
PCBEXPERT <on|off> Turns the PCBoard expert mode ON or OFF.
|
|
PCBPROT <value> PCBoard file transfer protocol (A-Z).
|
|
PAGELEN <value> Set page length inside PCBoard.
|
|
PCBCOMMENT <value> Set user maintained comment.
|
|
AUTOSTART <value> Qmail Door autostart command.
|
|
PROTOCOL <value> Qmail Door file transfer protocol (A-Z).
|
|
EXPERT <ON or OFF> Turns the Qmail Door expert mode ON or OFF.
|
|
MAXSIZE <value> Maximum size of the user's .QWK packet (in
|
|
bytes)
|
|
MAXNUMBER <value> Maximum number of messages per conference.
|
|
|
|
[4.3.3] MarkMail
|
|
|
|
Send a message addressed to "MARKMAIL" with the subject line saying:
|
|
|
|
ADD [value] in the conference you want to add
|
|
DROP in the conference you want to drop
|
|
YOUR [value] in the conference you want only your mail sent
|
|
YA [value] in the conference you want only your mail + mail
|
|
addressed to "ALL"
|
|
FILES ON or OFF in any conference to tell MarkMail whether to scan
|
|
for new files or not.
|
|
BLTS ON or OFF to turn on and off, respectively, of receiving
|
|
bulletins.
|
|
OWN ON or OFF to turn on and off, respectively, of receiving
|
|
messages you sent
|
|
DELUXE ON or OFF to turn on and off, respectively, of receiving
|
|
DeLuxe menu
|
|
LIMIT <size> to set the maximum size of MESSAGES.DAT file can
|
|
be, it cannot exceed what the Sysop has set up
|
|
|
|
An optional number can be added onto the commands "ADD", "YOUR", and
|
|
"YA". If this number is positive, then it will be treated as an abso-
|
|
lute message number. MarkMail will set your last read pointer to that
|
|
number. If it is negative, MarkMail will set your last read pointer
|
|
to the highest minus that number. For example: "ADD -50" will add the
|
|
conference and set the last read pointer to the highest in the confer-
|
|
ence minus 50.
|
|
|
|
[4.3.4] KMail
|
|
|
|
Send a private message addressed to "KMAIL" in the conference that you
|
|
want to add, drop, or reset. The commands are "ADD", "DROP", and
|
|
"RESET #", respectively. The "#" is the message number you want your
|
|
last read pointer in the conference be set to.
|
|
|
|
[4.3.5] RoseMail
|
|
|
|
The RoseMail door allows configuration information be placed in either
|
|
the subject line or message text. The message must be addressed to
|
|
"ROSEMAIL". For only one command, it can be placed in the subject
|
|
line. For more than one changes, the subject line must say "CONFIG"
|
|
and each change be placed in the message text. Every line should be
|
|
left justified. Valid commands are:
|
|
|
|
Command Example
|
|
------------------------------------------------- ------------------
|
|
ADD <Conference> [<Message #>] [<Yours>] ADD 2 -3 Y
|
|
DROP <Conference> DROP 2
|
|
RESET <Conference> <Message #> RESET 12 5000
|
|
PCBEXPERT <ON | OFF> - PCBoard expert mode PCBEXPERT ON
|
|
EXPERT <ON | OFF> - RoseMail expert mode EXPERT OFF
|
|
PCBPROT <A - Z> - PCBoard protocol PCBPROT Z
|
|
PROT <A - Z> - RoseMail protocol PROT G
|
|
PAGELEN <Number> - Page length PAGELEN 20
|
|
MAXSIZE <Kbytes> - Max packet size in Kb MAXSIZE 100
|
|
MAXNUMBER <max msgs/conference> MAXNUMBER 100
|
|
JUMPSTART <Sequence or OFF> JUMPSTART D;Y;Q
|
|
MAXPACKET <max msgs/packet> MAXPACKET 500
|
|
AUTOSTART <Sequence or OFF> - same as jumpstart AUTOSTART OFF
|
|
OPT <##> <ON | OFF> - set door option OPT 2 OFF
|
|
|
|
[4.3.6] Complete Mail Door
|
|
|
|
Send message to "CMPMAIL", the commands are "ADD" and "DROP". This
|
|
message must be sent in the conference that you want to add or drop.
|
|
|
|
[4.3.7] The MainMail System
|
|
|
|
Send a message addressed to "MAINMAIL" with the subject line saying:
|
|
|
|
ADD [value] in the conference you want to add
|
|
DROP in the conference you want to drop
|
|
YOURS [value] in the conference you want only your mail sent
|
|
YOURS ALL [value] in the conference you want only your mail + mail
|
|
addressed to "ALL"
|
|
|
|
The optional [value] parameter functions identically to the MarkMail
|
|
door -- positive number indicates an absolute message number, negative
|
|
number will set your last read pointer that many messages from the
|
|
last message.
|
|
|
|
[4.3.8] BGQWK
|
|
|
|
The BGQWK mail door for GT Power supports file request via message.
|
|
To request a file, simply enter a message:
|
|
|
|
To: BGQWK
|
|
Subject: DL:FILENAME.EXT
|
|
|
|
The FILENAME.EXT has to be exact name, wildcard is not supported. The
|
|
message text can be left blank.
|
|
|
|
The only limit on the file request feature is your time and/or your
|
|
file ratio. The transfer of the requested file(s) will start right
|
|
after the QWK download is completed. The only exception is when the
|
|
user is using a bidirectional transfer protocol. There, the REP and
|
|
QWK are sent at the same time, hence, the file request cannot be pro-
|
|
cessed until the QWK transfer is completed.
|
|
|
|
[4.3.9] UltraBBS
|
|
|
|
Send a private message addressed to "ULTRABBS" in the conference that
|
|
you want to add, drop, or reset. The commands are "ADD", "DROP", and
|
|
"RESET #", respectively. The "#" is the message number you want your
|
|
last read pointer in the conference be set to. The QWK mail door for
|
|
UltraBBS is built in and it generates the DOOR.ID file as well.
|
|
|
|
[4.3.10] TriMail
|
|
|
|
TriMail is the QWK door for TriBBS. This door will accept off-line
|
|
configuration options sent to Qmail, MarkMail, or TriMail. This means
|
|
you can send the message to: "QMAIL", "MARKMAIL", or "TRIMAIL" in the
|
|
appropriate conference and it will work. The available options are:
|
|
|
|
BLTS ON Turn bulletin scan on
|
|
BLTS OFF Turn bulletin scan off
|
|
FILES ON Turn new files scan on
|
|
FILES OFF Turn new files scan off
|
|
RESET <value> Reset last message read pointer
|
|
DROP Drop this conference
|
|
ADD [value] Add this conference. The [value] is optional and
|
|
will set the last message read pointer.
|
|
|
|
[4.3.11] Cam-Mail
|
|
|
|
Address your message to either QMAIL or CAM-MAIL. Then enter the
|
|
command in the subject line. Valid commands are:
|
|
|
|
Add Add conferences for scanning
|
|
Bulletins On Download all new bulletins in QWK packet
|
|
Bulletins Off Turn off download of new bulletins
|
|
Color On Download the QWK packet in color, if available
|
|
Color Off Turn off download in color
|
|
Drop Drop a conference from scanning
|
|
Duplicates On Turn on duplicate checking in REP files
|
|
Duplicates Off Turn off duplicate checking
|
|
Files On Download new files list in QWK packet
|
|
Files Off Turn off download of new files list
|
|
Goodbye On Send the Goodbye files with the QWK packet
|
|
Goodbye Off Does not send the Goodbye files
|
|
Mailflags On Notifies users they have mail
|
|
Mailflags Off Does not notify users of mail
|
|
NDX On Create NDX files for QWK packet
|
|
NDX Off Does not create NDX files
|
|
Welcome On Send the Welcome file with the QWK packet
|
|
Welcome Off Does not send the Welcome file
|
|
|
|
[4.4] Turning off the echo flag
|
|
|
|
In order to send a non-echoed message (not send out to other BBSs), a
|
|
user can enter "NE:" in front of the subject line. This feature may
|
|
not be offered in all mail doors.
|
|
Some mail doors strip out the "NE:" from the subject line. However,
|
|
that leaves the recipient with nothing to tell that the message was
|
|
not echoed. Therefore, it is better if "NE:" is not stripped.
|
|
|
|
[4.5] Tag-lines
|
|
|
|
The most common format for a reader tag-line is:
|
|
|
|
* My reader v1.00 * The rest of the tag-line.
|
|
|
|
The three dashes is called a tear-line. The tag-line is appended to
|
|
the end of the message and is usually one line only. It is preferred
|
|
that tag-lines conform to this format so that networking softwares
|
|
such as QNet and RNet will not add another tearline to the message
|
|
when they process it.
|
|
|
|
Softwares on FidoNet does not like mail readers adding a tear-line of
|
|
their own, so if your mail reader offers a FidoNet mode, you will need
|
|
to get rid of the tear-line. Another item which differs between the
|
|
FidoNet and PC-based networks is that FidoNet does not like extended
|
|
ASCII characters. So your reader may want to strip high ASCII if the
|
|
user has FidoNet mode on. Acceptable tag-line style, I believe, is
|
|
just this:
|
|
|
|
* My Reader v1.00 * The rest of the tag-line.
|
|
|
|
[5] Net mail
|
|
|
|
QWK mail doors can be used along or in conjunction with QWK network
|
|
softwares to operate a network. Many such network exists. A Net-
|
|
Status packet (one that can be imported to BBS message base) is very
|
|
similar to a normal mail packet users get. The only difference is at
|
|
the end of the MESSAGES.DAT file. There, a series of 128 byte blocks
|
|
are appended to indicate Net-Status.
|
|
|
|
One byte represent one conference, in groups of 128. A non-zero value
|
|
means the user is allowed Net Mail status for that conference. The
|
|
number of Net Status blocks appended to the MESSAGES.DAT file only
|
|
needs to cover the highest conference the user has access to.
|
|
|
|
The reason these packets have to be different? Using QWK mail doors
|
|
to send and receive messages require you to be able to send messages
|
|
in other user's name as well as receive private messages in confer-
|
|
ences. The Net-Status tells the mail door to import the messages even
|
|
if they are from another name.
|
|
|
|
The only weird implementation here is that the block with the highest
|
|
conference numbers come before the lower ones. Hence, to illustrate:
|
|
|
|
Conference 128
|
|
| Conference 129
|
|
| |
|
|
vv vv
|
|
0000 00 00 FF 00 00 00 00 00-00 00 00 00 00 00 00 00 Flags for
|
|
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 conferences
|
|
0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 128-255
|
|
0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
0050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
0060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
0070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 FF 00
|
|
|
|
Conference 0
|
|
| Conference 1
|
|
| |
|
|
vv vv
|
|
0080 00 FF 00 00 00 00 00 00-00 00 00 00 00 00 00 00 Flags for
|
|
0090 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 conferences
|
|
00A0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 0-127
|
|
00B0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
00C0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
00D0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
00E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
|
|
00F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 FF
|
|
|
|
This example shows that this user has Net Status in conferences 1,
|
|
127, 130, and 254.
|
|
|
|
MarkMail and KMail doors (both for PCBoard) choos to implement things
|
|
a little differently. Instead of appending Net-Status blocks to the
|
|
end of the MESSAGES.DAT file, they simply put "MarkMail" or "Kmail..."
|
|
in the first 8 position of the file and the user is granted Net-Status
|
|
in all conferences.
|
|
|
|
-=-=-=-=-=-=-<>-=-=-=-=-=-=-
|
|
|
|
[A] Credits and Contributions
|
|
|
|
Mark "Sparky" Herring, who originated the QWK-format.
|
|
|
|
Tim Farley, who started this documentation back in the summer of 1990.
|
|
The general outline here is the work of Tim. I filled in the blanks.
|
|
|
|
Jeffery Foy, who gave us the format for Microsoft single binary versus
|
|
IEEE format.
|
|
|
|
Greg Hewgill, who (if I remember correctly) wrote the Turbo Pascal
|
|
routines (included in here) to convert between MKS and TP LongInt.
|
|
|
|
Dennis McCunney, who is the host of the Off-line conference on RIME,
|
|
is very knowledgeable in off-line reading concept and programs. His
|
|
goal is to have one reader that can read mail packet from any source.
|
|
|
|
Cody Gibson and Jeffery Foy, whose information on Net-Status packet
|
|
are included here.
|
|
|
|
All those who have been around the Off-line conferences on ILink (the
|
|
oldest of the four I participate), RIME, Fido, and Intelec, who have
|
|
provided great help over the past three years. The bulk of the infor-
|
|
mation presented here are from messages in those conferences. These
|
|
people include, but are no limited to, the followings: Dane Beko,
|
|
Joseph Carnage, Marcos Della, Joey Lizzi, Mark May, and Jim Smith.
|
|
|
|
|
|
[B] Sample Turbo Pascal and C code
|
|
|
|
Here are a few routines in Turbo Pascal and C to convert Microsoft
|
|
BASIC MKS format to usable IEEE long integer. These are collected
|
|
over the networks and there is no guarantee that they will work for
|
|
you!
|
|
|
|
Turbo Pascal (Greg Hewgill ?):
|
|
|
|
type
|
|
bsingle = array [0..3] of byte;
|
|
|
|
{ converts TP real to Microsoft 4 bytes single }
|
|
|
|
procedure real_to_msb (preal : real; var b : bsingle);
|
|
var
|
|
r : array [0 .. 5] of byte absolute preal;
|
|
begin
|
|
b [3] := r [0];
|
|
move (r [3], b [0], 3);
|
|
end; { procedure real_to_msb }
|
|
|
|
{ converts Microsoft 4 bytes single to TP real }
|
|
|
|
function msb_to_real (b : bsingle) : real;
|
|
var
|
|
preal : real;
|
|
r : array [0..5] of byte absolute preal;
|
|
begin
|
|
r [0] := b [3];
|
|
r [1] := 0;
|
|
r [2] := 0;
|
|
move (b [0], r [3], 3);
|
|
msb_to_real := preal;
|
|
end; { function msb_to_real }
|
|
|
|
Another Turbo Pascal routine to convert Microsoft single to TP LongInt
|
|
(Marcos Della):
|
|
|
|
index := ((mssingle and not $ff000000) or $00800000) shr (24 -
|
|
((mssingle shr 24) and $7f)) - 1;
|
|
|
|
C (identify yourself if you wrote this routine):
|
|
|
|
/* converts 4 bytes Microsoft MKS format to long integer */
|
|
|
|
unsigned long mbf_to_int (m1, m2, m3, exp)
|
|
unsigned int m1, m2, m3, exp;
|
|
{
|
|
return (((m1 + ((unsigned long) m2 << 8) + ((unsigned long) m3 <<
|
|
16)) | 0x800000L) >> (24 - (exp - 0x80)));
|
|
}
|
|
|
|
Microsoft binary (by Jeffery Foy):
|
|
|
|
31 - 24 23 22 - 0 <-- bit position
|
|
+-----------------+----------+
|
|
| exponent | sign | mantissa |
|
|
+----------+------+----------+
|
|
|
|
IEEE (C/Pascal/etc.):
|
|
|
|
31 30 - 23 22 - 0 <-- bit position
|
|
+----------------------------+
|
|
| sign | exponent | mantissa |
|
|
+------+----------+----------+
|
|
|
|
In both cases, the sign is one bit, the exponent is 8 bits, and the
|
|
mantissa is 23 bits. You can write your own, optimized, routine to
|
|
convert between the two formats using the above bit layout.
|
|
|
|
|
|
[C] Sample message
|
|
|
|
Here is a sample message in hex and ASCII format:
|
|
|
|
019780 20 34 32 33 32 20 20 20 30 32 2D 31 35 2D 39 32 4232 02-15-92
|
|
019790 31 33 3A 34 35 52 49 43 48 41 52 44 20 42 4C 41 13:45RICHARD BLA
|
|
0197A0 43 4B 42 55 52 4E 20 20 20 20 20 20 20 20 53 54 CKBURN ST
|
|
0197B0 45 56 45 20 43 4F 4C 45 54 54 49 20 20 20 20 20 EVE COLETTI
|
|
0197C0 20 20 20 20 20 20 20 51 45 44 49 54 20 48 41 43 QEDIT HAC
|
|
0197D0 4B 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 K
|
|
0197E0 20 20 20 20 20 20 20 20 20 20 20 20 34 30 33 36 4036
|
|
0197F0 20 20 20 20 37 20 20 20 20 20 E1 0A 01 00 00 20 7 b
|
|
019800 2A 20 49 6E 20 61 20 6D 65 73 73 61 67 65 20 64 * In a message d
|
|
019810 61 74 65 64 20 30 32 2D 30 39 2D 39 32 20 74 6F ated 02-09-92 to
|
|
019820 20 53 74 65 76 65 20 43 6F 6C 65 74 74 69 2C 20 Steve Coletti,
|
|
019830 52 69 63 68 61 72 64 20 42 6C 61 63 6B 62 75 72 Richard Blackbur
|
|
019840 6E 20 73 61 69 64 3A E3 E3 52 42 3E 53 43 20 AF n said:
|
|
|
|
RB>SC >
|
|
019850 20 65 64 69 74 6F 72 20 69 6E 20 74 68 65 20 28 editor in the (
|
|
019860 6D 61 69 6E 66 72 61 6D 65 29 20 56 4D 2F 43 4D mainframe) VM/CM
|
|
019870 53 20 70 72 6F 64 75 63 74 20 6C 69 6E 65 20 69 S product line i
|
|
[ etc. ]
|
|
019A00 6E 6F 74 20 61 20 44 6F 63 74 6F 72 2C 20 62 75 not a Doctor, bu
|
|
019A10 74 20 49 20 70 6C 61 79 20 6F 6E 65 20 61 74 20 t I play one at
|
|
019A20 74 68 65 20 48 6F 73 70 69 74 61 6C 2E E3 20 20 the Hospital.
|
|
|
|
019A30 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
|
|
019A40 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
|
|
019A50 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
|
|
019A60 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
|
|
019A70 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
|
|
019A80 E3 50 43 52 65 6C 61 79 3A 4D 4F 4F 4E 44 4F 47
|
|
PCRelay:MOONDOG
|
|
019A90 20 2D 3E 20 23 33 35 20 52 65 6C 61 79 4E 65 74 -> #35 RelayNet
|
|
019AA0 20 28 74 6D 29 E3 34 2E 31 30 20 20 20 20 20 20 (tm)
|
|
4.10
|
|
019AB0 20 20 20 20 20 20 20 20 20 48 55 42 4D 4F 4F 4E HUBMOON
|
|
019AC0 2D 4D 6F 6F 6E 44 6F 67 20 42 42 53 2C 20 42 72 -MoonDog BBS, Br
|
|
019AD0 6F 6F 6B 6C 79 6E 2C 4E 59 20 37 31 38 20 36 39 ooklyn,NY 718 69
|
|
019AE0 32 2D 32 34 39 38 E3 20 20 20 20 20 20 20 20 20 2-2498
|
|
|
|
019AF0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
|
|
|
|
[D] Sample index file
|
|
|
|
Here is a sample index file in hex format:
|
|
|
|
000000 00 00 28 87 19 00 00 30 87 19 00 00 38 87 19 00
|
|
000010 00 7E 87 19 00 00 07 88 19 00 00 0B 88 19 00 00
|
|
000020 0F 88 19 00 00 14 88 19 00 00 19 88 19 00 00 1E
|
|
000030 88 19 00 00 22 88 19 00 00 27 88 19 00 00 2C 88
|
|
000040 19 00 00 31 88 19 00 00 3B 88 19 00 00 40 88 19
|
|
000050 00 00 46 88 19 00 00 49 88 19 00 00 4D 88 19 00
|
|
000060 00 52 88 19 00 00 55 88 19 00 00 59 88 19 00 00
|
|
000070 60 88 19 00 00 66 88 19 00 00 70 88 19
|
|
|
|
This index file is for conference 25. The values for the offset are as
|
|
follows: 84, 88, 92, 127, 135, 139, 143, 148, 153, 158, 162, 167, 172, 177,
|
|
187, 192, 198, 201, 205 210, 213, 217, 224, 230, and 240.
|
|
@
|
|
|