Example:

        1:140/146 fidonet.org 04:21:1997 1

      MsgCount is a simple message counter that the system could keep,
      incrementing it for each message that is exported. The message count
      could be zeroed at the start of a new day. This is just an example
      of a possible implementation.

    EchoArea (Open String Type)

      This field in the PKT header replaces the traditional AREA:
      kludge that was required by older systems. This makes the PKT format
      a true echomail system, and not just an echomail system built on
      netmail formats. For netmail messages, this field should be blank, or
      may contain "NETMAIL" as the EchoArea. Reserved EchoArea names:

        ,
        NETMAIL         - FTN style netmail (point to point)
        EMAIL           - Internet style email (possibly gated)

    SeenBys (Word)
    Paths (Word)

      Paths and SeenBys are stored after the message header in binary form.
      These two variables instruct the processing software as to how many
      seenbys and paths it should read from the end of the header. There
      will always be at least one path and two seenbys. A path is a system
      that the message has passed through. A seenby is a system which has
      already received the message. Paths help in tracking down logical
      errors (circular references) in which messages get exported back to
      a host by a receiving system, and seenbys help cut down on duplicate
      mail being sent to a system.

    TextBytes (Longint)

      This tells processing software how many bytes the message text
      occupies. This is used for quick loading of messages.


PKT Makeup
----------

  A transported PKT is a single file that contains a main packet header
  (TYPE Type2000Header) and contains one or more echomail or netmail
  messages. Each echomail message consists of a packed message header
  (TYPE Pakd2000MsgHeadr), followed by 1 or more binary paths (stored
  as TYPE NetworkAddress), followed by 2 or more binary seenbys (stored
  as TYPE NetworkAddress), followed by a message text body (which may
  contain zero bytes). The seenbys do not need to be ordered. They may
  be simply appended as a message passes through a series of systems.
  Paths should also be simply appended, to preserve the correct path the
  message travelled. Seenbys may be stripped by any host to reduce
  bandwidth. A host is defined as the mail carrier from one net to another
  net. Doing this, of course, places the blame for problems (dupe loops)
  directly on the host.

    Recap of a transport PKT:

      Control header -- Type2000Header
                     +- Pakd2000MsgHeadr
      Actual message |  NetworkAddress x Number Of Paths
                     |  NetworkAddress x Number Of SeenBys
                     +- MessageTextBody

  Certain fields in the Pakd2000MsgHeadr should be "zeroed" (set to nul)
  on export to another system. These include:

    ReplyTo          : Open String Type; {If the message is not a reply}

  Additional message attributes should also be zeroed. These include:

    FAttribute       : Byte; {1 - IsKillSent
                              4 - IsTruncFile
                              5 - IsKillFile}
    GAttribute       : Byte; {1 - IsLocal
                              2 - IsSent
                              4 - IsReceived
                              5 - IsOrphan
                              6 - IsDeleted}

  The filenaming convention for exported message packets should be
  .P2K. The  portion is left to the imagination of
  the developer, but a suggested method would be the Crc32 string of
  the unix date stamp of the file creation. This is just an example,
  and there are far more complex and better ways of doing this that
  are beyond the scope of this document.


Implementation Hints And Suggestions
------------------------------------
Firstly, do NOT place out of date FTN style kludges in the message body.
Implementations should pay no mind to any that happen to show up (due to
another implementation not following this document). The following are
the kludge lines referred to:

  AREA
  SEEN-BY
  PATH
  INTL
  FMPT
  TOPT
  REPLY
  MSGID

All these kludges are replaced by appropriate message header fields, thus
allowing processor software to quickly parse a received message. Also,
the addition of binary 4D paths and seenbys that follow the message header
are more complete than existing practice of the net/node 2D combination
used by older FTN software.

Other kludge lines (such as PID and TID) are still valid, and may
be used by any or all implementations.


Contributors/Software Details
-----------------------------
Developers are encouraged to use this proposal, as well as take part in its
future modifications. Please contact one of the main contributors for
information on aiding in the cause.

This proposed standard is being implemented in the following software:

  Application   Author                      Description
  ----------------------------------------------------------------------
  Shotgun       Brent Shellenberg           BBS software package with
                (brents{at}shaw.wave.ca)       echomail processor, front end
                                            mailer and TIC processor.
                                            Shareware.
  WaterGate     Ramon van der Winkel        FTN/usenet/email processor
                ramon{at}wsd.wline.se          and gateway software package.

Other authors - please contact one of the contributors of this document with
your name, e-mail address, the name of your software, a brief description and
the software status (freeware, shareware etc.).
=== Cut ===

  Vincent Danen (vdanen{at}stnnet.ml.org) . Sysop's TechNet IC
  AllFix/2 Beta . WaterGate/2 Beta . Internet Rex Beta . BBBS/2 Beta
  PGP Fingerprint: 0D 78 A1 58 03 AF 12 7D  9E 08 88 0B 71 9A DC B1

... I haven't had sex in so long, I forget who gets tied up!

--- WaterGate/2+ v0.94.PRE12