Here's my take on developing FidoNet compatible NetMail and EchoMail
software, and basically what I did.

=====

0) When starting, use only the FTS documents but read all the
others just to get ideas and to see how other people think about
coding and FidoNet.

1) Assume all definitions and examples^* as mandatory.  This, I
believe, is important.  I do not listen to the people who say
"it is not stated as mandatory. . ."  That is a poor argument
as I see it.  For example, FTS-0001 does not say that the
"Application Layer Data Definition : a Stored Message" header
format is mandatory, but it most certainly is!  Think of everything
not explicitly stated as optional as mandatory.

^* Note: read the docs carefully! FTS-0001 does not really give
explicit examples of kludges, they can be considered not examples
but definitions only (or faulty examples, depending on your point
of view).

2) Assume case is significant and use only the exact case of the
given examples.  Again important.  If case is not significant, then
there is no problem.  If case is significant and you think it is
not then things may not work properly or at all.

3) When the FTS says that "there are deviations from the
standard. . ." DO NOT WRITE MESSAGES with those particular
deviations, use the standard.  But you might want to consider
being able to READ MESSAGES with those deviations (I chose not
to and have not run into any problems, yet).

4) Always write the full header information (re: Stored and Packed
Mesages), but DO NOT COUNT ON ALL INCOMING MESSAGES TO ADHERE TO
THEM! (more on that later)

5) Always write the kludges and Control Lines only as described,
but DO NOT COUNT ON ALL INCOMING MESSAGES TO ADHERE TO THEM!

6) Do not consider the EchoMail Area, Tearline, Origin and Seen-bys
as kludges!  They are Control Lines, but they differ from actual
kludges.

7) Consider the order of EchoMail Control Line placement mandatory.

8) Put all kludges before the text body in NetMail, and before the
text body but after the AREA Control Line in EchoMail.

9) Do not assume all incoming messages are correct.  This is, as
I found out, very important, but, barring corruption, the only
things that I have seen wrong are the '|' marked offests in the
Stored Message header, ill-formed MSGID and non-standard kludges,
and missing Tearlines.

For EchoMail I do not even bother with the Stored Message header,
I discard it.  For NetMail I ignore the '|' marked offsets in the
Stored Message header and use the INTL kludge to get the full
orginating address.  (When writing NetMail I write the proper
header _and_ use the INTL kludge, even for local messages.)

For kludges, check for spaces and no spaces on either side of the
':' character, and then check for lack of the ':' character.  (At
least everybody seems to use the ^A!)

No big deal about lack of a Tearline, just be sure that you can
handle messages without one.

I have never seen a message without an Origin, but if you parse
it, do not assume proper use of paranthesis.

=====

In a nutshell, that is all you have to do to get things to work
_PROPERLY_.  Perhaps some of my messages do not make it out to
all nodes, how can I ever know?  (I've tried putting: "If you do
not recieve this message please let me know." in the text but
nobody ever complained :-)

I have not once failed to properly handle 100% of all my incoming
Mail (with the exception of having to code "work arounds" to deal
with ill-formed and corrupt messages).  Which reminds me of another
very important item: copy all incomming packets to an archive
directory in case things go wrong so you can fix your code!

Perhaps others have different "dos and don'ts", and certainly
people have differing views about what to expect and to put
in Mail.  Basically, this is how _I_ do it, and it just may not
be the way others want to do things.

Also, I may have introduced typos and/or mistakes while typing
this.

--

--- A Perl Script