It probably needs complete rewrite :-)

Protocol module seems to need improvement, specially startup sometimes
seems to be rough. I also tried to work with opus without any kind of
front end as v32 modem I had took too long time to time out and
binkley started to opus, but protocol startup failed, it got one
packet but then started complaining about funny packet numbers and I
havent had time to check it out.

Batching news would improve performance a lot, though I guess rewriting
funpack would save even more.

Point and zone addressing should be done. It knows zones but looses
the info when packing. I'll rewrite packer to get some routing stuff
in and I try to get that done same time. If zones are important you might
get around limitations with sendmail or customizing smail or like.

Forwarding to other fidonet nodes should be implemented? It would be
better to pick message as is, just change from and destination node
addresses and stick it to packets needed, which would create blazing
fast redistribution. Going through news would be cpu hogger never seen
as theres very little advantage.

Ffgets still does need more tuneup: Sometimes I received messages with
soft crs and no blank. So, if lines get combined, a blank should be
inserted if soft cr is found. I think according to fsc-001 its really
the problem in someone elses software, as fsc-001 says that soft crs
etc should be ignored, not replaced with (single) blank. but I think
it would be better to accept that format also.

Message-id should really be something which could allow noticing
duplicates.  maybe date and node number could be used.

Date length problem is still open, is it 20 chars like in fsc-001 or
19 like in all messages I receive (via confmail)?

Fcall xmodem receive is horrible cpu hog. I have to profile it and see
whats happening, probably readline?

I/P packets could be in subdirectories or even node structure

could be built for spool directory like

...fnet/I/2/504/1/0   2:504/1.0
...fnet/I/2/504/26/0  2:504/26.0
...fnet/I/2/504/26/2  2:504/26.2

Message body should be checked out for control chars and ibmscii. I have
a separate filter which takes care of that, I just have
to install it, so wait for the next version.

RECEIVE_PATH could be fidonet path, not symbolic as it is now, I have
to check out if news, mail etc accept addresses which start with a number.

If fnews.cf has errors in newsgroup flags, it will coredump. One should
check those strtoks there.

When receiving new echo area, it should be automatically added
to fnews.cf, and su newsuser /usr/lib/news/inews -C fidonet.echoareaname
should be called.

HDB uucp seems to be able to kill fcall calling out? Lock file is uucp
mail, is in /usr/spool/locks (svr3) and has process id in it with 10 chars
and \n at end.

rfmail could accept any kind of fidonet address, like
sysop-name.fidonet, system-name.fidonet and such things. Though, this
would require some artifical intelligence!

Processing private echo messages could be changed, now it tries to send
them to local user, failing in parsing address and sending the stuff to
uucp or root. Use accept-private and trash-private to get around this.

Configure-script? have to check out it there is public domain one?
Yes there is, it just came over usenet but I haven't tried it yet.

There should be a configuration file for everything, not it needs
recompilation for just about everything.

Nodelist and Index files are in memory, this will break up the roof in
brain-damaged architectures. There should be an option for making
indices disk-resident if user wants it. Biggest problem is the name
list, it could be rewritten to use char * for names insted of
constant-length name. With current nodelist of about 4000 nodes, it
will be > 150 k. Disk-resident would be nice but I haven't got
mergesort/disky qsort/disky bsearch around so I skipped it.

From: field should really be identical to Reply-To: field and latter
could be removed. On the other hand, there would be info about from
which echo feed it came from, but that should be separate field. I'll
leave it as is now, comments?

I will try to build routine capable of reading list of names with
fidonet numbers to use for finding out mail address, so lists like
FFUA (Finnish Fido Users Association) membership list could be used.

Generally all fields could follow rfc822 spec from FSC documentation
but it has some problems with news: No spec for newsgroups statement
and areas conversion. Most echomail names still are just names, like
C_ECHO and so on, if people had been using fidonet.something from the
beginning, things would be easier. I tried to push it through, so its
used in Finland, and in some conferences in Europe, most notably in
Enet.sysop I started in Europe when I first time got my hands on
echomail :-)

In-Reply-To: could be set to what is in FSC-Control: EID: xxxx , but I
have to find out more about EID: mechanism before I get into it.

Now it uses Comment-To: to set up receiver field, node address is
either the one in nodelist or * origin. Origin probably bad guess but
that's all we have got! For this reason, storing information about
receved fidonet addresses would be good idea.

Some people may get theirs reply-to field to point to node first found
in nodelist, even if they want to get mail to some other node.

There would be another solution for reply-via mail. If it doesn't find
correct node from origin line or nodelist, it should send the mail
back to original echo as private message. clumsy, though.

Man pages are completely missing, I haven't got experience on writing
roff but maybe I have time to open the manual next week!

File requests and other fancy stuff. Never heard of :-)
modem7/telink is there, but haven't tried it yet.

There should be some kind of locking-mechanish using lock files, as
not all machines have lockf or locking.  I try to hack on other things
myself as I have locking/lockf.

fgets in funpack.c looks for * Origin in both mails and echos, only
echos are needed.

fcall should be modified to be capable of being slave like uucico. It
could try slave mode if no node is specified, but I need a getty which
notices TSYNC when someone calls in.

AREA: fields and FSC-controls might be moved to message header, as
they could be removed when reading news easily with rn parameters, but
converting them back to their original places is a bit nasty, maybe I
should include some kind of line-number? On the other hand, is it
necessary to have them at their original places anyway, message format
will be changed a bit always?

funpack: opens and closes config file for every message. Lots of other
inefficiences all around. Parsing headers should really be rewritten,
now it makes number of passes through the message.

reaction to incorrect permissions etc can be fatal, rfmail just
ignores the message if log file could not be opened, though it says
error but cannot log it. It should at least send message to news admin
and then maybe loop until it can read write log file... ok, getting too
fancy.

Currently only one fidonet mail/echo feed is supported as receiver,
but several systems can be polled for mail. This could be reasonably
easy to correct, just make fpack ignore messages not destined to
system specified, or even better, pack messages according to routing
files, which could be simple.

Arcmail capability should be build, even one-directional
would be help, I just have to compile arc for this machine, running
(pk)arc under dosmerge isn't reliable with my beta-version of
dosmerge, and people without 386 couldn't run it at all.

Now there are routines in some programs which could be used (and be
helpful and cleaner) in other programs also, and sometimes code
is really quick-hack-style.

Keep in touch!

