A Library for EMSI handshake for WPL Mailers by Gordon Normand XPRemsi.library is an XPR v3 library for Shelter Mailers that talks directly to wpl.library. It does not work with any other XPR host. It is not a direct replacement for the restricted distribution wplemsi.library, but can be used in those environments with some wpl code modification. The library simply sends and receives EMSI packets and calculates CRCs. All values to be sent must be set by the host mailer. Any action to be taken based upon received values is up to the host mailer. Much of this documentation is based upon public messages from Robert Williamson, the author of the Shelter Mailers, in the FIDONET echos NET_DEV and WELMAT and in the INTERNET WPL mailing lists. Much information was also gleaned from the Porticus Mailer WPL code. This powerful EMSI implementation is the most extensive available on the Amiga. References: WPL.Language, wpl application developers language reference, WPL.Programmer, wpl developers interface reference, by Russell McOrmond FSC-0056.001, The EMSI/IEMSI Protocol Definitions by Joaquim H. Homrighausen EMSI-II, EMSI/IEMSI Protocol Clarifications and Enhancements by Robert Williamson Calling: Inbound Calls: XprSetup xpremsi.library "" XprReceive "" XprClose set RC $(EMSI) Outbound Calls: XprSetup xpremsi.library "" XprSend "" XprClose set RC $(EMSI) $(EMSI) is TRUE if handshake was OK, else FALSE. The following variables should be set before calling the xpr. ${WPLNAME} An environmental variable which contains a string with the name and version of the host mailer. $(baud) The current link rate (modem<->modem, automatically set). $(remote.password) The password for the remote site as defined in site cache or nodelist. $(host.akas) A list of addresses in EMSI format: zone:net/node[.point][@domain] The first AKA is considered to be the PRIMARY address, and should be one's address in the domain of the site we are calling. $(host.phone) full phone number as in nodelist $(host.baud) max bps as in nodelist $(host.flags) nodelist flags as in nodelist $(host.sysop) sysop names as in nodelist $(host.city) location as in nodelist $(host.sitename) system name as in nodelist $(host.serial) name and version info set by host application $(host.freq) If false, the NRQ flag will be sent for INBOUND calls. $(host.link) $(host.compat) see below Additional EMSI fields can be added, if the following convention is followed: Set host.flags "$(host.flags)]}{TRX#}{[$(RESULT2)]}{[UTC]}{[${TZ}" As can be seen, the additional fields are tacked on to the host.flags variable. The library adds the data field's [,],{ and } to the variables contents. The first pair of "]}" terminate the emsi IDENT structure, the final pair is added by the library itself. If the handshake was successful, the following variables will be set. host.compat set to selected protocol (see below) remote.akas a list AKAS in EMSI format (zone:net/node[.point][@domain]) the first AKA is considered to be the PRIMARY address. remote.address set to primary address in EMSI format remote.freq this variable is set FALSE if remote site presents HRQ remote.password the password the remote site presented remote.link remote.compat see below remote.product FTSC product code remote.mailer Mailer name remote.version Mailer version remote.serial serial number or other product specific identification remote.extra remote.sitename remote.city remote.sysop remote.phone remote.baud remote.flags All the above are the remote sites system information. This may or may not be the same as what apprears in the Nodelist entry for that site. remote.time transaction timestamp The remainder is extracted from Robert Williamson's EMSI-II specification and is used by permission. The extract describes the EMSI Link and Compatibity flags which are direcetly related to the host. and remote. link and compat variables. Link and Compatibility Flag Processing: Link Flags: Link flags consist of a string of codes that specify DESIRED CONNECT CONDITIONS. They apply to the CURRENT SESSION ONLY. There are three TYPES of link flags: communications parameters, pickup options and hold options. Link Communications Parameters: Presented by both the calling system and answering system, this flag defines the communications link data bits, stop bits and parity parameters. The purpose of this flag is unclear however, my assumption is that it is expected that one end or the other change his communications parameters to match. The specification does not say which end must compromise, nor what to do if a) no compromise is possible, b) software does not support changing these parameters while connected. Obviously, if only one end changes link parameters, the session will fail. Pickup and Hold Flags: Under a strict interpretation of the EMSI specification, Link Pickup flags are only presented when calling (an Outbound Session) and are examined and processed only when answering (an Inbound Session) and Link Hold flags are only presented when answering (an Inbound Session) and are examined and processed only when calling (an Outbound Session). Some mailers optionally present BOTH Pickup and Hold flags during EITHER type of session. However, there is no requirement that the system received such a presentation take an action on flags not specified for the type of session. There are also no guidelines how to handle conflicts that may arise in iterpretation. Link Pickup options: The calling system can present one of three Link Pickup options related to pickup of mail. These are presented during OUTGOING calls and examined during INCOMING calls. / PUA Pickup mail for all presented addresses. one of | PUP Pickup mail for primary address only. \ NPU No mail pickup desired. If none of these flags are presented, PUA is to be assumed. If only one address is presented, neither PUP nor PUA should be presented, as this would be redundant. NPU is valid however. PUA: This flag is presented if our tosser is zone and/or domain aware. This flag is not examined, since sending all mail for all KNOWN akas is the default action under EMSI. The action to take if NO Pickup flag is presented is undefined in the EMSI spec. We assume PUA. Note: KNOWN akas are those addresses of a site for which one packs mail. Since no traffic exists for a sites other unKNOWN AKAS, they are of no interest and are ignored. PUP: This flag is presented if our tosser is not zone and/or domain aware. On outgoing calls the Primary address is always that address in the domain of the site we are calling. We will still present PUP, but this is redundant. When examined, mail is sent for Primary (first) address presented. NPU: This flag is presented when using the NOPICKUP session option. The presentation of NPU is a courtesy measure ONLY, since we hangup after sending our mail. When examined, NO files are sent, mail or OTHERWISE, UNLESS the remote also presented PUP. This would be an error on his part, but we ignore that fact :) and just give him what he wanted. Link Hold options: When answering, the site can present Link Hold flags which are requests to the calling site to not send certain types of files. These flags should be presented only on incoming calls and examined only on outgoing calls. HRQ Hold file requests (not processed at this time). and/or / HAT Hold ALL traffic. one of | \ HXT Hold compressed mail traffic. HRQ: This flag is presented during UMH if STRICTZMH is TRUE. This flag is also presented if file request processing is disabled TEMPORARILY for any reason. When examined, file requests are not sent to remote site. HAT: Presented if inbound free space has fallen below a preset limit. When examined, no files are sent, but files can be received. HXT: This flag is presented during UMH if STRICTZMH is TRUE. When examined, system specific processing determines what files are sent. Note: STRICTZMH would mean that only netmail packets may be sent or received. There should be no file request accepted or processed, no arcmail accepted or sent and no fileechos (TIC's) accepted or sent. Compatibility Flags: Compatibility flags consist of a string of codes that specify the CAPABILITIES (protocols and archivers) and ENABLED FEATURES (file request handler, filename conversion) of the mailer. Standard Protocol Flags: NCP No common protocol ( a failure ) DZA DirectZAP (Zmodem variant). ZAP ZedZap (Zmodem variant). ZMO Zmodem w/1,024 byte data packets (Wazoo ZedZip). JAN Janus KER Kermit SLK SeaLink Extended Protocol Flags: TEL Telink (FTS1) XMO Xmodem (DietIFNA) YMO Ymodem UUG uucp-g HYD Hydra NCP: This is presented if no compatible protocols (failure). It logged if the remote presents it. Since in most networks, a common protocol DOES exist, we fall back to that protocol, DietIFNA. Note: Versions of Binkley, Porticus, Gazebo, Umbrella and JamMail feature DietIFNA fallback. Other Compatibility flags: NRQ No file requests accepted by this system. NRQ: This flag should be presented if there is NO FILE REQUEST HANDLER. ie the system NEVER accepts file requests. When examined, No requests will be sent. **NOTE: It seems some mailers present NRQ as the caller's version of HRQ. I consider this action to be incorrect since: - Well written mailers NEVER process requests received during outbound sessions - NRQ flag indicates NO REQUEST SERVER AVAILABLE - HRQ flag indicates NO REQUESTS AT THIS TIME. - Under WAZOO, the lack of a NODELIST X? flag can be seen as the equivalent to EMSI presentation of NRQ NRQ should be presented ONLY IF the mailer does not have a file request server. It should NOT be used to indicate that the function is temporarly disabled. If the author of the EMSI specification had intended that NRQ be the caller's version of HRQ, why then are there separate LINK and COMPATIBILTY flags, if they are not consistanty applied? Why was there any distinction made between calling and answering system LINK flags? It would be more consistant if ALL LINK flags be presentable by either system. In fact, for consistancy, the chosen protocol should also be presented as a LINK flag. ARC ARCmail 0.60-capable, as defined by the FTSC. NO ACTION required, information is of little value. XMA Site supports other forms of compressed mail. NO ACTION required, information is of little value. FNC Filename conversion. This indicates that any transmitted filename must follow the CP/M & MS-DOS 8.3 restriction. An eight character file name followed by a three character extension; eg. FILENAME.EXT **NOTE: Since FNC is a COMPATIBILITY flag, it SHOULD be interpreted to mean that the system presenting FNC is advertising the CAPABILITY to send 8.3 file names. If the intention of the author of the EMSI spec was that this was a request for the other end to modify filenames, this should have be stated. The word 'received' should have been used instead of 'transmitted' and the FNC flag should have been defined as a LINK flag for consistancy in the specification. Accepting the fact the some systems actually intend the flag to be a request for the remote to convert filenames before sending, I have added this capability to RFH, my file request handler. FNC conversion is not required for mail or packets since the transmitted filenames always conform to the FTS-LIST specifications. While doing this, it occured to me that the above spec is somewhat unclear. Specifically, it does not mention what characters may be illegal in cp/m and msdos filenames. In fact, since this flag may be used by mailers on other platforms, simply stripping such characters is insufficent. Other platforms use characters in filenames that are illegal under msdos and msdos uses characters that are illegal on other platforms. Therefore, it would seem advisable that any FNC function should: - Strip ALL punctuation including embedded periods, except for the last period (.) which now separts the name and extension fields. I strip: '20'x-'2f'x, '3a'x-'40'x, '5b'x-'60'x, '7b'x-'7f'x - Convert to UPPERCASE - pad each field with trailing '0's to insure they are at least 8 and 3 in length - re-build the filename from the FIRST and LAST 4 characters of the name field and the FIRST three characters of the extension field.