Make the config command work... this should be added as an external, or
a menu option.

X11.

If a "Command" key value is included in .ini file, will be used in place of
mail processor's name (section name in square brackets).
If an "Eval" key value is included in .ini file (for non-native mail procs),
the key value will be JS-evaluated instead of executing an external script.
Fix: If a message is received for multiple local recipients and any of the
names match a mailproc's 'to' list, that mail processor will be executed.
These improvements and fixes allow a mailproc.ini entry like the following to
work:
[From Hosted Address]
	From = *@synchro.net,*@swindellfamily.com,*@weedpuller.com
	AccessRequirements=not user 1
	Eval = log("Removing mail from " + reverse_path); file_remove(message_text_filename)

(.can style wildcards are allowed)

to spamd. Some SA features require these header fields.
Received header support is currently disabled due to some issues, like:
1. Getting duplicates Received fields after processing the message
2. SpamAssassin *really* doesn't like dynamic IPs in Received header fields

SMTP HELO string from sender.

created.
Bug-fix for last commit (missing ;).

msg header.
Include the (envelope-from <>) comment in the "Received" header field.
Ingore any existing Return-Path header fields when parsing incomming message
headers.

does not support a zero size either.

you last scanned.

of externals being ran.

open() actually does.

parameter.

Note: When shareable is false, uses nopen() which will lock the file
exclusively and perform automatic retries.  When shareable is true uses
fopen(), and will only attempt to open the file once and will perform
no locking.  The behaviour when one script has a file opened with shareable
set to a different value than is used with a new call is OS specific.
On Windows, the second open will always fail and on *nix, the second open
will always succeed.

Add comments explaining user settings.

Intended to run as a login event and as a bbs.exec_xtrn() wrapper, this
will track new doors, and doors which have had activity since you last
played.

To set up the login event:
SCFG -> External Programs -> Fixed Events -> Logon Event
	"*../xtrn/doorscan/doorscan.js scan"

The modification to exec/xtrn_sec.js:
At around line 136:
//bbs.exec_xtrn(xtrn_area.sec_list[xsec].prog_list[i].code);
try {
	load("../xtrn/doorscan/doorscan.js","run",xtrn_area.sec_list[xsec].prog_list[i].code);
}
catch(e) {
	log("Error running "+xtrn_area.sec_list[xsec].prog_list[i].code+" "+e);
}

by it when using iniSetAllObjects().  Previously would result in something
like this:

[Section]
name=Section