home *** CD-ROM | disk | FTP | other *** search
-
- InterMail External File Request Processor Interface
-
- Copyright 1993 InterZone Software, Inc.
- All rights reserved.
-
- =========================================================================
- * Support for External file request processors has been added.
- See IMSETUP, under Mailer/File Requests/External. The following
- is an example of how a request processor could be installed:
-
- [path]\MYFREQ.EXE %A %F %N %P
-
- The pseudo parameters would in this case give the request
- processor the following information: network Address,
- List file, User name, Password.
-
- In all the parameters, any spaces are replaced with underscore
- characters (_). These are the available parameters:
-
- %A Network address of the remote system, e.g.: 1:369/35
- %B Link rate for the connection in bps, e.g.: 14400
- %C Session cost per minute, as defined in the cost table in
- FDNODE.CTL, e.g.: 25
- %D "INBOUND" or "OUTBOUND", depending on whether it's an
- incoming call or not.
- %F Pathname of the request list to be processed, e.g.:
- C:\IM\IMFILREQ.001
- %L Location provided by remote system's site info, e.g.:
- Pembroke_Pines_FL
- %M Minutes left to the next event when requests aren't
- allowed.
- %N Name of remote system, e.g.: InterZone_Cafe
- %O Name of remote system's SysOp, e.g.: Peter_Stewart
- %P Sessionlevel password given by remote system.
- %X "SECURE", "UNSECURE" or "UNLISTED" depending on whether the
- session is password protected or not.
- %Z Type of session: "WAZOO", "EMSI" or "OTHER" (the last is
- unlikely, since the external processor currently won't
- be invoked for BARK requests).
-
- The external request processor is executed in a shell from
- InterMail. It should finish processing within the timeout
- limits of the Zmodem protocol. The following should be returned
- by the file request processor:
-
- 1) The processed request list, using the same filename as the
- original list and containing the fully resolved pathname
- of each file that is to be sent.
-
- The request processor must handle all magic filenames,
- timestamps for update requests, as well as all password
- protection. Timestamps and passwords are supplied in the
- standard WaZOO request list format, since IM doesn't
- pre-process the contents of the request file in any way.
-
- A minus in front of a filename means that IM should delete
- the file after the session has been completed.
-
- 2) (Optional) Up to 255 return message files. These should
- be placed in the same directory as the request list and
- must use the following naming convention: IMRMSGnn.ext,
- where "nn" is the number of the message ("00"-"FE"), and
- ".ext" is the same extension as that of the request list
- (e.g. ".001", ".002", etc.).
-
- The name of the "sender" of the message can be inserted
- as a kludge line at the start of the message. If the first
- character is ^A (0x01), then IM will use the first line
- of the message (up to 35 characters) as the name of the
- sender. Otherwise the sender will be "InterMail". For the
- developer, this means that if you intend to use any other
- "kludge lines", e.g. MSGID, you must insert the sending
- program's name as the first line. NOTE: The message should
- contain text only and no message header beyond the name of
- the sender: IM will create the packed message header with
- all the required address information.
-
- The message text should be plain ASCII, and the only
- control characters should be ^A, CR and LF. InterMail
- will do no other processing of the text than creating
- a packet and message header, inserting any required INTL
- and FMPT/TOPT lines, and transmitting the message text
- unchanged.
-
- -*-
-