2DaPoint Page 1
╓─╖ ╥─┐ ╓─┐ ╥─┐ ╓─┐ ╥ ╥─┐ ─┬─
╓─╜ ║ │ ╟─┤ ╟─┘ ║ │ ║ ║ │ │
╙── ╨─┘ ╜ └ ╨ ╙─┘ ╨ ╨ ┴ ┴
The *Complete* Netmail Processor
Version 1.50 Reference Guide 11/1991
A totally free mail bundler for use on FTSC compliant .MSG
files with the BinkleyTerm 2.50 FidoNet Mailer
Software & documentation by Ron Pritchett of 1:376/74.0
Copyright (c) 1991 Realm Software
All Rights Reserved
Realm Software
133 WaterView Dr
Columbia, SC 29212
2DaPoint Page 2
INTRODUCTION
This software was written on a whim. After noticing how well Maximus
CBCS handles point addressing, I started searching for an equally
point-aware NetMail Bundler. The idea is that the average caller/user
shouldn't have to know anything about the pseudo point network/secondary
set of addresses. The only thing I found that came close was REMAPPER by
Bob Hartman (of ConfMail fame), but this didn't work quite the way I
wanted it to & lacked a few features. Finally I downloaded a copy of the
FTSC specs & went to work on my own program. Here it is.
>>What it does<<
- Full zone support.
- Complete Message bundling (.?UT file generator) for normally addressed
messages including File Requests, File Attaches, Forwarding, Crash,
Hold, & Kill. Also processes any Echomail that has happened to have
landed in your netmail dir. (ie the whole 9 yards)
- Through File Attaches between points or BBSes which can optionally be
deleted once sent. Multiple File Attaches & File Requests are supported
too.
- Recognition of point addresses embedded within messages to send the
message to the proper host or point host.
- Address redirection (including points) via name recognition.
- Name remapping via alias name recognition.
>>What it doesn't do<<
- It won't do XRobot-type automatic mailings/file attaches.
- It won't balance your checkbook.
- It won't fix your recently pedestrian-damaged Buick Impala for free or
even at a discount rate.
CONTROL FILE
2DaPoint requires the presence of a control file called 2DAPOINT.CTL
which must reside in the same directory the executable program is. There
is no way/reason to have the control file named anything else.
A sample configuration file with internal documentation is included. The
sample is actually MY control file. It's short & sweet. Not too many options
or things to go wrong. 2DaPoint is very forgiving about the information
contained in the control file. If information is missing or invalid, the
program will point out which additional information is needed/invalid.
2DaPoint Page 3
The commands are listed here in alphabetical order for reference ease.
Address <(zone:)net/node(.point)>
Here your full address must be specified. Zone & point are not
a required portion of the address; zone 1 is assumed & .0 is
also assumed. The point portion of the address is recognized,
but is only for future expansion. It may possible to run this
program from a point system, but I haven't tried it.
FileFwd <Kill | Save>
This options controls whether or not a file passing thru
your node is to be killed or saved. If 'Kill' is specified,
then file will be killed by your mailer after it has been sent.
If 'Save' is specified, the file will not be killed, it'll just
sit in your inbound directory. NOTE: This only applies to
passthru files (ie they didn't originate from your node & they're
not destine to your node).
Forward <Kill | Save>
This options controls whether or not a message passing thru
your node is to be killed or saved. If 'Kill' is specified,
then message will be packed up & then the .MSG file will
be erased. If 'Save' is specified, the message will not be killed
just marked as 'Sent'.
Inbound <directory>
This is the path of your incoming file/mail directory. This is
used for passthru file attaches for your node. This way points
can send mail amongst themselves via your host or even to other
nodes or other points on other nodes.
For Example, when a point sends a file to another point, the
subject line of the message contains the path & filename of the
file to be sent. Well, there's only a one in a million chance that
this will be the same on the both the point's & Host's computer.
2DaPoint will replace the path on the incoming message with the
directory name that you have specified. (ie where the file is now
located on the host system.)
Log <filename>
This filename, which can include drive & path specifications,
is where 2DaPoint logs it's activities. Versions prior to 1.50
were forced to use the file: 2DAPOINT.LOG in the directory where
the program was being run.
Mail <directory>
This is the path to your netmail messages directory. 2DaPoint
looks here for messages that need to be sent, etc.
2DaPoint Page 4
Mode <Net | Node>
This option controls whether a message bound for a point is
to be saved in a .PNT directory (for pickup or mailing) or
it's to be sent to the point's host system. If operating in
'Net' mode, any mail bound for a point in your zone & network
will be packed up for it's full 4D address & placed in a .PNT
subdirectory in your outbound mail area.
(If you're unfamiliar with the new .PNT directory format, refer
to the Binkley 2.50 documentation or the example in 2DaPoint.ctl.)
If operating in 'Node' mode, the additional constraint of a point
being your point is added. If a message is received for your
point, then (as above) it is bundled into a .PNT directory.
Otherwise, the message is sent to that point's host. Once there
the ^ATOPT would be recognized & the message would be sent along
the proper path.
Names
This marks the beginning of your name service addressing. One
name & address appear per line until the keyword END is
encoutered. If a message is bound for a node in your Network
or your PointNet and the name is in the control file, then the
destination in the control file is used instead of the one
embedded in the message. (Read that sentence again, I'm sure
it'll be the source of some confusion. <grin> )
The syntax of the NAMES block is:
Names
( <alias1> ^) <name 1> <address | Hold>
( <alias2> ^) <name 2> <address | Hold>
........ .........
( <aliasx> ^) <name x> <address | Hold>
End
Where <name> can be any numbers of words (theoretically). And
<address> is a full or partial address. "What's a partial
address?" you're asking. Well basically it means that the part
of the address that you don't explicitly enter, will be assumed
based upon what address you have specified for your address via
the ADDRESS statement. See examples in control file.
If an <alias> is present, then any message addressed to
<alias> or <name> will be sent to <name> @ <address>. The ^
character delimites between the <alias> & <name>. See example
control file for examples that might wipe away your confusion. <g>
Also: the <address> may be "Hold" which will simply hold the
message and not send it anywhere.
2DaPoint Page 5
Notify <None | OurNet | All>
If someone sends a message to your system & it is mis-addressed
(according to the name service table) then the sender of the
message will get a notice saying that they haven't sent their
msg to the wrong address & also listed will be the correct
address.
None - will disable this feature.
OurNet - will only send to nodes/point in your network.
All - will send a FYI msg back to the sender no matter what
net or zone they're in.
Outbound <directory>
This is the path to your outbound mail directory. All generated
outbound bundles/packets will be placed in this directory.
PWFile <filename>
This filename, which can include drive & path specifications,
is where 2DaPoint reads passwords for use in secure enviroments.
In a secure enviroment, packet headers have paswords embedded in
them. The password command syntax in the PWFile is:
Password Address Password_for_That_Node
Example:
Password 1:376/74.51 BLAHBLAH
SetBit <bitmask>
StripBit <bitmask>
Once it's been determined that the message needs to be sent, The
bits defined here will either be turned on or off in the status
of the message. This doesn't apply to echomail destine for other
systems that has happened to land in you netmail directory.
See Control file for detailed info.
ZoneGate <On | Off>
Use zone gating. See Control file for detailed info.
2DaPoint Page 6
COMMAND LINE PARAMETERS
-B = Use BIOS calls instead of direct video writes.
EXIT ERRORLEVELS
Exit ErrorLevel Codes
0 - No Mail Processed
1 - control file missing
2 - Incorrect Control file parameter(s)
3 - Netmail, Inbound, or Outbound dir doesn't exist
4 - Outbound Mail Created
LEGAL STUFF
I take no reponsibility for what this program will do. It is NOT a trojan
horse type program, but who knows what could happen with an incompetent user.
CLOSING THOUGHTS
This program has been thoroughly tested with Maximus & should work on Fido,
Opus & any other FTSC-compliant BBSwares. Please report any problems
encountered, if any. The latest version can be F'req-ed from 1:376/74 with
the magic filename of 2DAPOINT.
That's it! I'm not much on docs. I'd love to hear from you. If you thought
this software is trash, helpful, lacking in a few areas, whatever!
Ron Pritchett
1:376/74.0