**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1015
Revision: 1
Title: Simple E-Mail Attach Transport (S.E.A.T.)
Author: Charles Cruden,
Vincent Danen,
Brent Shellenberg
Ramon van der Winkel
Revision Date: 20 April 2000
Expiry Date: 20 April 2002
----------------------------------------------------------------------
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 Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
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. Unlike other
technical documents, this approach makes it easier to get a visual
idea of how the whole thing works. Any paragraph that contains a
pipe character (|) prior to the start of a line, indicates that the
information in that portion of the document is new to this revision.
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 <
[email protected]>
To: Steven Lager <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:26:47
Organization: GUNN Data Systems
Reply-To: Brent Shellenberg <
[email protected]>
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:
[email protected]
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/<AWIM2M;#<_*:]
M:=6FT+I2C:SAX]OAC8.(D('O.Y(TN)95S6'E2N@KO2/Z<'<O3;569"T!8"X?
MPR01',XNZ&@P^LP"RB83.&,3,ADX$AP$P9L/`Q^6;;6M&@[9]\4"9M)($`=M
MBCL-%B+U3AJEFB&(G3W_P_]'Q`$6:;H(DA^=LD[5B$)D=P;1A?6CRR[$/H5.
MYCC_<LS#]J=?`5!+`0(4`!0````(`%834".2#K[O=0$``#("```,````````
M``$`(``````````R,S4P,3,U0BY02U102P4&``````$``0`Z````GP$`````
`
end
--snip--
5.2 Breakdown Of The Above Example
----------------------------------
5.2.1 Message Subject
---------------------
The message subject must always start with "FTN Mail Transport".
Software should treat it case insensetively, and implementations
may place anything extra after the string.
Basic: Subject: FTN Mail Transport
Modified: Subject: FTN Mail Transport - Sysop's Tech Net
Mailer software (and encoders/decoders) should simply ignore
anything after the basic subject line text.
5.2.2 Control Information
-------------------------
In order for mail to be acknowledged as received, or in order to do
other system level operations on the received files, control lines
are required. These lines are placed in the message body, and must
always be treated case insensetive. All Ftn-* lines must occur
before the actual file to be transmitted. Because certain lines
are optional and certain lines can occur more than once, order is
not important: it is suggested though that implementations follow
the order given in this document wherever possible. There must
additionally be no extra text between the last Ftn-* line and the
headers indicating the start of the encoded file. Blank lines may
be inserted, but that is all.
Systems may choose to place text in the message before the Ftn-*
lines. No more than 10 lines of text should be given though, and
none of the lines may start with Ftn-.
5.2.3 Transmission keywords
---------------------------
These are keywords used in the transmission of files.
Ftn-File: AA3D1EAC.TH0
This is simply the filename of the file that is attatched to the
message. Though this may seem redundant, it will allow for quick
and easy parsing of the message body for the received filename.
Long filenames and non-DOS filenames are permitted. Systems
running under DOS should munge the filename to something
appropriate and inform the user of the original filename. When
sending the filename, the case and spacing provided after Ftn-File
must exactly match that of the file on the original filesystem.
Ftn-File-Id: AA3D1EAC.TH0.876796006.50DC7A2B
The Ftn-File-Id line is a free form text string that identifies a
complete file. It must be a unique string for each file sent from
a system, and is generally used for requesting the complete resend
of a file (explained in the section describing NAKs below).
Ftn-Crc32: 50DC7A2B
The value after the control string is the calculated Crc32 value
(hexadecimal) of the entire file (fused back together). This is
provided largely for multipart file attachments, but must be
present for all attachments to make parsing easier.
The CRC value expected here is one which does NOT invert the bits
at the end of calculation. Implementers are referred to the CRC
routines provided as part of the JAM API for sample
implementations. These can often be located in a file called
JAMAPI.ZIP.
Ftn-Encoding: uuencode
The Ftn-Encoding line is a simple line that declares the type of
encoding used for the attachment. This is provided for simplicity
reasons (in parsing the e-mail message) as well to draw some
boundaries of what is required for a certain standard level. The
following values are valid for this (and future) revisions:
uuencode
Base64
If a system doesn't support the encoding given in this line, it
should respond with an Ftn-Error line and the error code UE
(unsupported encoding).
Ftn-Seg: 1-1
This identifies the number of "parts" in which attached file is
being sent. The values make up a descriptor of what file segment
is being received from how many parts. For instance, 1-1 simply
means the attached file segment is 1 of 1 (so no further segments
will follow). If the value was 2-5, this would mean the contained
segment is part 2 of 5.
Ftn-Seg-Id:
[email protected]
The Ftn-Id line is a unique identification line for a file part
that is used primarily to send acknowledgements back to the
sender. The actual method the developer may use to create this
line is purely up to the imagination. It is intended to be a free
form text string that is simply "copied" for use in ack messages.
Ftn-Seg-Crc32: 50DC7A2B
This line contains the calculated Crc32 value of the file part
that is contained in the message. Unlike the Ftn-Crc32 line, this
is ONLY for the encoded piece that is contained within the single
message.
5.3 Large File Splitting
------------------------
Splitting of files MUST be done prior to the creation of the
encoded message. The uuencoding or Base64 methods described for use
with this revision are not to have any splitting/fusing method of
their own. Simply chop the file up into multiple temporary files,
and encode each seperately. Not all systems will require that the
files be sliced, but some may. This option (of splitting in general)
should be adjustable by the system operator. Also keep in mind that
those that are using standard e-mail clients to decode the inbound
mail packets will probably not be able to fuse the files back
together. An option for not splitting large files is therefore good
practice.
5.4 Additional Message Body Text
--------------------------------
It would be desirable to have implementations avoid placing too
much "noise" in the message text body (ie: advertisements or other
text that is not relevant to the transfer of the file attachments).
Since this method of transport is generally going to be done by
automated encoders/decoders, it probably won't be seen anyway, so
it would merely be a waste of space in the users' pop mail boxes.
5.5 Receiving files under DOS
-----------------------------
Implementors of a S.E.A.T. compatible mailer for DOS should note
that the Ftn-File line provides for the possibility of long
filenames being sent. Since DOS doesn't provide support for files
outside its 8.3 filename format, a way of mungeing filenames from
long to 8.3 name formats must be provided. It is recommended,
though not required, that a format similar to the Win95 method of
mungeing files is provided. The first six valid (under DOS)
characters of the filename form the start of the new filename.
These are followed by a dash (-) and a number (0 through 9). If
there is a period (.) in the original filename, the first three
characters following the last period form the extension of the new
filename. When the mungeing process results in a filename that
already exists, the number should be incremented until there is no
conflict. Each additional digit in the number means one less
character is taken from the start of the original filename.
If the original filename fits into the 8.3 format, it should be
used.
Some examples:
Original name Munged name
MailForYou.Zip MAILFO-0.ZIP
Bobs Your Uncle BOBS-0.
LOTS.O.DOTS.ZIP LOTS-0.ZIP
053F31CD.MO0 053F31CD.MO0
6. Recommended implementation
-----------------------------
S.E.A.T. level two provides a means for reliably transferring files
through email, ensuring that except in the case of a long term mail
problem, all files sent will arrive at their destination without
modification. S.E.A.T. level two also provides support for error
detection and correction in the S.E.A.T. keywords of a given
message, vital to supporting the optional keywords in levels three
and above.
S.E.A.T. level two defines the following keywords:
Ftn-Date
Ftn-Receipt
Ftn-Cancel
Ftn-Error
6.1 Transmission keywords
-------------------------
Ftn-Date: 34C7D356
The value after the control string is the UNIX time/date stamp of
the file as stored on the sending end's system, printed in
hexadeciaml format. This may be used by some implementations to
re-stamp file dates on the local system.
6.2 Response keywords
---------------------
These control lines are sent in response to files sent by other
SEAT mailers. They may be sent alone, or as part of the control
lines preceeding a transmitted file.
6.2.1 ACK Example (Single ACK)
------------------------------
Acknowledging a received section of a file is a simple task. The
Ftn-Seg-Id line (described above) is all thats needed to return an
acknowledgement.
Example (ACKing the above attachment example):
--snip--
From: ARCmail <
[email protected]>
To: Brent Shellenberg <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:30:00
Organization: Some Guy's BBS
Reply-To: Steven Lager <
[email protected]>
X-Mailer: INetFTN v0.01-Beta
Ftn-Receipt:
[email protected] 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 <
[email protected]>
To: Brent Shellenberg <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:30:00
Organization: Some Guy's BBS
Reply-To: Steven Lager <
[email protected]>
X-Mailer: INetFTN v0.01-Beta
Ftn-Receipt:
[email protected] Ack
Ftn-Receipt:
[email protected] Ack
Ftn-Receipt:
[email protected] Ack
Ftn-Receipt:
[email protected] 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 <
[email protected]>
To: Brent Shellenberg <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:30:00
Organization: Some Guy's BBS
Reply-To: Steven Lager <
[email protected]>
X-Mailer: INetFTN v0.01-Beta
Ftn-Receipt:
[email protected] 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 <
[email protected]>
To: Brent Shellenberg <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:30:00
Organization: Some Guy's BBS
Reply-To: Steven Lager <
[email protected]>
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 <
[email protected]>
To: Steven Lager <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:30:00
Organization: GUNN Data Systems
Reply-To: Brent Shellenberg <
[email protected]>
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 <
[email protected]>
To: Steven Lager <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:26:47
Organization: GUNN Data Systems
Reply-To: Brent Shellenberg <
[email protected]>
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:
[email protected]
Ftn-Seg-Crc32: 50DC7A2B
Ftn-Receipt:
[email protected] Ack
Ftn-Receipt:
[email protected] 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/<AWIM2M;#<_*:]
M:=6FT+I2C:SAX]OAC8.(D('O.Y(TN)95S6'E2N@KO2/Z<'<O3;569"T!8"X?
MPR01',XNZ&@P^LP"RB83.&,3,ADX$AP$P9L/`Q^6;;6M&@[9]\4"9M)($`=M
MBCL-%B+U3AJEFB&(G3W_P_]'Q`$6:;H(DA^=LD[5B$)D=P;1A?6CRR[$/H5.
MYCC_<LS#]J=?`5!+`0(4`!0````(`%834".2#K[O=0$``#("```,````````
M``$`(``````````R,S4P,3,U0BY02U102P4&``````$``0`Z````GP$`````
`
end
--snip--
6.2.5 Errors
------------
Errors may occur when the message generated at one system uses
features which aren't available on another (for example using
an encoding type that the other doesn't support). In this case,
the system which generates the error should respond with an
Ftn-Error line. The syntax of an Ftn-Error line is
Ftn-Error: <error code> <parameter>
where <error code> is one of the following codes, and <parameter>
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 <
[email protected]>
To: Brent Shellenberg <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:30:00
Organization: Some Guy's BBS
Reply-To: Steven Lager <
[email protected]>
X-Mailer: INetFTN v0.01-Beta
Ftn-Error: UE
[email protected]
--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 <
[email protected]>
To: Steven Lager <
[email protected]>
Subject: FTN Mail Transport
Date: Thu, 16 Oct 1997 02:26:47
Organization: GUNN Data Systems
Reply-To: Brent Shellenberg <
[email protected]>
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:
[email protected]
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=<boundary string>
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 <boundary string>.
Other changes required to an e-mail message to make it MIME
compliant:
Following the Ftn-* control lines:
--<boundary string>
Content-Type: application/octet-stream; name=<filename>
Content-Transfer-Encoding: Base64
Content-Disposition: inline; filename=<filename>
(Base64 encoding of the file part goes here)
--<boundary string>--
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: <Id> 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. Author contact data
----------------------
Charles Cruden
Fidonet: 1:342/806
E-mail:
[email protected]
Vincent Danen
Fidonet: 1:140/14
E-mail:
[email protected]
Brent Shellenberg
Fidonet: 1:229/606
E-mail:
[email protected]
Ramon van der Winkel
Fidonet: n/a
E-mail:
[email protected]
B. History
----------
Rev.1, 20002004: First release as FSP
**********************************************************************
