bbs/deb-mbse
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
b13b26fd6d
deb-mbse/lib/bluewave.h

1144 lines
65 KiB
C
Raw Normal View History

Initial revision
2001-08-17 05:46:24 +00:00
/*****************************************************************************/
/* */
/* The Blue Wave Offline Mail System Packet Structures */
/* Copyright 1990-1995 by Cutting Edge Computing. All rights reserved. */
/* Created by George Hatchew */
/* */
/* Version 3 - November 30, 1995 */
/* */
/* --------------------------------------------------------- */
/* DISTRIBUTION OF THIS FILE IS LIMITED BY THE TERMS */
/* SPECIFIED IN THE BLUE WAVE STRUCTURE DOCUMENTATION! */
/* --------------------------------------------------------- */
/* */
/* These data structures should be usable with any C compiler that */
/* supports the 1989 ANSI/ISO C language standard. They are NOT */
/* guaranteed to be usable with older compilers, which largely relied */
/* on the definition of the language as specified in Kernighan & Ritchie's */
/* _The C Programming Language (1st Edition)_. */
/* */
/*****************************************************************************/
#ifndef __BLUEWAVE_H /* An extra safeguard to prevent this header from */
#define __BLUEWAVE_H /* being included twice in the same source file */
#define PACKET_LEVEL 3 /* The current mail packet revision level, */
/* used in the "ver" field of the *.INF */
/* file header. */
/*
** This header defines the data structures for the following files in the
** official Blue Wave offline mail specification:
**
** Door: *.INF BBS and message area information
** *.MIX Quick index to *.FTI records
** *.FTI Information for all packet messages
** *.DAT Packet message text
**
** Reader: *.NET NetMail reply message information
** *.UPI Information for all other reply messages
** *.UPL Reply message information
** (alternative to *.NET and *.UPI)
** *.REQ List of files to download from BBS
** *.PDQ Offline door configuration information
** (packet version 2 and earlier)
** *.OLC Offline door configuration information
** (packet version 3 and later)
**
** Misc: *.MSG Fido-style message header
** (used *only* in the *.NET structure)
** *.XTI Extended message packet information
** (not an official part of the Blue Wave
** packet specification; is used by the Blue
** Wave reader only)
**
** The door files (plus individual files for BBS bulletins) comprise a Blue
** Wave message packet, and the reader files (plus individual files for each
** message) comprise a Blue Wave reply packet.
**
** In order to cover ALL BASES, and to be able to say that you were warned,
** *ALL* unused fields should be set to ASCII NUL (0). Any future
** implementation of reserved fields will rely on the premise that the field
** will be 0 if not implemented! The same warning follows for BITMAPPED
** fields. If a bit is not implemented or is not used, TURN IT OFF (0).
** (Clearing an entire structure can be easily accomplished via the memset()
** function. Example: "memset(&ftirec, 0, sizeof(FTI_REC))".)
*/
/*****************************************************************************/
/* >>>>>>>>>>>>>>>>>>>>>>> DATA TYPE DEFINITIONS <<<<<<<<<<<<<<<<<<<<<<<<< */
/*****************************************************************************/
/*
** The data type definitions below help make these structures a little more
** universal between environments. The 8-bit, 16-bit, and 32-bit data types
** defined below can be used as-is with virtually all MS-DOS and OS/2 C/C++
** compilers, but can be changed if necessary should your compiler define
** data types in a different fashion. (Note that the tCHAR and tINT types
** are currently not used; they are included simply for completeness.)
**
** IMPORTANT NOTE ABOUT COMPILERS AND STRUCTURES:
** All structures *must* be "packed" (i.e., the compiler MUST NOT insert
** padding bytes between structure elements in order to force elements onto
** word boundaries). The Blue Wave products expect them to be packed; if
** they aren't, you're bound to get some *very* interesting results.
*/
typedef signed char tCHAR; /* 8 bit signed values */
typedef unsigned char tBYTE; /* 8 bit unsigned values */
typedef signed short tINT; /* 16 bit signed values */
typedef unsigned short tWORD; /* 16 bit unsigned values */
First stage port to 64 bit
2005-10-11 20:49:41 +00:00
typedef int tLONG; /* 32 bit signed values */
typedef unsigned int tDWORD; /* 32 bit unsigned values */
Initial revision
2001-08-17 05:46:24 +00:00
/*****************************************************************************/
/* >>>>>>>>>>>>>>>>>>>>> DOOR DATA FILE STRUCTURES <<<<<<<<<<<<<<<<<<<<<<< */
/*****************************************************************************/
/*
** Name of file: *.INF
**
** Description: The *.INF file is the source of information for just about
** everything from the host BBS, as well as definitions for
** all of the message areas that are available to the user
** and their status (Local, EchoMail, NetMail, Read Only,
** etc.).
**
** File format: INF_HEADER { only included one time! }
** INF_AREA_INFO { repeated for as many msg bases }
** INF_AREA_INFO { as are available to the user }
** ...
*/
/* Bit-masks for INF_HEADER.UFLAGS field */
#define INF_HOTKEYS 0x0001 /* User uses "hotkeys" in door prompts */
#define INF_XPERT 0x0002 /* Short menus displayed in door */
#define INF_RES1 0x0004 /* RESERVED -- DO NOT USE! */
#define INF_GRAPHICS 0x0008 /* Enable ANSI control sequences in door */
#define INF_NOT_MY_MAIL 0x0010 /* Do not bundle mail from user */
#define INF_EXT_INFO 0x0020 /* Download extended info with messages */
/* (* VERSION 3 AND LATER ONLY *) */
#define INF_NUMERIC_EXT 0x0040 /* Use numeric extensions on packets */
/* (* VERSION 3 AND LATER ONLY *) */
/* Bit-masks for INF_HEADER.NETMAIL_FLAGS field */
#define INF_CAN_CRASH 0x0002 /* Allow Crash status */
#define INF_CAN_ATTACH 0x0010 /* Allow File Attach messages */
#define INF_CAN_KSENT 0x0080 /* Allow Kill/Sent status */
#define INF_CAN_HOLD 0x0200 /* Allow Hold status */
#define INF_CAN_IMM 0x0400 /* Allow Immediate status */
#define INF_CAN_FREQ 0x0800 /* Allow File Request messages */
#define INF_CAN_DIRECT 0x1000 /* Allow Direct status */
/* Bit-masks for INF_HEADER.CTRL_FLAGS field */
#define INF_NO_CONFIG 0x0001 /* Do not allow offline configuration */
#define INF_NO_FREQ 0x0002 /* Do not allow file requesting */
/* Values for INF_HEADER.FILE_LIST_TYPE field */
#define INF_FLIST_NONE 0 /* Door does not generate a list file */
#define INF_FLIST_TEXT 1 /* Door generates plain text list file */
#define INF_FLIST_ANSI 2 /* Door generates ANSI list file */
typedef struct /* INF_HEADER */
{
tBYTE ver; /* Packet version type (currently 2) */
tBYTE readerfiles[5][13]; /* Files to be displayed by reader */
tBYTE regnum[9]; /* User's registration number */
tBYTE mashtype; /* Currently unused (door fills with 0) */
/* Reserved for Blue Wave reader to store */
/* the compression type the packet uses. */
tBYTE loginname[43]; /* Name user types at BBS login */
tBYTE aliasname[43]; /* User's "other" name */
tBYTE password[21]; /* Password */
/* All bytes should be the actually ASCII */
/* value plus 10. Lame security, yes, */
/* but it does prevent "TYPE *.INF" from */
/* showing the password. */
tBYTE passtype; /* Password type */
/* 0=none 1=door 2=reader 3=both */
tWORD zone; /* Main network address of host BBS */
tWORD net; /* (zone:net/node.point) */
tWORD node;
tWORD point;
tBYTE sysop[41]; /* Name of SysOp of host BBS */
tWORD ctrl_flags; /* Flags to control reader capabilities */
/* (* VERSION 3 AND LATER ONLY *) */
tBYTE systemname[65]; /* Name of host BBS */
tBYTE maxfreqs; /* Max number of file requests allowed */
tWORD is_QWK; /* Whether *.INF belongs to a QWK packet */
tBYTE obsolete2[4]; /* OBSOLETE -- DO NOT USE! */
tWORD uflags; /* Bit-mapped door options/toggles */
tBYTE keywords[10][21]; /* User's entire set of door keywords */
tBYTE filters[10][21]; /* User's entire set of door filters */
tBYTE macros[3][80]; /* User's door bundling command macros */
tWORD netmail_flags; /* Bit-mapped NetMail options */
tWORD credits; /* NetMail credits */
tWORD debits; /* NetMail debits */
tBYTE can_forward; /* 0=Message forwarding not allowed */
tWORD inf_header_len; /* Size of INF_HEADER structure */
tWORD inf_areainfo_len; /* Size of INF_AREA_INFO structure */
tWORD mix_structlen; /* Size of MIX_REC structure */
tWORD fti_structlen; /* Size of FTI_REC structure */
tBYTE uses_upl_file; /* If this field is not zero, the door that */
/* created this packet can receive reply */
/* packets in the new *.UPL file format. */
/* Otherwise, the old *.UPI and *.NET */
/* files must be used. */
tBYTE from_to_len; /* The maximum length of the FROM: and TO: */
/* fields that the host BBS can support. */
/* If this value is 0 or is greater than */
/* 35, then 35 must be used (the upload */
/* file formats only allow for a maximum */
/* of 35 characters). */
tBYTE subject_len; /* The maximum length of the SUBJECT: field */
/* that the host BBS can support. If */
/* this value is 0 or is greater than 71, */
/* then 71 must be used (the upload file */
/* formats only allow for a maximum of 71 */
/* characters). */
tBYTE packet_id[9]; /* Original root name of the mail packet, */
/* as specified by the mail door. All */
/* files in the packet that are created */
/* by the mail door will use this root */
/* name, as will the reader when creating */
/* the upload files. Thus, even if the */
/* packets themselves are renamed to */
/* something completely different, the */
/* mail doors and readers will still be */
/* able to work with the proper files. */
tBYTE file_list_type; /* New file listing type */
/* (* VERSION 3 AND LATER ONLY *) */
/* Specifies the type of new file list */
/* that is generated by the door (see */
/* INF_FLIST_xxx, above). This field is */
/* intended for use with offline config. */
tBYTE auto_macro[3]; /* Auto-macro indicator flags */
/* (* VERSION 3 AND LATER ONLY *) */
/* Specifies which macros are auto macros */
/* (i.e. execute automatically after mail */
/* is scanned). */
tINT max_packet_size; /* Maximum size of uncompressed packet */
/* (* VERSION 3 AND LATER ONLY *) */
/* Specifies, in K, the maximum size of */
/* an uncompressed mail packet. A value */
/* of 0 indicates no maximum length. */
/* This field is intended for use with */
/* offline config. */
tBYTE reserved[228]; /* RESERVED FOR FUTURE USE */
/* This field MUST be filled with ASCII */
/* NUL (0x00) characters in order for */
/* future additional features to work */
/* properly! */
}
INF_HEADER;
/*
** Notes about the INF_HEADER.XXXXX_LEN fields, above:
**
** Door authors should take the few extra lines of code to fill in the
** structure lengths defined above. Doing so will make the Blue Wave data
** structures extensible and adaptable to almost any kind of file change that
** may be required in the future. The readers that use this mail packet
** format should contain code to handle a structure length that is longer or
** shorter than they expect.
**
** Reader authors need to take the time to code for possible extensions to
** this file format. If the data fields are LONGER than expected, simply do
** a seek to move to the next record, and ignore the extra information. If
** the data fields are SHORTER than expected, a simple "Please upgrade your
** reader" should suffice. <grin> However, you should never encounter a
** record size smaller than the ones defined here. Any extra information
** that is sent in the packets probably would not be crucial, and you may be
** able to continue with reading the packet anyway.
**
** It should be noted that all current Blue Wave doors set these fields to 0,
** as this extensibility was not added until recently. If the structure
** sizes are 0, the reader will assume that all records are of the sizes
** defined here. (Blue Wave readers below version 2.10 do NOT allow for
** extensible data files. Version 2.10, and all subsequent versions, WILL
** handle them properly.) DO NOT EXTEND THESE STRUCTURE FORMATS WITHOUT
** NOTIFYING CUTTING EDGE COMPUTING FIRST! If the extended information will
** benefit programs/users, it will be officially added to the packet format.
**
** The original values for the INF_HEADER.XXXXX_LEN structures are as below,
** defined as macros which you can use in your programs. Remember, if the
** value in INF_HEADER.XXXXX_LEN is 0, you must use these values instead!
*/
#define ORIGINAL_INF_HEADER_LEN 1230 /* Original *.INF header len */
#define ORIGINAL_INF_AREA_LEN 80 /* Original *.INF area rec len */
#define ORIGINAL_MIX_STRUCT_LEN 14 /* Original *.MIX record len */
#define ORIGINAL_FTI_STRUCT_LEN 186 /* Original *.FTI record len */
/*
** Below is some sample C code for reading in the variable length *.INF
** structure, which is the most "difficult" one to do. Note the sections of
** code which use the ORIGINAL_XXXXX_LEN macros; these are the sections that
** determine the proper structure length. (Comments are preceeded by "#"
** signs, since using C comment symbols would make most compilers think that
** nested comments are in use, a practice which normally is not allowed.)
**
** int read_inf_file(void)
** {
** INF_HEADER inf_header;
** INF_AREA_INFO inf_info;
** FILE *inf_file=NULL;
** tWORD record_num=0u;
** tWORD inf_header_slen, inf_area_slen;
** tLONG seek_pos=0L;
**
** inf_file = fopen("WILDBLUE.INF", "rb");
** if (inf_file == NULL)
** return 0;
**
** fread(&inf_header, sizeof(INF_HEADER), 1, inf_file);
** puts(inf_header.loginname);
** puts(inf_header.aliasname);
**
** # Test and verify the validity of the structure lengths.
**
** if (inf_header.inf_header_len < ORIGINAL_INF_HEADER_LEN)
** inf_header_slen = ORIGINAL_INF_HEADER_LEN;
** else
** inf_header_slen = inf_header.inf_header_len;
**
** if (inf_header.inf_areainfo_len < ORIGINAL_INF_AREA_LEN)
** inf_area_slen = ORIGINAL_INF_AREA_LEN;
** else
** inf_area_slen = inf_header.inf_areainfo_len;
**
** # now, move to the END of the header, since it may be longer
** # than we expect it to be. Use fseek()...
**
** fseek(inf_file, (long)inf_header_slen, SEEK_SET);
**
** record_num = 0U;
** while(fread(&inf_info, sizeof(INF_AREA_INFO), 1, inf_file))
** {
** puts(inf_info.title);
** record_num++;
**
** # we need to seek past the header, and then [record_num]
** # number of recs.
**
** seek_pos = (long)(inf_header_slen+(record_num*inf_area_slen));
** fseek(inf_file, seek_pos, SEEK_SET);
** }
**
** fclose(inf_file);
** return 1;
** }
*/
/* Bit-masks for INF_AREA_INFO.AREA_FLAGS field */
#define INF_SCANNING 0x0001 /* On=User is active for area */
#define INF_ALIAS_NAME 0x0002 /* On=Alias name, Off=Login name */
/* If ON, use INF_HEADER.ALIASNAME when */
/* addressing new mail or replies for the */
/* message area. If OFF, the reader uses */
/* the INF_HEADER.LOGINNAME for this */
/* purpose. */
#define INF_ANY_NAME 0x0004 /* On=Allow any name to be entered */
/* If ON, any name can be entered in the */
/* From: field when addressing new mail */
/* or replies for the message area. If */
/* OFF, the normal rules apply. */
#define INF_ECHO 0x0008 /* On=Network mail, Off=Local mail */
#define INF_NETMAIL 0x0010 /* On=E-mail, Off=Conference mail */
/* Refer to the chart below (the values */
/* for the NETWORK_TYPE field) for info */
/* on how these two flags should be set */
/* for message areas. */
#define INF_POST 0x0020 /* On=User can post, Off=User CANNOT post */
#define INF_NO_PRIVATE 0x0040 /* On=Private messages are NOT allowed */
#define INF_NO_PUBLIC 0x0080 /* On=Public messages are NOT allowed */
#define INF_NO_TAGLINE 0x0100 /* On=Taglines are not allowed */
#define INF_NO_HIGHBIT 0x0200 /* On=ASCII 1-127 only, Off=ASCII 1-255 */
/* If ON, only ASCII values 1 to 127 are */
/* allowed in messages. If OFF, all */
/* values from 1 to 255 are allowed. Due */
/* to the fact that ASCII value 0 is used */
/* in C as a string terminator, the value */
/* 0 should not be allowed in messages at */
/* all. */
#define INF_NOECHO 0x0400 /* On=User can prevent messages from being */
/* sent through the network */
#define INF_HASFILE 0x0800 /* On=User can attach files to messages */
#define INF_PERSONAL 0x1000 /* On=User is downloading only personal */
/* msgs in this message area. The flag */
/* INF_SCANNING also needs to be ON. */
/* (* VERSION 3 AND LATER ONLY *) */
#define INF_TO_ALL 0x2000 /* On=User is downloading messages to "All" */
/* and personal messages only in this */
/* area. The flag INF_SCANNING also */
/* needs to be ON. INF_PERSONAL should */
/* *not* be set, as this flag implies the */
/* downloading of personal messages also. */
/* (* VERSION 3 AND LATER ONLY *) */
/* Values for INF_AREA_INFO.NETWORK_TYPE field */
#define INF_NET_FIDONET 0 /* FidoNet-style E-mail and conferences */
/* Local = INF_ECHO=off, NETMAIL=off */
/* EchoMail = INF_ECHO=on, NETMAIL=off */
/* GroupMail = INF_ECHO=on, NETMAIL=off */
/* NetMail = INF_ECHO=on, NETMAIL=on */
#define INF_NET_INTERNET 1 /* Internet E-mail and Usenet newsgroups */
/* Local = INF_ECHO=off, NETMAIL=off */
/* Newsgroup = INF_ECHO=on, NETMAIL=off */
/* E-mail = INF_ECHO=on, NETMAIL=on */
typedef struct /* INF_AREA_INFO */
{
tBYTE areanum[6]; /* Area number this record corresponds to */
tBYTE echotag[21]; /* Area tag name (*.BRD name for Telegard) */
tBYTE title[50]; /* Area description/title */
tWORD area_flags; /* Bit-mapped area options */
tBYTE network_type; /* Network mail type (see above) */
}
INF_AREA_INFO;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.MIX
**
** Description: The *.MIX file is a very small file, with one record for
** every message area that was scanned. It contains the
** information to get into the *.FTI file.
**
** File format: MIX_REC { repeated for each message area scanned }
** MIX_REC
** ...
*/
typedef struct /* MIX_REC */
{
tBYTE areanum[6]; /* Area number this record corresponds to */
/* This is the ASCII representation of the */
/* actual area number shown on the host BBS. */
tWORD totmsgs; /* Total number of messages for this area */
tWORD numpers; /* Total number of personal messages in this area */
tLONG msghptr; /* Pointer to first message header in *.FTI file */
}
MIX_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.FTI
**
** Description: The *.FTI file contains the information for each message
** in the packet. Each record includes all of the
** information about the message, including the pointer to
** the actual message text in the *.DAT file.
**
** NOTE: Messages in the *.FTI file will ALWAYS be in area
** number order. That is to say, if the MIX_REC
** indicates there are 100 messages for this area,
** all 100 messages will follow in sequential order.
**
** File format: FTI_REC { repeated for as many messages }
** FTI_REC { as obtained from the host BBS }
** ...
*/
/* Bit-masks for FTI_REC.FLAGS field */
#define FTI_MSGPRIVATE 0x0001 /* Private = For addressee ONLY */
#define FTI_MSGCRASH 0x0002 /* Crash = High priority mail */
#define FTI_MSGREAD 0x0004 /* Read = Message read by addressee */
#define FTI_MSGSENT 0x0008 /* Sent = Message sent */
#define FTI_MSGFILE 0x0010 /* File Attach = Send file(s) */
#define FTI_MSGFWD 0x0020 /* Forward = Message to/from others */
#define FTI_MSGORPHAN 0x0040 /* Orphan = Message destination unknown */
#define FTI_MSGKILL 0x0080 /* Kill/Sent = Delete after sending */
#define FTI_MSGLOCAL 0x0100 /* Local = Message originated here */
#define FTI_MSGHOLD 0x0200 /* Hold = Hold for pickup, don't send */
#define FTI_MSGIMMEDIATE 0x0400 /* Immediate = Send message NOW */
#define FTI_MSGFRQ 0x0800 /* File Request = Request file(s) */
#define FTI_MSGDIRECT 0x1000 /* Direct = Send direct, no routing */
#define FTI_MSGUNUSED1 0x2000 /* */
#define FTI_MSGUNUSED2 0x4000 /* */
#define FTI_MSGURQ 0x8000 /* Update Request = Req updated file(s) */
typedef struct /* FTI_REC */
{
tBYTE from[36]; /* Person message is from */
tBYTE to[36]; /* Person message is to */
tBYTE subject[72]; /* Subject/title of message */
tBYTE date[20]; /* Origin date of message */
/* Depending on the host BBS's date storage */
/* format, the EXACT format of this field */
/* will change. Some will take all 19 bytes, */
/* others may take only 10. */
tWORD msgnum; /* Number of THIS message on BBS */
tWORD replyto; /* "This is a reply to #xx" */
/* Not used for every message. When non- */
/* zero, there is a previous message in */
/* the thread. */
tWORD replyat; /* "There is a reply at #xx" */
/* Not used for every message. When non- */
/* zero, there is a reply to this message. */
tLONG msgptr; /* Offset to start of message in *.DAT file */
/* Seek to this exact offset in the *.DAT */
/* file, then read "msglength" bytes from */
/* the file to load the entire message text. */
tLONG msglength; /* Length of message text (in bytes) */
tWORD flags; /* Bit-mapped message status flags */
tWORD orig_zone; /* Origin address of message */
/* These three fields will most likely be 0, */
/* unless the current message belongs to a */
/* NetMail message base. */
tWORD orig_net;
tWORD orig_node;
}
FTI_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.DAT
**
** Description: The *.DAT file is an unstructured file which contains the
** text of every message obtained from the host BBS.
** Valid messages begin with an ASCII space (0x20) character
** (which is NOT to be considered part of the message!)
** followed by zero or more bytes which constitute the
** message text. The pointer to the text for each message is
** stored in FTI_REC.MSGPTR, and the length of the text for
** each message is stored in FTI_REC.MSGLENGTH.
**
** File format: Unstructured
*/
/*****************************************************************************/
/* >>>>>>>>>>>>>>>>> MISCELLANEOUS DATA FILE STRUCTURES <<<<<<<<<<<<<<<<<< */
/*****************************************************************************/
/*
** Name of file: *.MSG
**
** Description: The Fido *.MSG message (named for the BBS program on which
** it originated) has become a de-facto standard among BBS
** implementations, due to the sheer number of utilities
** available that operate with *.MSG messages. It is as
** close to a universal message format as one can get in
** FidoNet (and FidoNet-style networks), and is the reason
** why it is used here (well, the *.MSG header, anyway).
**
** NOTE: Most of the fields in the FTI_REC structure (shown
** above) correspond to similar fields in MSG_REC.
** This was done deliberately, in order to make
** *.FTI file processing a little more intuitive for
** programmers. Also note that MSG_REC is only used
** by the NET_REC structure, which will soon become
** obsolete (replaced by UPL_REC).
**
** File format: MSG_REC { only included one time! }
** message text { text can be terminated by an ASCII NUL }
** { character (0x00), or by an ASCII CR, }
** { LF, NUL (0x0D 0x0A 0x00) sequence }
*/
/* Bit-masks for MSG_REC.ATTR field */
#define MSG_NET_PRIVATE 0x0001 /* Private */
#define MSG_NET_CRASH 0x0002 /* Crash mail */
#define MSG_NET_RECEIVED 0x0004 /* Received */
#define MSG_NET_SENT 0x0008 /* Sent */
#define MSG_NET_FATTACH 0x0010 /* File attached */
#define MSG_NET_INTRANSIT 0x0020 /* In-transit */
#define MSG_NET_ORPHAN 0x0040 /* Orphaned */
#define MSG_NET_KILL 0x0080 /* Kill after sending */
#define MSG_NET_LOCAL 0x0100 /* Local message */
#define MSG_NET_HOLD 0x0200 /* Hold for pickup */
#define MSG_NET_RESERVED 0x0400 /* RESERVED */
#define MSG_NET_FREQ 0x0800 /* File request */
#define MSG_NET_RREQ 0x1000 /* Return receipt request */
#define MSG_NET_RECEIPT 0x2000 /* Return receipt message */
#define MSG_NET_AREQ 0x4000 /* Audit request */
#define MSG_NET_FUREQ 0x8000 /* File update request */
typedef struct /* MSG_REC (will soon be obsolete) */
{
tBYTE from[36]; /* Person message is from */
tBYTE to[36]; /* Person message is to */
tBYTE subj[72]; /* Subject/title of message */
tBYTE date[20]; /* Creation date/time */
/* This date/time is usually in either of the */
/* Fido-sanctioned formats "DD MMM YY HH:MM:SS" */
/* or "WWW DD MMM YY HH:MM", but due to the */
/* chaotic nature of FidoNet-compatible software, */
/* this CANNOT be relied upon! */
tWORD times; /* Number of times read (fairly obsolete) */
tWORD dest; /* Destination node (of net/node) */
tWORD orig; /* Origin node (of net/node) */
tWORD cost; /* Cost of sending message (usually in US cents) */
tWORD orig_net; /* Origin net (of net/node) */
tWORD destnet; /* Destination net (of net/node) */
tLONG unused1; /* Undefined */
tLONG unused2; /* Some software (Opus and Maximus, for example) */
/* uses these fields to store the sent/received */
/* date/time as bit-packed fields, using the same */
/* format used in MS-DOS directory entries. */
tWORD reply; /* Message # that this message replies to */
tWORD attr; /* Message attributes and behavior flags */
tWORD up; /* Message # that replies to this message */
}
MSG_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.XTI
**
** Description: The *.XTI file contains extended information for each
** message in the packet. The number of records in the *.XTI
** file will always equal the number of messages in the
** packet, with each record corresponding to a record in the
** *.FTI file (i.e. record #1 in the *.XTI file corresponds
** to record #1 in the *.FTI file, and so on).
**
** NOTE: This file is currently created ONLY by the Blue
** Wave reader, and is not a part of the official
** Blue Wave packet specification; it is merely
** documented here for third party programmers to use
** if they so desire. How other readers store which
** messages have been read/replied-to/marked is left
** as an option to be implemented by the individual
** reader authors. You may use this method if you so
** desire; however, PLEASE do not name any external
** files not conforming to this specification as
** <packet-ID>.XTI, due to the fact that the Blue
** Wave reader will expect the file to be in the
** format described. If it's not in the expected
** format, things will get interesting. :-)
**
** File format: XTI_REC { repeated for as many messages }
** XTI_REC { as obtained from the host BBS }
** ...
*/
/* Bit-masks for XTI_REC.FLAGS field */
#define XTI_HAS_READ 0x01 /* Message has been read */
#define XTI_HAS_REPLIED 0x02 /* Message has been replied to */
#define XTI_IS_PERSONAL 0x04 /* Message is personal */
#define XTI_IS_TAGGED 0x08 /* Message has been 'tagged' */
#define XTI_HAS_SAVED 0x10 /* Message has been saved */
#define XTI_HAS_PRINTED 0x20 /* Message has been printed */
/* Bit-masks for XTI_REC.MARKS field */
#define XTI_MARK_SAVE 0x01 /* Message marked for saving */
#define XTI_MARK_REPLY 0x02 /* Message marked for replying */
#define XTI_MARK_PRINT 0x04 /* Message marked for printing */
#define XTI_MARK_DELETE 0x08 /* Message marked for deletion */
typedef struct /* XTI_REC */
{
tBYTE flags; /* Bit-mapped message flags */
tBYTE marks; /* Bit-mapped message markers */
}
XTI_REC;
/*****************************************************************************/
/* >>>>>>>>>>>>>>>>>>>> READER DATA FILE STRUCTURES <<<<<<<<<<<<<<<<<<<<<< */
/*****************************************************************************/
/*
** Name of file: *.NET
**
** Description: The *.NET file is created ONLY when there is NetMail to be
** sent. It contains the FULL header of the Fido-style *.MSG
** structure plus the fields defined below (which aren't part
** of the standard *.MSG structure yet required by the door).
**
** NOTE: Readers should only generate a *.NET file if
** INF_HEADER.USES_UPL_FILE is not set *AND* the
** mail packet format is version 2 or earlier.
** Doors should process *.NET files *ONLY* in cases
** where a *.UPL file is not present.
**
** File format: NET_REC { repeated for as many NetMail }
** NET_REC { messages as exist in the packet }
** ...
*/
typedef struct /* NET_REC */
{
MSG_REC msg; /* The Fido-style *.MSG header */
tBYTE fname[13]; /* Filename the message text is in */
tBYTE echotag[21]; /* NetMail area tag (*.BRD name for Telegard) */
tWORD zone; /* Destination zone (of zone:net/node.point) */
tWORD point; /* Destination point (of zone:net/node.point) */
tLONG unix_date; /* Date/time of message */
/* This Unix-style date/time value (number */
/* of seconds since 01/01/70) is converted */
/* to the date/time storage method used by */
/* the host BBS. */
}
NET_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.UPI
**
** Description: The *.UPI file contains the information for each message
** in the reply packet, as well as information on the reader
** version and registration numbers. Each record includes
** all of the information about the message.
**
** NOTE: Readers should only generate a *.UPI file if
** INF_HEADER.USES_UPL_FILE is not set *AND* the
** mail packet format is version 2 or earlier.
** Doors should process *.UPI files *ONLY* in cases
** where a *.UPL file is not present.
**
** File format: UPI_HEADER { only included one time! }
** UPI_REC { repeated for as many msg bases }
** UPI_REC { as are available to the user }
** ...
*/
typedef struct /* UPI_HEADER */
{
tBYTE regnum[9]; /* Reader registration number */
tBYTE vernum[13]; /* Reader version number */
/* All bytes should be the actually ASCII */
/* value plus 10. Lame security, yes, but it */
/* does prevent "TYPE *.UPI" from showing the */
/* version number. */
tBYTE future[33]; /* RESERVED FOR FUTURE USE */
#ifdef PAD_SIZES_EVEN
tBYTE evenpad; /* If your compiler pads structures out to even */
/* numbered sizes, define PAD_SIZES_EVEN */
/* before including this header. When the */
/* *.UPI file is written, be sure to write */
/* sizeof(UPI_HEADER) - 1 bytes, otherwise */
/* your compiler may insert an extra byte not */
/* explicitly specified here. */
#endif
}
UPI_HEADER;
/* Bit-masks for UPI_REC.FLAGS field */
#define UPI_RES1 0x01 /* RESERVED FOR FUTURE USE */
#define UPI_RES2 0x02 /* RESERVED FOR FUTURE USE */
#define UPI_RES3 0x04 /* RESERVED FOR FUTURE USE */
#define UPI_RES4 0x08 /* RESERVED FOR FUTURE USE */
#define UPI_RES5 0x10 /* RESERVED FOR FUTURE USE */
#define UPI_RES6 0x20 /* RESERVED FOR FUTURE USE */
#define UPI_PRIVATE 0x40 /* Message is PRIVATE */
#define UPI_NO_ECHO 0x80 /* Message is NOT to be echoed */
/* This feature is not yet implemented in */
/* the Blue Wave reader or doors, as none */
/* of the currently supported BBS software */
/* has support for this feature. */
typedef struct /* UPI_REC */
{
tBYTE from[36]; /* Person message is from */
tBYTE to[36]; /* Person message is to */
tBYTE subj[72]; /* Subject/title of message */
tLONG unix_date; /* Date/time of message */
/* This Unix-style date/time value (number */
/* of seconds since 01/01/70) is converted */
/* to the date/time storage method used by */
/* the host BBS. */
tBYTE fname[13]; /* Filename the message text is in */
tBYTE echotag[21]; /* Area tag name (*.BRD name for Telegard) */
tBYTE flags; /* Bit-mapped flags */
tBYTE reedit; /* INTERNAL USE ONLY! */
/* This flag is used internally by the Blue */
/* Wave reader. Doors should ignore this */
/* field during reply packet processing. */
}
UPI_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.UPL
**
** Description: The *.UPL file contains the information for each message
** in the reply packet, as well as information on the reader
** version and registration numbers. Each record includes
** all of the information about the message.
**
** NOTE: Readers should only generate a *.UPL file if
** INF_HEADER.USES_UPL_FILE is set *AND/OR* the mail
** packet format is version 3 or later. Doors should
** process *.UPL files in all cases where one is
** present.
**
** File format: UPL_HEADER { only included one time! }
** UPL_REC { repeated for as many messages }
** UPL_REC { as are included in the packet }
** ...
*/
typedef struct /* UPL_HEADER */
{
tBYTE regnum[10]; /* Reader registration number (if desired) */
tBYTE vernum[20]; /* Reader version number as a string. */
/* All bytes should be the actually ASCII */
/* value plus 10. Lame security, yes, but it */
/* does prevent "TYPE *.UPL" from showing the */
/* version number. */
/* Examples: "2.10a Beta" */
/* "2.11" */
tBYTE reader_major; /* Major version of the reader (number to the */
/* left of the decimal point) */
tBYTE reader_minor; /* Minor version of the reader (number to the */
/* right of the decimal point) */
tBYTE reader_name[80]; /* String containing name of the reader, such */
/* as "The Blue Wave Offline Mail Reader". */
/* This is provided for door programmers that */
/* wish to display the name of the reader */
/* that created the reply packet. (Filling */
/* it is mandatory but using it is optional.) */
tWORD upl_header_len; /* Size of UPL_HEADER structure */
tWORD upl_rec_len; /* Size of UPL_REC structure */
/* NOTE: Refer to the INF_HEADER section for */
/* more information on using the size */
/* fields. */
tBYTE loginname[44]; /* Name found in INF_HEADER.LOGINNAME. This is */
/* provided for door authors as a security */
/* measure to implement as they wish. */
tBYTE aliasname[44]; /* Name found in INF_HEADER.ALIASNAME */
tBYTE reader_tear[16]; /* String containing abbreviated name of the */
/* reader, such as "Blue Wave", "Q-Blue", */
/* "Wave Rider", etc. This is provided for */
/* doors programmers that wish to add to the */
/* tear line the name of the reader that */
/* created the reply packet. (Filling it is */
/* mandatory but using it is optional.) If */
/* this field is blank, the tear line to be */
/* generated is left to the discretion of the */
/* door author. */
tBYTE compress_type; /* Compression type required for mail packet */
/* The Blue Wave reader uses this internally */
/* to store the compression type required for */
/* this particular mail packet. */
tBYTE flags; /* Reader processing flags */
/* The Blue Wave reader uses this internally */
/* to store flags required for later */
/* processing. */
/* 0x01 = Was a .QWK packet. */
/* 0x02 = Host requires a *.UPI file */
tBYTE not_registered; /* Reader is not registered to user */
/* If this byte is set to a non-zero value, */
/* the Blue Wave doors will assume that the */
/* user's reader was not registered, and will */
/* place "[NR]" at the end of the tear line. */
/* Third-party doors may use this flag for */
/* the same purpose; its use is optional by */
/* mail readers (especially if you don't care */
/* whether or not "[NR]" shows up on the tear */
/* line <grin>). */
tBYTE pad[33]; /* RESERVED FOR FUTURE USE, and to pad struct */
/* out to a 'nice' 256 bytes */
}
UPL_HEADER;
/* Bit-masks for UPL_REC.MSG_ATTR field */
#define UPL_INACTIVE 0x0001 /* Message is INACTIVE */
/* Doors should NOT attempt to import this */
/* message. */
#define UPL_PRIVATE 0x0002 /* Message is PRIVATE */
#define UPL_NO_ECHO 0x0004 /* Message is NOT to be echoed */
/* This feature is not yet implemented in */
/* the Blue Wave reader or doors, as none */
/* of the currently supported BBS software */
/* has support for this feature. */
#define UPL_HAS_FILE 0x0008 /* Message has file "attached" to it */
/* It is up to the door to check the */
/* validity of this flag. If the file is */
/* contained in the mail packet, great. */
/* If not, the door should probably prompt */
/* the user to begin uploading the file */
/* after importing the messages. (Not yet */
/* implemented in the Blue Wave reader.) */
#define UPL_NETMAIL 0x0010 /* Message is network mail */
/* Indicates NetMail/E-mail message. The */
/* NETWORK_TYPE field (see below) will */
/* indicate which fields should be used */
/* for addressing the message. */
#define UPL_IS_REPLY 0x0020 /* Indicates that the message is a reply to */
/* an existing message, rather than being */
/* a completely new message. */
#define UPL_MRES7 0x0040 /* RESERVED FOR FUTURE USE */
#define UPL_MRES8 0x0080 /* RESERVED FOR FUTURE USE */
/* All of the other 8 bits of this field are */
/* also reserved for future use. This */
/* should provide for plenty of expansion */
/* for future development. */
/* Bit-masks for UPL_REC.NETMAIL_ATTR field */
#define UPL_NRES1 0x0001 /* RESERVED FOR FUTURE USE */
#define UPL_NETCRASH 0x0002 /* Crash = High priority mail */
#define UPL_NRES2 0x0004 /* RESERVED FOR FUTURE USE */
#define UPL_NRES3 0x0008 /* RESERVED FOR FUTURE USE */
#define UPL_NETFILE 0x0010 /* File Attach = Send file(s) listed */
/* in Subject field */
#define UPL_NRES4 0x0020 /* RESERVED FOR FUTURE USE */
#define UPL_NRES5 0x0040 /* RESERVED FOR FUTURE USE */
#define UPL_NETKILL 0x0080 /* Kill/Sent = Delete after sending */
#define UPL_NETLOCAL 0x0100 /* Local = Message originated here */
#define UPL_NETHOLD 0x0200 /* Hold = Hold for pickup, do not send */
#define UPL_NETIMMEDIATE 0x0400 /* Immediate = Send message NOW */
#define UPL_NETFRQ 0x0800 /* File Request = Request file(s) */
/* listed in Subject field */
#define UPL_NETDIRECT 0x1000 /* Direct = Send direct, no routing */
#define UPL_NRES6 0x2000 /* RESERVED FOR FUTURE USE */
#define UPL_NRES7 0x4000 /* RESERVED FOR FUTURE USE */
#define UPL_NETURQ 0x8000 /* Update Request = Request updated */
/* file(s) listed in Subject field */
/* Values for UPL_REC.NETWORK_TYPE field */
#define UPL_NET_FIDONET 0 /* FidoNet-style E-mail and conferences */
/* UPL_NETMAIL=off - Local, Echo, Group */
/* UPL_NETMAIL=on - NetMail */
#define UPL_NET_INTERNET 1 /* Internet E-mail and Usenet newsgroups */
/* UPL_NETMAIL=off - Local, Newsgroup */
/* UPL_NETMAIL=on - E-mail */
typedef struct /* UPL_REC */
{
tBYTE from[36]; /* Person message is from */
/* NOTE: Doors should validate this field! */
tBYTE to[36]; /* Person message is to (non-Internet) */
/* For Internet E-mail, the NET_DEST field */
/* should be used to store the destination */
/* name/address, leaving this field blank. */
/* For Usenet newsgroups, this field should be */
/* left blank, as newsgroups don't use a "To:" */
/* field. */
tBYTE subj[72]; /* Subject/Title of message */
tWORD destzone; /* Destination address (FidoNet only) */
/* If the message is not a FidoNet NetMail */
/* message, this field (and the subsequent */
/* three fields as well) should be set to */
/* zero. */
tWORD destnet;
tWORD destnode;
tWORD destpoint;
tWORD msg_attr; /* Bit-mapped message attributes */
tWORD netmail_attr; /* Bit-mapped NetMail attributes (FidoNet only) */
/* If the message is not a FidoNet NetMail */
/* message, this field should not be used. */
tLONG unix_date; /* Date/time of message */
/* This Unix-style date/time value (number */
/* of seconds since 01/01/70) is converted to */
/* the date/time storage method used by the */
/* host BBS. */
tDWORD replyto; /* This unsigned long word stores the message # */
/* that this message is a reply to. This */
/* should be the same as FTI.MSGNUM. Note, */
/* however, that FTI.MSGNUM is a word. C */
/* programmers especially will need to */
/* properly typecast the value (i.e. */
/* upl.replyto=(tDWORD)fti.msgnum). As */
/* messaging/BBS systems become more complex, */
/* FTI.MSGNUM may become obsolete, and a */
/* tDWORD variable may be used in its place. */
tBYTE filename[13]; /* Filename the message text is in */
/* If this file does not exist in the upload */
/* packet then doors should consider this an */
/* invalid record. */
tBYTE echotag[21]; /* Area tag the message goes in */
/* This must correspond exactly to the */
/* INF_AREA_INFO.ECHOTAG field for the message */
/* area this message belongs to. Simple area */
/* number matching has proven not to work */
/* simply because sysops are finicky people, */
/* and seem to constantly renumber/change the */
/* message area numbers on the host BBS. */
/* Using an echotag helps to alleviate this */
/* problem. C_ECHO will be C_ECHO on the BBS, */
/* whether it is msg area 17 on the host BBS */
/* or whether it is area 207. Doors should do */
/* a case-INSENSITIVE compare on this field to */
/* find where the message belongs. */
tWORD area_flags; /* The Blue Wave Offline Mail Reader uses this */
/* word internally to store the same value as */
/* in INF_AREA_INFO.AREA_FLAGS. The purpose */
/* of this word is to hold the original */
/* information about the message area so that */
/* later message editing processes can be */
/* controlled properly. For example, if a */
/* user later wanted to edit this message, the */
/* reader would know instantly whether this is */
/* a NETMAIL area, whether PVT messages are */
/* allowed, etc. This allows re-editing of */
/* the message, even when there is not a */
/* corresponding *.INF file laying around, or */
/* the area is not listed in the *.INF file */
/* you currently have to work with. DOOR */
/* AUTHORS SHOULD IGNORE THIS FIELD WHEN */
/* IMPORTING MESSAGES! */
tBYTE f_attach[13]; /* If the UPL_HAS_FILE flag is set, this field */
/* will contain the file name that is attached */
/* to the message. */
tBYTE user_area[6]; /* User-defined storage. Doors should ignore */
/* this field, and reader authors should feel */
/* free to utilize this field for their own */
/* internal use, if necessary. */
tBYTE network_type; /* Indicates the network type. This field must */
/* hold the same value as the NETWORK_TYPE */
/* field in INF_AREA_INFO, allowing doors and */
/* readers to properly handle the message. */
/* (Values duplicated as UPL_NET_xxx, above.) */
/* For FidoNet NetMail and Internet E-mail, it */
/* also indicates which fields should be used */
/* for addressing and status information (as */
/* indicated in comments above and below). */
tBYTE net_dest[100]; /* Network destination address (non-FidoNet) */
/* Internet E-mail messages should use this */
/* field to store the destination address. */
}
UPL_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.REQ
**
** Description: The *.REQ file is simply a list of filenames the user
** wants to request from the host BBS. Wildcard characters
** ("*" and "?" under MS-DOS) are allowed, but are not
** guaranteed to produce accurate results on all door
** implementations.
**
** NOTE: Current Blue Wave doors do not accept wildcard
** characters in filenames, and will consider any
** filenames which contain them as being invalid.
** Additionally, if there are more than 10 entries in
** the *.REQ file, current Blue Wave doors will read
** the first 10 and discard the rest. These are
** limitations of the Blue Wave doors, not of the
** Blue Wave format itself.
**
** File format: REQ_REC { repeated for as many files as }
** REQ_REC { requested from the host BBS }
** ...
*/
typedef struct /* REQ_REC */
{
tBYTE filename[13]; /* Name of file to request */
}
REQ_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.PDQ
**
** Description: The *.PDQ file contains the information used for the
** offline configuration feature of the mail door. After the
** header is a series of records which indicate the message
** areas to enable for scanning the next time a mail packet
** is requested.
**
** NOTE: Readers should generate a *.PDQ file *ONLY* if
** the mail packet format is version 2 or earlier;
** otherwise, a *.OLC file should be generated.
** Doors should process *.PDQ files *ONLY* in cases
** where a *.OLC file is not present.
**
** If the AREA_CHANGES flag in PDQ_HEADER.FLAGS is
** set, the door should process the offline
** configuration as well as changes to the list of
** areas the user wants to download. In the Blue
** Wave door, this is done by first turning OFF all
** message areas that were active, then turning ON
** the ones specified in the *.PDQ file. This seems
** to be the simplest, most straight-forward method
** of accomplishing this task, though other, more
** complex schemes could easily have been devised.
**
** File format: PDQ_HEADER { only included one time!
** PDQ_REC { repeated for as many message areas }
** PDQ_REC { as the user wishes to enable }
** ...
*/
/* Bit-masks for PDQ_HEADER.FLAGS field */
#define PDQ_HOTKEYS 0x0001 /* Toggle "hotkeys" in prompts */
#define PDQ_XPERT 0x0002 /* Toggle expert mode (menu displays) */
#define PDQ_AREA_CHANGES 0x0004 /* Change active message areas */
#define PDQ_GRAPHICS 0x0008 /* Toggle IBM 8-bit ASCII characters */
#define PDQ_NOT_MY_MAIL 0x0010 /* Toggle bundling mail from user */
typedef struct /* PDQ_HEADER */
{
tBYTE keywords[10][21]; /* User's entire set of door keywords */
tBYTE filters[10][21]; /* User's entire set of door filters */
tBYTE macros[3][78]; /* User's door bundling command macros */
tBYTE password[21]; /* Password */
tBYTE passtype; /* Password type */
/* 0=none 1=door 2=reader 3=both */
tWORD flags; /* Bit-mapped flags */
}
PDQ_HEADER;
typedef struct /* PDQ_REC */
{
tBYTE echotag[21]; /* Echo tag of message area to activate */
/* With Telegard systems, this should */
/* be the name of the *.BRD file, rather */
/* than the actual echo tag. */
}
PDQ_REC;
/*---------------------------------------------------------------------------*/
/*
** Name of file: *.OLC
**
** Description: The *.OLC file contains the information used for the
** offline configuration feature of the mail door.
**
** NOTE: Readers should generate a *.OLC file *ONLY* if
** the mail packet format is version 3 or later;
** otherwise, a *.PDQ file should be generated.
** Doors should process *.OLC files in all cases
** where one is present.
**
** File format: ASCII text (lines terminated with CRLF)
**
** Comments: Refer to the Blue Wave Developer's Kit documentation
** for details on the exact format of the *.OLC file.
*/
/*---------------------------------------------------------------------------*/
#endif /* __BLUEWAVE_H */
Reference in New Issue Copy Permalink