One, two, three, four, one, two...
 Let me tell you how it will be, All.

=== Cut from fsp-xxxx-2.001 ===
    3.2.6. Flags:

    Flags:  field is used for  changing  status  of  the  netmail
letter. Flags: field has special structure:

    Flags: FlagField [...],

    where FlagField = 3 ASCII characters.

    There can be _unlimited_ number of flag  fields  in  "Flags:"
field. Flag fields are case unsensitive.

    FTSC can add another flags, but basic flags for netmail are:

    Flag     Brief      Long Description
    --------------------------------------------------------------
    PVT      Private    Indicate that the message may be read only
                        by its addressee and author, and should
                        not be quoted anywhere.

    HLD      Hold       Message should be held for pickup by its
                        destination system.

    CRA      Crash      High-priority mail.

    LOW      Low        Low-priority mail.

    K/S      Kill/Sent  Remove message after it has been success-
                        fully sent.

    DIR      Direct     Message must be sent directly to its
                        destination and may not be routed.

    HUB      Hub/Host   Host- or Hub-route message (if available).
             route

    FIL      File       Message has one or more files attached to
                        it.

    IMM      Immediate  NOW!-priority mail. Mail with this flag
                        should be sent immediately, and override
                        any restriction, f.e. worktime and cost of
                        it.

    XMA      Xmail      Message can be sent in compressed form
                        (in a bundle).

    KFS      Kill file  Remove attached file(s) after they have
             sent       been successfully sent. Valid only for
                        message with FIL flag.

    TFS      Truncate   Truncate attached file(s) to zero length
             file sent  after they have been successfully sent.
                        Valid only for message with FIL flag.

    RRQ      Receipt    Request to send another message back to
             Request    the originating system, if message
                        reached its final destination.

    ARQ      Audit      Request to send another message back to
             Request    the originating system from any system
                        received this message, including
                        final destination.

    CFM      Reading    Request to send another message back to
             Comfirm    the originating system when message
             Request    was read by receiver.

    (thanks to Joaquim H. Homrighausen)

    Example:

    Flags: DIR PVT
    Flags: ATT CRA
    Flags: PVT RRQ CFM

    3.2.7. Attach:

    This field indicates files, attached to the message (they are
sent outside the message one). Syntax:

    Attach: filename DOSFILENAME [...]

    Where filename is a name of the file,  as on the  originating
system.  DOSFILENAME is used for system supporting only 8.3  case
unsensitive  file  system  (f.e.   FAT  under  MS-DOS).   It   is
recommended to send files with MS-DOS 8.3 standard  only  between
the systems. 8.3 filename should be upcased.
    If filename contains spaces it should be quoted.

    Example:

    Attach: linux.kernel.tgz KERNEL.TGZ XServer.tgz XSERVER.TGZ
    Attach: "MS-DOS based file.doc" MSDOSB~1.DOC

    3.2.8. Received: field.

    This  field  describes  system,  which  message  have  passed
(received  by  it).   This  field  usually  inserted  by  tossers
unpacking netmail. Syntax:

    Received: "From" FromAddress "by" ToAddress
["with" ProgID]

    Where:

    FromAddress -- address of the  transit  (originating)  system
message received from.
    ToAddress -- address of the current system.
    ProgID -- ID of the  program.  This  field  can  contain  any
information.

    Example:

    Received: From 2:5020/1159 by 2:5020/1301 with SomeMailer/NT


    4. Echomail message and it's header fields.
    -------------------------------------------

    There is  number  of  basic  and  advanced  fields,  used  in
echomail message.

    4.1. Basic fields.

    4.1.1. From: field.

    Syntax and purpose of From: field is the same as in 3.1.1.

    4.1.2. Message-ID: field.

    Syntax and purpose of Message-ID:  field is the  same  as  in
3.2.1.  Note,  that  Message-ID:   is  an  _required_  field  for
echomail.

    4.1.3. Conference: field.

    This field describes name of the conference  message  belongs
to. Syntax:

    Conference: Name

    Where Name should be upcased and contain  ASCII  alphanumeric
characters.

    Example:

    Conference: ENET.SYSOP
    Conference: SU.FIDOTECH
    Conference: LONG.NAMES.OF.CONFERENCES

    4.1.4. Date: field.

    Syntax of the Date: field is the same as in 3.1.3.



    There are all fields required to _form_ an echomail  message.
See section 4.3 to know more  about  Path:  and  SeenBy:  special
fields.

    4.2. Additional fields.

    4.2.1. Comment-To: field.

    This field describes author of message, which is replied. Its
syntax is:

    Comment-To: Name []

    Where Name is the name of the  author,  and  address  --  his
address, if available. ESCaping is like in From: field.  Assumed,
that message is addressed to 'All',  if no Comment-To:  field  in
echomail.

    4.2.2. Reply-ID: field.

    This field contains Message-ID:  field content of originating
message.

    4.2.3. Subject: field.

    This field contains subject of the message

    4.2.4. Comments: field.

    Syntax of this field is the same as in 3.2.5.

    4.3. Special fields.

    Special fields are Path:  and SeenBy:.  This fields are  used
for control all over echomail distribution because of echomail is
a wide-distributed system.  SeenBy:'s prevent system pack mail to
the systems already in the list, Path:  is used to visual control
of echomail routing.

    4.3.1. SeenBy: field.

    SeenBy:  field is used to prevent  message  being  packed  to
