UMS Message Format $VER: 9.2 (17.7.92) This text is (C) 1992 by Martin Horneffer. It may freely be copied and distributed, as long the the text is unchanged and this copyright notice is left intact. The Universal Message System universal message format. A message in the UMS message base is always defined by a list of tags. This allows the format to be easily extended as new tag may always be defined later on. In one UMS message, each tag may occur only once. Some tags are somehow implementation-dependend - these are documented somewhere else. This document describes the format of the currently defined TEXT-tags. Currently these tags include all information that is site-independend and needed when transfering messages between different systems. Most of these tags are network-independent. Drivers for all networks can and must understand them. A text-tag specifies a null-terminated string of any length. All ASCII-characters are allowed. Unless something else is documented for a specific tag, the ISO 8859-Latin 1 charset is used for 8-bit characters. Some of the text-tags are required for every message, others are optional. 0) "MsgText" This contains the main 'text' of a message. Every message must have this tag as it is usually the main information transported by a message. Any information that does not belong to teh original text must not be put here. Even when a gateway between two different networks puts information in the text, an UMS importer should - if possible - extract this information and use or store it somewhere else. The text may be of any size. Since some networks limit messages to a certain size, drivers for these networks must be able to cope with this situation. Lines are delimited by the standard line delimiter (LF for the Amiga; may be different fpr other systems). Lines may be of any length, so it's up to the newsreader or exporter to wrap lines if needed. 1) 'FromName' This is the name of the message's author. It's ONLY the name (the 'realname', if possible), NOT the address. If there is no realname, the username must be used or extracted from the author's address. Every message must have this tag. 2) 'FromPath' This is the author's net-address. The name needn't redundantly be repeated in this field, if it's already in 'FromName'. This tag must be empty (i.e. the tag may not occur), if the author is located on the local system. In every other case this tag is needed. Whenever possible, the address should be the user's real address and not an encapsulated address or the address of a gateway. Thus it may be necessary for importers to convert received addresses to another network's format. The corresponding exporters, of course, have to be able to re-convert these address. This makes used gateways transparent to the user - one of UMS' most important features. It saves the user from having to know and worry about all the gateways' formats himself. Since there are different networks with different formats of addresses, it's neccessary to distinguish these different formats. This is done by looking at the "tail" of the address. The following formats are currently known: Identifier : network/format ---------------------------------------------------- "@Fidonet" : FidoNet ".maus" : MausNet ".zer" : Z-Net ".org", ".sub", ".edu", ".UUCP", ".de", .. [any valid usenet domain] : RFC E.g., "2:242/7.9@Fidonet" is an address in Fidonet format. "ac2.maus" is MausNet format, "maho@dfv.rwth-aachen.de" is RFC. Network-identifiers are NOT case-sensitiv. Nevertheless you always should preserve case, as it might be needed by some networks. Some examples for splitting addresses in 'Name' and 'Path': RFC: "Martin Horneffer " -> name: "Martin Horneffer" path: "maho@balrog.dfv.rwth-aachen.de" "horneff@pool.informatik.rwth-aachen.de (Martin Horneffer)" -> name: "Martin Horneffer" path: "horneff@pool.informatik.rwth-aachen.de" "horneff@pool.informatik.rwth-aachen.de" -> name: "horneff" path: "horneff@pool.informatik.rwth-aachen.de" FidoNet: "Martin Horneffer at 2:242/7.9" -> name: "Martin Horneffer" path: "2:242/7.9@Fidonet" "Joerg Gutzke at 2:242/7" -> name: "Joerg Gutzke" path: "2:242/7@Fidonet" 3) 'ToName' Name of the person the message is addressed to. Must be specified in all private messages ("e-mail") and is optional in public messages ("news"). 4) 'ToAddress' Network-address of the addressed person. Needed in private messages if the message has not yet reached its destination. Must not be used when the mail is addressed to a user on the local system. 'ToName' and 'ToPath' have exactly the same format as 'FromName' and 'FromPath'. It must always be possible to reply to a private or public message by using it's FromName and FromPath as the new ToName and ToPath. 5) 'MsgID' A unique message ID in RFC-format. This is valid also for non-RFC networks like FidoNet or Z-Net! Every message must have such an ID. If there's no ID for a message, the message-base-processor will create a new one for this message. Never create message IDs on your own! 6) 'CreationDate' (Optional) date of creation (i.e. when the message has been written by the user). May be in any format that is readable by humans. AmigaDOS format (dd-mmm-yy hh:mm:ss) preferred. 7) 'ReceiveDate' Not used any more. Avoid this. As a replacement there is a tag for a site-specific binary date. 8) 'ReferID' (Optional) message ID of the most recent message that is referred to by the current message. Same format as 'MsgID'. 9) 'Group' Name of the message's newsgroup. Must be used for public messages; may not be used for private mail. This tag is the only one that distinguishes private from public messages. To avoid possible conflicts, the name of the network must be prepended for non-usenet groupnames. Usenet groupnames, which already are hierarchically ordered, stay as they are. E.g. "fidonet.AMIGA", "maus.ac.amiga", "comp.sys.amiga.misc". 10) 'Subject' The (short) subject of the message. Required. 11) 'Attributes' (Optional) list of keywords controlling the processing of the message and/or telling how to interpret it. The keywords are separated by blanks (" "). Some known keywords for 'Attributes': key meaning ----------------------------------------- "file-attach" the message comes with an attached (binary) file that should be routed with the message. The 'Subject' contains the name of the file on the local system. "receipt" the message has automatically been created and should not be replied to. (e.g. a "receipt" or a "bounce-mail"). "receipt-request" author wishes to get a receipt. "crash" FidoNet-crashmail "BIM" the author illegally used IBM-PC special chars and needs to be flamed. ;-) 12) 'Comments' (Optional) all "header-"information, that belong to a message and must be preserved, but don't fit to another text-tag. E.g. all unknown RFC-header lines go here. 13) 'Organization' (Optional) sender's organization or "Origin". 14) 'Distribution' (Optional) where/what the message should be distributed to/by. Much like RFC-"Distribution:". 16) 'FidoID' This is specific to FidoNet and should be ignored by all programs not specifically dealing with FidoNet. It's used to keep the internal "^aMSGID" used within FidoNet if it cannot be converted to 'MsgID'. This only applies to messages that came from other networks and went to FidoNet through some gateway. 17) 'MausID' This is specific to MausNet and should be ignored by all programs not specifically dealing with MausNet. It's used to store the internal MausNet-ID. It will become superfluous when MausNet software learns to deal with real Message-IDs. 32) 'FidoText' This is specific to FidoNet and should be ignored by all programs not specifically dealing with FidoNet. It's used by FidoNet drivers to avoid loss of information due to conversions of eol-delimiters or charsets.