JetMail Developers Documentation Version 1.00 for JetMail 1.00 Last Update: 29-Jul-93 Copyright (C) 1992/93 by Daniel Roesen and Joerg Spilker All rights reserved Contact: Daniel Roesen Friedrich-Ebert-Strasse 24 56182 Urbar Germany FidoNet 2:243/95.2@fidonet.org AtariNet 51:601/111@atarinet.ftn NeST 90:400/1031@nest.ftn InterNet droesen@scary.fido.de Phone: +49-261-679202 Fax: +49-261-679220 Please don't call before 3:00am and later than 11:00pm and please note that if you are calling from foreign contries, there could be some time shiftings. Joerg Spilker Brueckenstrasse 12 D-32676 Luegde Germany FidoNet 2:245/6207@fidonet.org AtariNet 51:601/102@atarinet.ftn NeST 90:4/0@nest.ftn The JETMAIL environment variable ================================ JetMail searchs for it's auxilliary files in a special folder which is only for JetMail's system files. The default name is JETMAIL and must be located on the same hirarchical level as JETMAIL.TTP is. If you want to use another directory structure, you have to tell JetMail where the system folder is located and how it is named. Example: JETMAIL=G:\JETMAIL\ JetMail's system files ====================== These files must be located in JetMail's system folder. CONFIG.JM --------- This is JetMail's main configuration file. Other utilitys may store additional setup information in this file by using the "External" keyword: External [ ...] is a unique program identifier and after this, zero or more parameters could follow. "External" works exactly as BinkleyTerm's "Application" keyword. All "External" lines are ignored by JetMail's configuration file parser. ROUTE.JM -------- This file contains mail routing rules for JetMail. Other utilitys may also include routing information for their own purpose after a single "Externals:" in the file. JetMail will ignore the whole rest of the file. To avoid overlappings of the syntax of keywords used by two different utilitys, the routing commands should be registered via Daniel Roesen or Joerg Spilker. DUPES.SYS --------- In this file, the CRC-32 (calculated using polynom 0xedb88320) of the last recent imported echomail MSGIDs are stored. The file is a stream of ULONGs. The CRC checksum is calculated over the following part of the MSGID string: ^aMSGID: 2:243/95.2@fidonet.org 1ed8a925 ^-----------------------------^ You can calculate the count of CRCs stored in DUPES.SYS as following: count = filelength / sizeof(ULONG); MAILHIST.SYS ------------ This file contains information about inbound/outbound mail and file attach traffic of your system. Structure if MAILHIST.SYS: o Header (HISTHDR) o Info record(s) (MAILHIST) The header contains a ("JetMail" plus terminating NUL byte), a and a number. An utility which reads MAILHIST.SYS _MUST_ check for a correct (case sensitive!) and a matching number. Changes in the number indicates that the format of the MAILHIST structure has become incompatible to the old format. Utilitys supporting version 1 can't read version 2 MAILHIST.SYS files and vice versa. Changes in the number indicates that some of the reserved space in the MAILHIST structure has been used but the file remains compatible to the other MAILHIST.SYS file of the same . Also, the history header structure HISTHDR contains information about when the file was created and last updated in standard UNIX format (seconds since 01-Jan-1970). All fields of the MAILHIST structure are self-explaining except of the pointer which is used by JetMail internally for building a linked list. AREAHIST.SYS ------------ This file contains statistic information about your echomail areas. Structure of AREAHIST.SYS: o Header (HISTHDR) o Info record(s) (AREAHIST) The header is exactly the same as in AREAHIST.SYS, but the version counting is independent from MAILHIST.SYS. Fields of the AREAHIST structure: Field Description ---------------------------------------------------------------------- Full name of the echomail area. UNIX time code when the last message was imported or exported in(to) this area. Count of message traffic. Count of dupes received. Count of messages addressed to the sysop received. EXITINFO.SYS ------------ This file contains information about the last JetMail run. The format of EXITINFO.SYS is the structure EXITINFO. Field Description ---------------------------------------------------------------------- Version of the EXITINFO structure. If an other version number than INFOVER is detected, the EXITINFO.SYS file should not be processed. Flags about what's happened. See table below. Netmail received. Netmail sent. Echomail received. Echomail sent. Description of the bit field: Bit Description ---------------------------------------------------------------------- 0 Message(s) to JetMail's AreaFix received. 1 Notify message(s) sent. 2 System report written. 3 JetMail's Server was used. 4 Message(s) to sysop received. 5 Security failure while processing inbound mail occured. 6 Message(s) trashed. 7 Message(s) gated. All other bits are reserved. FWD.SYS ------- This file contains information about pending forward requests and/or information about recently automatic removed areas. The message header format used by JetMail ========================================= The message header structure (MSGHDR) is used by JetMail and the new versions of LED, the message editor by Volkmar Wieners (2:241/5800.5) and is now the new standard. The structure was designed with arrangement with other leading Fido software authors on Atari ST. Field Description ---------------------------------------------------------------------- Name of the author of this message, NUL terminated. Name of the addressee, NUL terminated. Topic, NUL terminated. Time & date string in FTS-0001 format. This is the time and date on which this message was originally written or generated, NUL terminated. UNIX time stamp when this message was imported into your local message base or when a local entered message was exported. Offset in the MSG file where the first byte of the message text of this message is located. QBBS reply link information Message attributes (bitfield) CRC-32 of the MSGID/REPLY kludges for reply chaining. unused Extended message attributes (bitfield) A bitfield in which programs can temporary (in memory) mark a message as processed by certain functions. Example: JetMail uses bit 0 to mark a gated message internally. This field MUST be zeroed when saving to the msgbase! A bitfield in which programs can physically mark a message processed by them. To avoid conflicts between programs using the same bit with different meanings, all software authors needing a bit of this bitfield should contact Daniel Roesen. Address see at the top of this file. Please send a little description of the use of the bit you need and the name of the program. Size of message text INCLUDING the terminating NUL byte. The message text is also saved INCLUDING the NUL byte!!! QBBS read counter QBBS cost field Origin and destination address of the message. Message flags ============= N = allowed in netmail messages E = allowed in echomail messages Bit Name NE Description ------------------------------------------------------------------- 0 Private ++ Message is private 1 Crash +- Message should be send crashed to the destination system. [only for Local messages] 2 Received ++ Message was received by the addressee. This flag is used by QBBS for the BBS users. 3 Sent ++ Message was exported. [only for Local messages] 4 W/File +- Message has a file attached. The filename is specified in the subject field. 5 InTransit +- This netmail is not addressed to your system and was routed. 6 Orphan +- JetMail didn't know where to route this netmail to. 7 Kill/Sent +- Message will be deleted after it was properly sent. [only for Local messages] 8 Local ++ Message was written locally on your system by yourself or one of your BBS users. 9 Hold +- Message will be laid on hold. [only for Local messages] 10 unused -- This flag is not defined in FTS-0001 and should not be used for any purposes. 11 FRequest +- This message is a file request. The requested file(s) are specified in the subject field seperated by blanks. 12 ReturnReceipt +- Requests a receipt from the destination system of the netmail message. 13 IsReceipt +- Indicates a receipt message sent in reaction to a netmail flagged ReturnReceipt. 14 AuditRequest +- Requests receipts of all routing systems for this netmail message. 15 Deleted ++ Indicates a deleted message. A message flagged Deleted is removed the next time JetMail is invoked with the MAINT option. Extended message flags ====================== Bit Name NE Description ------------------------------------------------------------------- 0 Read ++ Indicates a message which the sysop has read via the local message reader (JetEdit or LED). 1 Archive/Sent ++ If this flag is set, JetMail copies this message to the archive area (if defined) after exporting it. [only for Local messages] 2 TFS +- Truncates the file after sent via the mailer. [only for Local FileAttaches] 3 KFS +- Deletes the file after sent via the mailer. [only for Local FileAttaches] 4 Direct +- Send netmail direct to the destination (don't route it). [only for Local messages] 5 ZoneGate +- Send netmail via zone gate system (not yet implemented). [only for Local messages] 6 HostRoute +- Send netmail via host/hub of the destination system (not yet implemented). [only for Local messages] 7 Locked ++ Indicates that this message is locked. That means: No export, no crunching, no changing (in JetEdit) of the message header and text. 8 Immediate +- Send netmail immediatly to the destination. This is the "harder" version if crashmail only implemented correctly in Semper, a new mailer by Jan Kriesten. 9 Gated ++ Marks locally gated messages. 10 CreateFlowFile +- Marks a message which advises JetMail to send several files to the destination system. See section "Flowfile creation facility" for further explanation. JetMail Flowfile Creation facility ================================== JetMail allows writing sending files without knowing the real outbound format. So utils are independent from the outbound structure. This feature is very useful for utils such as TICker etc. It would be nice if all mail processors provide this feature. The utils must write a netmail message with the To-field containing the destination address for the files and the string "SysOp". The "From" string should contain the name of the creating program, such as "STick" or "Hatch" or whatever. The From address is not of interest and should contain 0:0/0.0 as address. In order to detect FlowFile-Messages, the flag XF_CREATEFLOWFILE must be set in the bitfield. The subject line is not used by JetMail but should contain "Flowfile creation". This is subject to change, 'cause there could by an use for this field. Each message line is of the following syntax: must be the full file specification incl. path and drive can be "" "" "" "" can be "" "" "" means that the mailer should truncate the file after if was successfully sent. means that the mailer should delete the file after it was sucessfully sent. The message MUST be terminated by a tearline. Example of a message: ====== CUT HERE ============================================= Msg #20 / 1-33 Time: 16 Jul 92 21:48:20 From: TIC-me on 0:0/0 To : SysOp on 2:245/52 Subj: Flowfile creation ---------[FidoNetmail ]------------------------------------------ C:\DESKTOP.INF G:\IO\TICS\12345678.TIC D:\BLAFASEL.TXT --- ====== CUT HERE =============================================