node, already received it from another place. SeenBy system allow
to build different routing shemes.

    Syntax:

    SeenBy: Address [ [...] [ShortAddr [...] ] ]
    [SPACE Address [ [...] [ShortAddr [...] ] ]

    SeenBy: is several-string field.

    SPACE is an ASCII space (20 HEX, 32 DEC).

    Address is an _3D_ FidoNet address.  ShortAddr can be written
in a more simplified  form,  f.e.  without  network  and/or  zone
information,  if it information can  be  solved  from  previsious
items. Length of each string of SeenBy:  field,  including first,
can't be more than 80 symbols.  Addresses in this field should be
ordered in zonal-network-nodes numeric order, less numbers should
be placed first.

    Example:

    SeenBy: 1:23/23 237/72 128 2:5020/1159 1160 5051/16 67 88

    This field show, that message was packed to such systems:
    1:23/23, 1:237/72, 1:237/128, 2:5020/1159, 2:5020/1160,
    2:5051/16, 2:5051/67 and 2:5051/88.

    4.3.2. Path: field.

    Path:  field is used more for visual control of  distribution
of echomail messages than for technical purposes (like  Received:
field in netmail).

    Syntax:

    Path: Address [[...] [ShortAddr [...] ] ]

    This field is one string field.  Address is full 3D  address,
ShortAddr can be shorted,  if  information  can  be  solved  from
previous items.

    Example:

    Path: 2:5020/1159 1301 2:5051/16 5:123/43 128/41

    This show that message passed four  systems  before  reaching
128/41.


    5. Message body.

    There is no any special restriction of message body  content,
for example for 7 and 8 bit characters, and so on, only one.
    Point mark ('.',  ASCII 2E HEX) is used in packet  to  divide
one message from another,  if it is used  in  first  place,  i.e.
CRLF.CRLF marks end of message (EOM).
    Point itself,  if should be used in first  field  of  message
should be ESCaped as an ESCape char.

    ESCape seq.    ASCII char
    -------------------------
    \.             .
    \\             \

    Example:
    =======
    From: Gennady Kudryashoff 
    To: John Gladkih 
    Date: 23/03/1999 23:03:00 +0300

    Some text.
    \.
    \\Another text.
    \.
    .
    =======

    After parsing message body looks like that:

    =======
    Some text.
    .
    \Another text.
    .
    =======

    6. Packet.

    6.1. Packet types.

    There is two packet types.  You can use netmail  or  echomail
packet.  So every packet can contain messages of only  one  type.
There is no  differences  between  echomail  and  netmail  packet
structures.

    6.2. Name convention.

    Packet can be  named  as  8.3  DOS  file,  in  case-sensetive
environments, like *NIX systems, this file is upcased.  Extension
of packet file is 'FP'.  Name alphabet is  an  hexadecimal,  i.e.
0..9 and 'A'..'F' symbols.
    Packet name generation is simply random generation, but names
can't be repeat (for one system to another transmit) for one year
at least.  Netmail packets for BSO systems  can  be  named  under
unixtime.

    6.3. Packet structure.

    Packet consist of header and a unlimited number of  messages.
Empty packets are not allowed. Header and messages are divided by
empty string (i.e.  CRLFCRLF).  Every message  is  finished  with
point ('.') mark, next string should be header of next message or
EOF (or nothing).

    6.4. Packet header.

    Packet header consist of four fields.

    6.4.1. From: field.

    This field contains the originating system (i.e.  originating
for packet) address. Syntax:

    From: Address[{at}domain]

    Where address can be 3D or 4D.


    6.4.2. To: field.

    This  field  contains  the  destinating  system  for   packet
address. Syntax:

    To: Address[{at}domain]

    Where address can be 3D or 4D.

    6.4.3. Date: field.

    This field contains packet's last  update  date.  This  field
form like Date: field in 3.1.3.

    6.4.4. Password: field.

    This field contains password for packet.  It can be 8 upcased
symbols maximum. Syntax:

    Password: password

    6.4.5. Example of packet.

    =====
    From: 2:50/59{at}FidoNet
    To: 1:234/34
    Date: 23/03/1999 23:03:00 +0400
    Password: SOMEWORD

    Received: From 2:5020/1301 by 2:50/51 with SomeMail/NT
    From: Dmitry Bredikhin 
    To: Sysop 
    Message-ID: FAFFF_ROBOT_1288Gahgfsgf{at}2:5020/1301
    Subject: Something else?

    Your system is not listed in my FRIP routing  sheme.  Please,
    update your routings.
    .
    Received: From 2:463/23 by 2:50/51 with SomeMail/NT
    Received: From 2:473/91 by 2:463/23 with SquishII/OS2
    From: Alexander Malikov 
    To: Vlad Malev 
    Message-ID: 88nanhashhsjaw{at}2:473/91.23
    Reply-ID: USAMAIL_88s9asah{at}1:238/4.3{at}fidonet.org
    Subject: Re: Independent media?

    VM> May be, I should call you?

    Of cource, you can. Please, see our pointlist.
    .
    =====


**********************************************************************
=== Cut from fsp-xxxx-2.001 ===

* Crossposted in NET_DEV
    Gennady Kudryashoff.                            [Team The Beatles]
--- E-Mail: genka{at}bum.elektra.ru