Document: FSC-0064 Version: 007 Date: 10-May-1992 InterDomain Message Identification, Gating, Reply Linking and Addressing Jamie Penner 1:153/1025 Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Copyright (C) 1990, 1991, 1992 by Jamie Penner All Rights Reserved Originally written: Sept 3, 1990 Revised: November 12, 1990 Revised: June 23, 1991 Revised: August 26, 1991 Revised: January 22, 1992 Revised: February 4, 1992 Revised: February 12, 1992 Use of this proposal is encouraged and permitted by the author without further notification in any software which is being written to conform to FTSC specifications. Suggestions and discussion are strongly encouraged. The author may be reached at: jamie.penner@f1025.n153.z1.fidonet jamie.penner@f0.n24.z24.signet.admin Echomail Basics: All echomail passing through an interdomain echomail gateway must have all information in the message header changed to reflect the proper address of the domain in which the messages are entering. The PATH and SEEN-BY lines should also reflect these changes with only the SEEN-BY line containing any information from the domain previous. This information shall be the single address of the system passing the mail to the gateway system. In addition, all gateway software should recognize, by the message itself, whether it has EVER passed through the gateway in the past. CRC records, SEEN-BY lines, PATH lines and MSGID lines are not sufficient for this purpose as most systems purge recorded logs of this info after a given time. InterDomain Echomail/Netmail Flags: ----------------------------------- ^ADOMORG: usr.nme@[!][p.f.n.z.]network[.nid][[#nodelist_name][#point[x]] ^ADOMDES: usr.nme@[!][p.f.n.z.]network[.nid][[#nodelist_name][#point[x]] These lines would be a complete domain signature for any user on any system in any FTN network. The DOMORG line would be the actual origin information of the user and system sending the information. The DOMDES line would be the actual destination information of the recipient user and system. There are essentially two variations to the domain signature. The ! immediately following the @ denotes a Type B, otherwise defaulting to Type A. Type A: e.g. jamie.penner@f1025.n153.z1.fidonet This has the complete FTN information needed for any processor to send the message. Type B: e.g. jamie.penner@!signet.admin#ic.signet The ! immediately preceeding the network signifies that no FTN information is available but the information after the # will give the name of the system as denoted in the nodelist for that network. This way, processors can be designed in a fashion that they can look up the system name. Should this be going to a point, the domain may be: jamie.penner@!signet.admin#ic.signet#point If I have two points and I want to send it to a different point, I might use: jamie.penner@!signet.admin#ic.signet#point2 The domain identifier in a Type B signature can be further used for further locating a system if needed. In both signature types, the nid (network identifier) is optional (eg fidonet.org or signet.admin - only the first field actually identifies the network name). This information is completely dependant upon each domain. For example I might send this: rob.macare@!signet.eur.r331#maasstad.bbs This kind of structure would get the message to the right system. If there was two of the same system in Region 331, I could use: rob.macare@!signet.eur.n4601#maasstad.bbs This format of domain signatures is provided solely for compatibility purposes to provide software developers with a platform on which they can structure new programming techniques and can be used in conjunction with the other flags as laid out in this document. # GateOrigin: zzz:NNN/nnn.ppp@dmn (note leading space) This line is currently inserted into all stripped down echomail passing through interdomain gateways by GateWorks. This allows the message overhead to be cut down by properly replacing the origin line for users to read in the text yet, not creating a second full originline. This line shall be added immediately before the tearline with a single blank line following it. e.g. # GateOrigin: 24:24/0.0@signet ^AGATECHK: zzz.NNN.nnn.ppp [zzz.NNN.nnn.ppp] [zzz.NNN.nnn.ppp] Any echomail passing through a particular gateway should have this line inserted at the beginning of the message text. Everytime the message passes through another echomail gateway, the address would be added to the line. This way, if a message passes back through with the same ID, it is a known duplicate and can be vaporized. e.g. ^AGATECHK: 24.24.0.0 8.8.7001.0 ^AMSGORG: The MSGORG line keeps a standard original address and message id in the message for reply, identification, dupe checking, and origination purpose. This line would vanish and be replaced with the necessary lines if passed through a gateway. e.g. ^AMSGORG: 24:24/0.0@signet 0123456789abcdef The originating ID is no different than other 16 bit IDs being generated. It must be unique in a sense that no other message originating from that system will have the same number (at least within a short time span). ^AGATEWAY: This field is inserted by the packer. The user-defined zonegate fields give the message its destination to the zonegate and may be routed through whatever channels to get there. e.g. ^AGATEWAY: 1:153/1025.0@fidonet.org ^GRPLY: When replying to a message, this line would be looked up so as to find the actual message destination and give the system its zonegate information. If the message passes through a gateway, the MSGORG line would be removed upon insertion of this line. e.g. ^AGRPLY: 1:153/1025@fidonet.org 24:24/0.0@signet An example echomail message from 24:11/7777.0@signet across the domain to 1:153/85.0@fidonet should read: To: Bill Herringshaw, 1:153/85.0@fidonet From: Jamie Penner, 1:153/1025.0@fidonet Subject: Testing AREA: TEST_ECHO ^AGATECHK: 24.24.0.0 ^AGRPLY: 1:153/1025.0@fidonet 24:11/7777.0@signet ^ADOMORG: jamie.penner@f7777.n11.z24.signet.admin ^ADOMDES: bill.herringshaw@f85.n153.z1.fidonet.org ^APID: RA 1.01 Hi Bill, just testing out this new software # GateOrigin: 24:11/7777.0@signet --- GateWorks v4.00a * Origin: Home of GateWorks!! (1:153/1025.0) SEEN-BY: 24/0 153/1025 ^APATH: 153/1025 An editor programmed to handle these fields would recognize GRPLY line and know that the message had passed through a gateway. An echomail reply would simply pass through the gateway. If a netmail reply was required, this would be the reply message: To: Jamie Penner, 24:11/7777@signet From: Bill Herringshaw, 1:153/85.0@fidonet Subject: Testing ^AGATEWAY: 1:153/1025.0@signet ^AGRPLY: 24:24/0.0@signet 1:153/85.0@fidonet ^ADOMORG: bill.herringshaw@f85.n153.z1.fidonet.org ^ADOMDES: jamie.penner@f7777.n11.z24.signet.admin > Hi Bill, just testing out this new software Got it here! via InterMail @ 24:24/0.0@signet, 17:23:17 22 Jan 92 The mailer and/or packer would check for the GATEWAY flag and route the message through that gateway. Under this method of flags, all systems in all domains should have access to the ability to reply via netmail to a system in a different domain. In addition, by following this specification, all interdomain echomail should be clean and troublefree. This eliminates the need for some of the other ^A lines being used. It is the intention that all addresses in these flags may use the 5d addressing scheme, or either of the Type A or B domain signatures. The software should be written to determine the type of address used and manipulate the situation accordingly. The following list of software may be incomplete but lists all software currently available or under development using this spec: GateWorks v4.00 ContactBBS TOSSworks FASTmail