mark lewis wrote in a message to Bill Burton:


 BB> I am running a WINXP box with Argus set up as my mailer and VFIDO
 BB> is my tosser which is part of the VADV BBS package. VFIDO is
 BB> tossing my outbound packets to my C:\Argus\OUT\ directory and they
 BB> just sit there. I have been unable to figure out how to get Argus
 BB> to send the packets. Any suggestions and help would be appreciated.

 ml> is VADV configured for binkleyterm style outbound or file attach
 ml> like frontdoor? 

 ml> are those mail files in your OUT PKTs and/or mail bundles like MO1?

I have both PKTs and Bundles waiting to send.

 ml> are they accompanied by a ?LO file? without a ?LO file, they can't
 ml> won't go anywhere 

There are not any ?LO or other files for sending that I can find.

 ml>  is argus is a pure BSO mailer...

Below is an excerpt from the Argus help file that may assist in trouble
shooting.

I am receiving MSGs and Files in Argus via a BinkP connect from D'Bridge and
they are tossing to the BBS.
------------------------------------------------------------------------------


What is Argus?
Argus is a comprehensive FTN Mailer designed to work as a multi-line system
using two widely used data exchange transports - Dial-up networking and TCP/IP
- simultaneously.

Major benefits by using Argus are:

True multitasking using Win32 API 
True multi-line mailing system 
Extended TCP/IP support 
This chapter also describes FTN standards, supported by Argus.


FTN Standards Supported
Argus interacts with remote systems using protocols and technology standards
described in this chapter. Because Argus is built on FTN Technology (FidoNet
Technology Network), it supports standards and proposals developed by FTN
committee, common standards of FTN mail system functions are also supported by
Argus.

This is the list of FTN standards and proposals that Argus is compliant to.
Descriptions of those standards can be obtained from ftp://ftp.fidonet.org 

FTS-0001 mail session (limited to incoming-only). FSC-0039, FSC-0045 and P2K
packet types are also supporting to extract remote information. 
YooHoo (FTS-0006) handshake. 
Nodelist (FTS-0005). Also, extended TCP/IP flags are supported. 
EMSI Handshake (FSC-0056) - full implementation. 
WaZOO mail session and file requests (FTS-0006) - full implementation. 
Z-modem file transfer protocol - full transport implementation with
Skip/Refuse.
Hydra file transfer protocol (FSC-0072) - full transport implementation except
of chat ability. 
Working Time Nodelist flag (FSC-0062). 
Binkley-style Outbound. 
BinkP Transfer Protocol - full implementation of v1.0 draft specification,
extended to file requests. 
Encrypted BinkP session. 
CRAM-MD5. 
The reason to implement FTS-0001 mail session and FTS-0006 handshake is to be
Fidonet-Policy compliant. Fidonet is the greatest FTN-based network worldwide.
Here is an extract of chapter 2.1.8 Fidonet Policy v4:

Any system which wishes to be a part of FidoNet must be able to receive mail
during this time using the protocol defined in the current FidoNet Technical
Standards Committee publication (FTS-0001 at this writing). It is permissible
to have greater capability (for example, to support additional protocols or
extended mail hours), but the minimum requirement is FTS-0001 capability
during this one hour of the day.
Note, that there are some limitations in Argus implementation of FTS-0001:

Outgoing FTS-0001 calls are not supported. 
Argus receives only and does not send out files during FTS-0001 session. 
The password length is limited by FTS-0001 to 8 characters. Links with more
than 8 characters in a password would be unable to initiate a pa
sword-protected FTS-0001 session. 
Skip File and Reject File operations are disabled (as well as refuse/delay). 
No file re-gets. 
Some FTS-0001 mailers do not provide valid file time. 
FTS-0001 protocol may not be fully Year2000 compliant in some implementations. 
CRAM-MD5 is not suported. 


Binkley-Style Outbound
This chapter explains the general principles of the Binkley-style Outbound
structure, used by Argus mailing system.

Binkley-style Outbound was introduced in BinkleyTerm mailing system by Bit
Bucket Software, soon it became a standard for the outbound section of mailing
systems.

