********************************************************************** FTSC FIDONET TECHNICAL STANDARDS COMMITTEE ********************************************************************** Publication: FTS-1025 Revision: 1 Title: Simple E-Mail Attach Transport (S.E.A.T.) Author: Charles Cruden, Vincent Danen, Brent Shellenberg Ramon van der Winkel Issue Date: 15 May 2004 Review Date: 15 May 2006 ---------------------------------------------------------------------- Contents: 1. The Purpose 2. Reading this document 3. Implementation 4. Specifying compliancy 5. Required implementation 6. Recommended implementation 7. Optional implementation 8. Last Notes ---------------------------------------------------------------------- Status of this document ----------------------- This document is a Fidonet Technical Standard (FTS). This document specifies an optional Fidonet standard protocol for the Fidonet community. This document is released to the public domain, and may be used, copied or modified for any purpose whatever. Introduction ------------ This document describes a consistent way of sending FTN style mail as an attachment to an internet e-mail. It provides a clearly delineated minimum specification, a recommended specification as well as several option extensions. 1. The Purpose -------------- With the popularity of the internet being utilized as a replacement for long distance calls to transfer FTN style mail, came about a problem. Though the idea is exciting and beneficial to all, every developer that went this route did their work on their own (thus creating a large sea of software that wasn't compatible with anything else). The purpose of this document (and discussions that have been ongoing in the Sysop's Tech Net and NET_DEV) is to define a basic standard of common ground that can ensure that everyone's software has the ability to communicate with others. As much as the FTS-1 document of Fidonet makes sure that FTN style mailers can communicate, this document is to do the same thing for internet e-mail attachment software. 2. Reading This Document ------------------------ This document uses examples to show working "real life" copies of what a properly formatted S.E.A.T. message looks like, making it easier to get a visual idea of how the whole thing works. 3. Implementation ----------------- This document is divided into three sections: required, recommended and optional implementations. Each defines a level of compatibility with S.E.A.T. In order for a program to be considered S.E.A.T. compatible, it must implement all the encodings and keywords presented in the "required" section of this document: this will be defined as S.E.A.T. level one compatible. This provides a method for sending files of any size through email, but does not provide a means for assuring their correct delivery. Developers are strongly encouraged not to stop at providing S.E.A.T. level one support but to include level two support - implementation of all the encodings and keywords presented in the both the "required" and "recommended" sections of this document. Level two support provides for reliable transmission of files through email. S.E.A.T. levels three and four are defined as programs which implement respectively some or all of the encodings and keywords presented in the "optional" portion of this document, as well as providing S.E.A.T. level two support. Although these extensions are not required of any implementation, they provide certain features which future users would find useful. Note that a program cannot be considered to provide support for S.E.A.T. at a given level without providing support for ALL the levels beneath. 4. Specifying compliancy ------------------------ When a program specifies that it is S.E.A.T. compatible, it must also provide the level of S.E.A.T. which it implements. i.e. "This program is S.E.A.T. level three compatible." All level four compatible programs must also provide the revision of S.E.A.T. which they are compatible with, so that other developers may be aware which extensions the author claims to support. It is recommended, though not required, that all authors provide this information as well. 5. Required implementation -------------------------- S.E.A.T. level one describes the minimum set of encodings and keywords which a program must support in order to be considered S.E.A.T. compatible. Quickly, these are: Encodings: UUencode Keywords: Ftn-File Ftn-File-Id Ftn-Crc32 Ftn-Encoding Ftn-Seg Ftn-Seg-Id Ftn-Seg-Crc32 S.E.A.T. level one programs must correctly generate these keywords for each file they send, and must be able to decode any incoming message which uses exclusively keywords from this set. Note that this implicitly requires any S.E.A.T. compatible mailer to support files split across multiple messages. 5.1 Attachment Example ---------------------- All control information for each attached file is placed in the message body text. The only exception to this is the subject line, which must always start with a fixed character string to identify (to mailer software) the e-mail message as a SEAT packet. Control lines must be confined to more than 255 characters in total length, and unless otherwise specified, may not have any "white space" (ie: no blank characters other than the space that directly follows the control line identifier). This document displays the use of basic uuencoding of files. All implementations must provide it as a bare minimum. --snip-- From: ARCmail To: Steven Lager Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:26:47 Organization: GUNN Data Systems Reply-To: Brent Shellenberg X-Mailer: INetFTN v0.02-Beta Ftn-File: AA3D1EAC.TH0 Ftn-File-Id: AA3D1EAC.TH0.876796006.50DC7A2B Ftn-Crc32: 50DC7A2B Ftn-Encoding: uuencode Ftn-Seg: 1-1 Ftn-Seg-Id: 50DC7A2B-1-1-brents@sk.sympatico.ca Ftn-Seg-Crc32: 50DC7A2B begin 644 AA3D1EAC.TH0 M4$L#!!0````(`%834".2#K[O=0$``#("```,````,C,U,#$S-4(N4$M4;5$] M;]LP$*7LK0"+S)EN:1$K%D4QK>UPBF3+:H?80:D.G0K:D2W!BAB(=!!O^;GY M#UE""G6+MCE^X'B\]^[XZ"$/2?0.G:`>.D5#]/2AAY[[+_WW/?3+;NUPYC*/ MOK->%W&Y[A2-8+DV<#D&H(RS$:<4Q76-DK9H#(BRJ.NB617M%N6%-BC^EL8\ MFXF?29K'V,N_SCB(+%V7"AX8H33,5'U[CKUKD;FKB%)N%PTCF--I,IZ.(^S= M=*!2F>V^^0N5EY4&.R486XM@3`C!MADP90$K&QKB_]K"V/ To: Brent Shellenberg Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:30:00 Organization: Some Guy's BBS Reply-To: Steven Lager X-Mailer: INetFTN v0.01-Beta Ftn-Receipt: 50DC7A2B-1-1-brents@sk.sympatico.ca Ack --snip-- 6.2.2 ACK Example (Multiple ACKs) --------------------------------- Acknowledgements may also come with multiple ACKs in a single message. Software should look for this, and be prepared to act on it at any time. Example (ACKing the above attachment example): --snip-- From: ARCmail To: Brent Shellenberg Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:30:00 Organization: Some Guy's BBS Reply-To: Steven Lager X-Mailer: INetFTN v0.01-Beta Ftn-Receipt: 54DC7A2B-1-1-brents@sk.sympatico.ca Ack Ftn-Receipt: 53DC7A2B-1-2-brents@sk.sympatico.ca Ack Ftn-Receipt: 53DC7A2B-2-2-brents@sk.sympatico.ca Ack Ftn-Receipt: 52DC7A2B-1-1-brents@sk.sympatico.ca Ack --snip-- 6.2.3 NAK Example ----------------- A NAK has two purposes when dealing with file acknowledgements. The first method is similar the ACK procedures for dealing with getting a resend of an individual file segment. The second method is for requesting a total resend of a complete file. NAKing A File Segment --------------------- A NAK should be sent when there is a problem decoding a received file segment, or a segment is missing after a long period of time (implementation of timers is the resposibility of the developer). Example (NAKing the above attachment example): --snip-- From: ARCmail To: Brent Shellenberg Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:30:00 Organization: Some Guy's BBS Reply-To: Steven Lager X-Mailer: INetFTN v0.01-Beta Ftn-Receipt: 50DC7A2B-1-1-brents@sk.sympatico.ca Nak --snip-- As with ACKs, NAKs may come in multiples in the same message. NAKing A Complete File (complete resend) ---------------------------------------- The only difference in this method is that the ID line used in the Ftn-Receipt line is the Ftn-File-Id line and NOT the Ftn-Seg-Id line. To use show the difference between this method and the simple method of NAKing a file segment, this example (again) uses the example from this document: --snip-- From: ARCmail To: Brent Shellenberg Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:30:00 Organization: Some Guy's BBS Reply-To: Steven Lager X-Mailer: INetFTN v0.01-Beta Ftn-Receipt: AA3D1EAC.TH0.876796006.50DC7A2B Nak --snip-- With the possibility of a system requesting a total resend of a file, comes the possibility that the file no longer exists on the sending system (as in the case of echomail bundles or TIC files). SEAT provides a method for the sender to tell the receiver that the requested resend file no longer exists through the use of the Ftn-Cancel line. In taking the above example for requesting a complete resend, the sending system would respond with a message such as: --snip-- From: ARCmail To: Steven Lager Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:30:00 Organization: GUNN Data Systems Reply-To: Brent Shellenberg X-Mailer: INetFTN v0.01-Beta Ftn-Cancel: AA3D1EAC.TH0.876796006.50DC7A2B --snip-- 6.2.4 ACKs/NAKs Within An Attachment Message -------------------------------------------- ACK/NAK lines may be sent along with a message that contains an e-mail attachment. This cuts down on the number of e-mail messages that are sent, and can generally clear the clutter from your spool directory. Using the document example, this example is modified to show this usage of ACK/NAK lines. Please note that these control lines can be anywhere in the message text boundary. --snip-- From: ARCmail To: Steven Lager Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:26:47 Organization: GUNN Data Systems Reply-To: Brent Shellenberg X-Mailer: INetFTN v0.01-Beta Ftn-File: AA3D1EAC.TH0 Ftn-File-Id: AA3D1EAC.TH0.876796006.50DC7A2B Ftn-Date: 876796006 Ftn-Crc32: 50DC7A2B Ftn-Encoding: uuencode Ftn-Seg: 1-1 Ftn-Seg-Id: 50DC7A2B-1-1-brents@sk.sympatico.ca Ftn-Seg-Crc32: 50DC7A2B Ftn-Receipt: 437D8EAA-1-1-onsite@accel.net Ack Ftn-Receipt: E7F352CB-1-1-onsite@accel.net Nak begin 644 AA3D1EAC.TH0 M4$L#!!0````(`%834".2#K[O=0$``#("```,````,C,U,#$S-4(N4$M4;5$] M;]LP$*7LK0"+S)EN:1$K%D4QK>UPBF3+:H?80:D.G0K:D2W!BAB(=!!O^;GY M#UE""G6+MCE^X'B\]^[XZ"$/2?0.G:`>.D5#]/2AAY[[+_WW/?3+;NUPYC*/ MOK->%W&Y[A2-8+DV<#D&H(RS$:<4Q76-DK9H#(BRJ.NB617M%N6%-BC^EL8\ MFXF?29K'V,N_SCB(+%V7"AX8H33,5'U[CKUKD;FKB%)N%PTCF--I,IZ.(^S= M=*!2F>V^^0N5EY4&.R486XM@3`C!MADP90$K&QKB_]K"V/ where is one of the following codes, and is as defined for the given code. CA: cryptographic algorithm unsupported When a program receives a file encrypted with a cryptographic algorithm it doesn't support, it should send this code back, with the parameter being the entry in the Ftn-Crypt field. A system which receives this error should notify the user of the problem and treat the file as being NACK'ed, though where possible, it would be desireable not to have the file resent until the systems have worked out an algorithm which they both can use. UE: unsupported encoding These are generated when the encoding given in the Ftn-Encoding line is not supported by the system which received the message. The parameter is the Ftn-File-ID of the file that was sent. UK: unsupported keyword If a mailer finds an Ftn- control line which it doesn't recognize, it should respond with an unsupported keyword error, and give the unrecognized keyword as the parameter. UM: unsupported MIME format These are generated when the Content-Type or Content-Transfer-Encoding strings in the MIME header are not understood by the receiving system. The parameter is the Ftn-File-ID of the file that was sent. (Other error codes may be added as new features are added to the specification.) Error codes are case insensitive. An example of sending an Ftn-Error line is: --snip-- From: ARCmail To: Brent Shellenberg Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:30:00 Organization: Some Guy's BBS Reply-To: Steven Lager X-Mailer: INetFTN v0.01-Beta Ftn-Error: UE 54DC7A2B-1-1-brents@sk.sympatico.ca --snip-- Like Ftn-Receipt and Ftn-Cancel, Ftn-Error lines can be sent more than one to a file, and can be sent as part of the control lines of another file. The system which generates an Ftn-Error line should notify the user that an error has occurred and should explain what the error was. The system which receives an Ftn-Error line should also notify the local user that a problem occurred, explain what the error was and to whom the original message was intended. When the parameter of an Ftn-Error line is an Ftn-File-ID, Ftn-Error means that the file with the given ID has not been received correctly (as if a Nak had been received). It is up to the developer to decide whether this will mean the file will be resent with the problem fixed, or whether the local user will be requested to fix the problem, though wherever possible, the first choice is preferred. 6.3 Time Allowances For ACKs ---------------------------- It is up to the developer to decide the time frame to be allowed for the ACKs to be returned to the sender's system. 3 days would be sufficient. Keep in mind that this means that there needs to be a copy stored on the user's hard drive for that length of time (in case no ACK is received, or the other system responds with a NAK). If the time period passes, the sender should resend the segments in question. The receiver of the file(s) should simply ignore (erase) any segments belonging to files that have already been received. An easy way to accomplish this to maintain a data file containing the Ftn-Id lines (or the Crc32 value). As an note to developers, you should have your encoding scheme be able to not require acks at all, as some users may wish to transfer files to other parties that use simple e-mail clients that don't have the ability to react to the Ftn-* control lines (eg. S.E.A.T. level one mailers). 7. Optional implementation -------------------------- The keywords and encodings given here are optional for any developer to implement. Although they provide extended functionality to programs, their implementation may be too difficult or time consuming for some. S.E.A.T. optional keywords are: Ftn-Freq Ftn-Auth Ftn-Crypt S.E.A.T. optional encodings are: Base64 7.1 Example message for optional implementations ------------------------------------------------ Note that the MD5 and Crc32 values here are just fillers and have not been calculated to match the contents of the message. --snip-- From: ARCmail To: Steven Lager Subject: FTN Mail Transport Date: Thu, 16 Oct 1997 02:26:47 Organization: GUNN Data Systems Reply-To: Brent Shellenberg X-Mailer: INetFTN v0.02-Beta MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=SomeUniqueStringThing Ftn-File: AA3D1EAC.TH0 Ftn-File-Id: AA3D1EAC.TH0.876796006.50DC7A2B Ftn-Date: 876796006 Ftn-Crc32: 50DC7A2B Ftn-Encoding: Base64 Ftn-Seg: 1-1 Ftn-Seg-Id: 50DC7A2B-1-1-brents@sk.sympatico.ca Ftn-Seg-Crc32: 50DC7A2B Ftn-Auth: c349f4d113a4d38afd5327c3328d6c37 Ftn-Crypt: Blowfish --SomeUniqueStringThing Content-Type: application/octet-stream; name=AA3D1EAC.TH0 Content-Transfer-Encoding: Base64 Content-Disposition: inline; filename=AA3D1EAC.TH0 //xQAAABXAwAAAAAAAAAAAACiAAAAAAAAAAHAAcAKAAAAElCTV9MUwDDAAAA ACwBHAAAAcQBxAFIAAABDT01QTRTAFtSRVFVRVNURVJdLFtBUEldLFtCT09L FUUlOU1RBTExdLFtVUE1FWFRdRVSU0VSVkVSXSxbRE9TTEFOQVBJXSxbR1VJ JUEJPQVJEXSxbTVNHUE9QVVBdR1JTkdVSV0A5QAAAAAAAAAIAAgA2wAAAAIA AUkVMRUFTRQA1AAgBAAAAAAAAA0AAAADAAMABQEAAFZFUlNJT04AMDQAKAEA GAAYAIAEAAAIAAgAmAQAAT1NSMBJAQAAAAAAAAYABgBAAQAAAwADAEYBAABP 0MABwAQAAAAAAAAUABQBhAQAAAYBAABQQVRIAEs6XElCTUxBTgAAAAAAAAAA IAQAAEQARAJEBAABJTlNUVFlQTRSWShSRVFVRVNURVIpAI4CAAC/AQAAAAAA 2AQAASUJNX0xBTlgA4QEAAAAAAgA1wEAAAIAAgDfAQAAUkVMRUFTRQA1AAQC ACAAIAPkBAAADAAMAAQIAAFZF04AMTIAJAIAAAAAAAAGAAYAHAIAAAIAAgAi SRUwAMgBFAgAAAAAAAAYABgA8AADAEICAABPU1ZFUgA0MABsAgAAAAAAAAUA ACgAKAGICAABQQVRIAEs6XElCQAAAAAAAAAAAAgACACEAgAAAgACAIwCAABS IADEAAAAAAKoCAAAAAAAACAAIABJQk1fVVBNAMwCAAAAAAAACAAIAMICAAAC AAFJFTEVBU0UANQDvAgAAAAAAADkAgAAAwADAOwCAABWRVJTSU9OADA0AA8D ABgAGAAcDAAACAAIADQMAAE9TDIAMAMAAAAAAAAGAAYAJwMAAAMAAwAtAwAA VIANDAAAAAAAAAAAAAFAAUASAMAACgBNAwAAUEFUSABLOlxNVUdMSUIACy== --SomeUniqueStringThing-- --snip-- 7.2 MIME Headers and Base64 encoding ------------------------------------ Mime headers can be a touchy subject when trying to implement an easy to use decodable scheme. Many programs tend to use different flavours of MIME headers, and can therefore create a bit of a headache when trying to decode them. These simple guidelines will ensure that a file can be decoded by standard MIME mail programs as well as SEAT compatible readers. It is important to understand that they are intended merely as a subset of MIME that will be, nevertheless, compatible with MIME enabled mail readers. S.E.A.T. does not require that a given mailer be able to correctly interpret any MIME message. Wherever possible though, authors are encouraged to make more robust MIME parsers. Base64 Encoded Messages ----------------------- There are required control lines that need to be placed in the message header in order for e-mail clients to correctly determine that a message is a MIME format message. These two lines are basically: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= The boundary string is a unique string that you create for your MIME format messages. Implementations should be aware that for the Content-Type: line as mentioned above, some e-mail readers place quotations around the . Other changes required to an e-mail message to make it MIME compliant: Following the Ftn-* control lines: -- Content-Type: application/octet-stream; name= Content-Transfer-Encoding: Base64 Content-Disposition: inline; filename= (Base64 encoding of the file part goes here) ---- Note that this forces MIME implementations to use Base64 encoding and the prescribed Content-Type. Future revisions may allow different Content-Transfer-Encodings and Content-Types. Developers who choose to support the MIME encoding should check the Content-Type and Content-Transfer-Encoding strings to ensure their program can interpret them correctly: if it can't, an Ftn-Error response is required with the UM (unsupported MIME format) error. If the guidelines given here are followed explicitly, there should be no problems. Developers who want to provide more MIME support in their programs are encouraged to examine the MIME RFCs (RFCs 2045-2049), especially 2045, to ensure their program is compliant. The MIME RFCs can be found at http://info.internet.isi.edu:80/in-notes/rfc/files. For ease of implementation, developers must ensure that the Content- lines are sent in the order given above. 7.3 Optional keywords --------------------- 7.3.1 Transmission keywords --------------------------- Ftn-Freq: FILEMASK.EXT This line allows for standard file requesting. The format of FILEMASK.EXT may contain any valid DOS filename or wildcards, and may be accompanied by a password such as: Ftn-Freq: THEFILES.RAR |PASSWORD The | character is not part of the password itself, but rather a seperator between the filename and password. The single space between the filemask and password is required, and must not be more than one single space. Please note that this file name/mask may include long file names as used in more advanced operating systems. Although the FILEMASK.EXT may match more than one file locally, only one FILEMASK.EXT at a time may be provided after the Ftn-Freq. Ftn-Auth: c349f4d113a4d38afd5327c3328d6c37 This field can be used as both error detection and authentication for messages sent. The field's value is the MD5 digest of the file enclosed in the message, printed in hexadecimal. (Developers are referred to RFC 1321 for an implementation of MD5.) Nearly all errors in transmission will be detected by discrepancies in the value given here and the one calculated on the reconstructed message. This field can be used in addition to the Ftn-Crc32 field for verifying a file has arrived intact. It should not be used in replacement though, in case the receiving system doesn't support the Ftn-Auth keyword. The Ftn-Auth value can also be used by systems to setup a system of authentication of messages. Two systems wanting to make sure files are transmitted unmodified and from the source they say they're transmitted from can establish a session level password. The digest value is calculated on a string formed by adding the file's bytes to the end of the session level password. Session level passwords should be case and space sensitive. They must match exactly. This is to discourage would-be forgers from trying to find the password by brute force. It is suggested, but not required, that passwords be at least 10 characters long, again to discourage brute force attacks against them. Ftn-Crypt: Blowfish Systems wishing to establish even more secure connections can use encryption to hide the contents of the files they are transmitting. The Ftn-Crypt field's value is the name of the encryption algorithm used. Suggested implementations include Blowfish IDEA DES PGP2 (PGP version 2.x or lower) PGP5 (PGP version 5.0 or higher) There may still be implementation differences beyond just the algorithm used, as most allow different block sizes and stream types. In order to ensure that one implementation can talk to the other, block based encryption algorithms (such as Blowfish, IDEA, etc.) must use 64 bit blocks and CFB encoding. Because encryption replaces the files with encrypted copies, the CRC and MD5 digest values generated in the Ftn-Crc32, Ftn-Part-Crc32 and Ftn-Auth must be calculated to match that of the actual file transmitted. That is to say, first the MD5 and CRC values are calculated, and then the file is encrypted. This allows implementations to detect files corrupted by both transmission errors and bad passwords. The response to either type of error is still an Ftn-Receipt: NACK line. The main point of attack on most of the encryption algorithms used will be a brute force attack on the password, where applicable. In systems which use passwords, the two systems must use passwords which match exactly, case-sensitively. (i.e. the password Something would not work to decrypt a file encrypted with the password something.) Systems can introduce their own encryption algorithms if they so desire, but when using the Ftn-Crypt line, their strings must be preceeded by X-. For instance, one value might be Ftn-Crypt: X-Mycrypt If a system supporting the Ftn-Crypt field receives a file encrypted with an algorithm it doesn't recognize, it should respond with an Ftn-Error: CA line. (See the Ftn-Error section for more details.) 8. Last Notes ------------- The control lines and format outlined in this document must all be followed correctly. All control lines for a given level should be present (regardless of whether or not you feel they are required). Even in the case of a single non-split message, the control lines should all be in place to make parsing easier, and to assure all software receives all the information it may require to function. Also, it is imperative that all implementations provide basic uuencoding as the bare minimal encoding method. A. References ------------- JAM "Joaquim-Andrew-Mats Message Base Proposal" Revision 1, 1993. ISO 3309 International Organization for Standardization, "Information Processing Systems--Data Communication High-Level Data Link Control Procedure--Frame Structure", ISO 3309, October 1984, 3rd Edition. ITU-T V.42 International Telecommunications Union, Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion, ITU-T Recommendation V.42, 1994, Rev. 1. RFC 1952 "GZIP file format specification version 4.3" RFC 2823 "PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing" Williams93 "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" version 3. Ross N. Williams, 19 August 1993 ftp://ftp.rocksoft.com/papers/crc_v3.txt B. Author contact data ---------------------- Charles Cruden Fidonet: 1:342/806 C. History ---------- Rev.1, 20040515: Initial release (was: FSP-1015.001). FTSC changes: * Fixed formatting & removed FSP annotations. * Added references for CRC32 algorithm. * Removed obsolete author contact information. **********************************************************************