Explained briefly, The Binkley-style Outbound is a directory structure
containing outgoing packets. The outbound directory for Default outbound zone
is the directory specified in the Outbound entry field of the Directories
Configuration dialogue. Outbound directories for other zones are created as
directories with the same name as default outbound zone directory, but the
name extension of such directory is hexadecimal representation of 12-bit
number of the zone. (This is the reason to limit maximal zone number with
4095, which is FFF hex).

OUTBOUND
 The outbound directory for Default outbound zone) 
OUTBOUND.001
 The outbound directory for Zone number 1 (North America) 
OUTBOUND.03F
 The outbound directory for Zone number 63 (3F hex) 


All outbound packets are divided into two groups: Mail bundles and Attachment
lists. Each group has four (actually three, because Direct is equal either to
Crash or to Normal - it is determined in the terms of a particular mailing
system) subtypes determining the urgency of a packet: 

Subtype Initiates a poll Packet contents is transferred during outgoing
connection Mail bundle extension Attachment list extension 
Crash yes yes .CUT
 .CLO
 
Direct yes yes .DUT
 .DLO
 
Normal no yes .OUT
 .FLO
 
Hold no depends on setup .HUT
 .HLO
 


A Mail bundle is a standard FTS-0001 or P2K message packet, so before sending
it, the system changes its name to XXXXXXXX.PKT, where each X represents a
random hexadecimal digit (usually that hexadecimal combination is actually the
time of a packet creation in UNIX format, but it is not relevant in modern
mailing systems).

The Attachment list is a text file containing text lines, each of these lines
contains the full path name of an outbound file. The very first character in a
line may also determine the action after the target file is sent: '^'
character placed in the beginning of a line means that the target file must be
deleted, '#' means that the target file shall be truncated after its transfer.

The name of each outbound packet for a node has a format NNNNFFFF.EXT, where
NNNN is the hexadecimal representation of 16-bit Net number, FFFF is the
hexadecimal representation of 16-bit Node number and EXT is the extension
determining the group and subtype of the packet (see the table above). Thus,
all outbound packets for node with address 469/38.0 will have names
01D50026.EXT

Outbound packets for points are stored in sub-directories of an Outbound
directory. Those directories have names of format NNNNFFFF.PNT, NNNN and FFFF
have the same meanings as for a node's outbound packet, .PNT is the extension
symbolising that it is a point outbound. Outbound packets for points are names
as 0000PPPP.EXT, PPPP is the hexadecimal representation of 16-bit Point number
and EXT is the extension determining the group and subtype of the packet (see
the table above). Thus, point 25 of node 469/38 (469/38.25) will have outbound
packets named 00000019.EXT placed in the sub-directory 01D50026.PNT\ of an
appropriate outbound directory.

There are some additional Binkley-style extensions, supported by Argus:

.BSY
 Indicates that the node is busy 
.REQ
 List of file to request from remote 
.HRQ
 List of files, requested by remote 


Argus has an ability to open .BSY-files without DELETE_ON_CLOSE mode. Files
will be deleting using DeleteFile command. This may be useful on some network
file system which don't support DELETE_ON_CLOSE mode. To turn this option on,
add the following registry value:

[HKEY_LOCAL_MACHINE\SOFTWARE\RIT\ARGUS\CurrentVersion\IniFile.ini]
"SimpleBSY"=dword:00000001
Outbound SmartMenu is a powerful tool provided for Binkley-style Outbound
operation.


BinkP is a new transfer protocol designed especially for using IP connections
for FTN developed in 1996 by Dima Maloff. This protocol does not imitate a
Dial-up connection, so it allows to use maximum performance because the
absence of irrelevant data transferred within Dial-up connections (such as
checksums for example) and using of two-way data flow. The default IP port
number for BinkP is 24554. BinkP could be used over Dial-up as well. In that
case Niagara algorithms would be used on Transport Layer. BinkP allows flow
encryption and CRAM-MD5.

------------------------------------------------------------------------------

Later,
Bill

 Internet: wabusa.com  Telnet: bbs.wabusa.com  Fidonet POTS: 330-548-2566 
--- 
 * Origin:  INA:fidonet.wabusa.com, IBN  (1:2215/15)