.. [000] What is MailGate? What MailGate can do for you MailGate is a very complete package that will help you do many things and add complex features to your BBS system. It is the result of many hours of hard work since January, 1993. The result can be seen from the size of all executable files contained in this package. MailGate was compiled using Borland's excellent Turbo Pascal 7.0, which gives an indication that each byte means a lot of work. It was our philosophy to design every single function and procedure used to build this package. Yes, we reinvented the wheel completely. But now we can control every single detail of this program and maintenance and improvements are easy to handle. These are the known features of MailGate below. We hope you can find other applications not listed and we kindly ask you to report your findings to us, so that other people can benefit from them. We tried our best to test the program intensively, but bugs may come out and we also need your help in reporting them to us. We really hope MailGate can make your system much more powerful and management easier for you. Enjoy it! * Features of MailGate * 1 - Gateway to the Internet 1.1 - Netmail to Email and Email to Netmail. Users from other systems may participate. An entire nodelist may participate in the gateway. 1.2 - Echomail to Lists and/or Newsgroups and vice-versa. This feature does not depend on the type of BBS system you are running. It is BBS independent. The only requirement is that your system be able to process PKT packets. 1.3 - Email messages to Fax. Any person on the Internet may send a Fax to your system or any other system in an entire nodelist. 1.4 - Echomail compressed files can be automatically sent and received from another remote site as if the compressed files were sent over a Fidonet mailing session through a phone call. 1.5 - Your system can manage Local Lists and have them available for Internet users to subscribe. In other words, MailGate provides a very powerful Listserver, which includes a Fileserver for automatic delivery of files to subscribed users of your Local lists. Needless to say, these local lists can be in gateway with echomail areas, and the Fileserver in gateway with the TIC server. 1.6 - Complete set of customized messages to be sent to UUCP and Fidonet users about the use of the gateway. 1.7 - Complete control of the use of the gateway for later billing, if this is the case. The system will control the number of bytes sent and received, the names of the addressees and addressers, the time and date the message was processed and the subject of the message. 1.8 - Alias file and subdirectory for file requests with the GET command of the Listserver. Powerful carbon copy manager. 1.9 - Netmail file attaches are uuencoded and sent to the Internet destination. 1.10 - UUCP to UUCP network system. Your system may act as a UUCP provider, assign Internet subdomain to other systems, re-route UUCP mail between uplink/downlinks, exchange Newsgroups to as many as 255 downlinks 1.11 - True subdomaining or fake subdomaining. For example, assuming your system to be TTBBS.COM, there may exist systems like XXBBS.TTBBS.COM or %XXBBS@TTBBS.COM 1.12 - Downlink nodes may either receive mail in UUCP or Fidonet format. Downlinks in Fidonet format are configured in the MAPS database. 1.13 - Echomail messages with valid Internet destination in the TO: field may be configured to have them sent as email to the destination 1.14 - Get the best of both worlds, Fido and UUCP. MG may be configured to compress/decompress UUCP mail to/from any UUCP downlink using Fidonet file attaches. The files will be sent during a Fidonet session, received in the other end as if a UUCP session had taken place 2 - Gateway between different Fidonet type of Networks. Fidonet has zones 1 through 6, but there are many other networks using the Fidonet technology. 2.1 - Netmail to Netmail from one network to another. 2.2 - Echomail to Echomail from one network to another. 3 - Complete Fax delivering Manager 3.1 - NetMail to Fax. Any netmail from any system can be delivered as Fax messages. The system provides two different kinds of Fax management, one for normal users and the other for VIP users, configured in a special Database. 3.2 - EchoMail to Fax. Messages from an echomail Area can be forwarded to the Fax manager and sent as Fax messages. 3.3 - UUCP to Fax. Messages from Internet users may be sent to the Fax manager. 3.4 - Complete information about the transmission status of the Fax messages. Users who send Fax mail will be notified of date, time number of pages and time used during the transmission of the Fax. There is a limit of attempts to send a Fax message before giving up. Support to BitFax 3.02 and BGFAX 1.40 3.5 - Files to the Fax server. Netmail file attaches are forwarded to the Fax server for delivery and special handling 3.6 - Phone book Databases are available for automatic delivery of a Fax message to multiple recipients. This is a Fax mailing List. 4 - TIC distribution of Files. 4.1 - TIC works the same way as do echomails. Files can be automatically distributed from uplink systems to downlink systems, without the need of human manipulation (unless, of course, the file has to be distributed in the beginning). 4.2 - Unlimited number of TIC Areas. The system is only limited by the capacity of your Hard Disk. 4.3 - 26 TIC groups to manage the areas. Conversion of compression type. 4.4 - Complete set of remote maintenance functions to control the configuration of any system. This is called the RAID function. 4.5 - Special treatment to MAGIC files. 4.6 - Uplinks can be configured to automatically add new TIC Areas in your system, or do the same with MAGIC Areas. 4.7 - TIC reports can be sent to any Echomail Area or to the sysop, via netmail. 4.8 - Virus scan can be processed on files in distribution 4.9 - NODEDIFF and NODELIST files can be located, compressed and sent to the members of a TIC Area automatically. 4.10 - TIC Areas may have their own Node numbers to operate, which makes each Area completely independent from each other and easy to work with in different networks. 4.11 - FileFix manager. Any user can access certain echomail areas and send special commands to the user "FileFix", which will execute a search for the files requested by the user in the TIC Areas of your system. Files that match the request will be listed in an automatic reply to the original user in the same echomail Area. It is a type of "archie" search in the network. 4.12 - The system may manage the file lists of other systems, and process them during a FileFix search. These systems may also be configured to receive a copy of the requesting netmail, and work on it. This, on the Internet, is called the "ARCHIE" function, and your system and network may be configured to implement it 4.13 - Unlimited number of node numbers as members of a TIC Area. 4.14 - FILES.BBS or Remote Access internal file base may be configured for individual TIC Areas. FILE_ID.DIZ is removed from inbound file and used as a complete file description. 4.15 - Customized text file to be appended in the TIC reports of each TIC area. Banners may be included in compressed files. 4.16 - The system may have TIC area directories scanned for new files. If found, they are automatically broadcasted to the TIC downlinks. 4.17 - MAGIC files are updated/added in the ALIAS file used by the mailer during file requests 4.18 - TIC downlinks may be Internet users. The TIC manager will forward the files to the destinations as uuencoded messages 5 - Netmail Local server 5.1 - Your system may forward text messages to a particular list of users. 5.2 - Users from your network may request files to be sent to them as netmails. 5.3 - Users from your network may request files to be file attached to them. 5.4 - Users from your network may request files to be Faxed to any phone number or phone database. 5.5 - Users from your network may save text files in your system for later availability for request in the system 5.6 - Users may request information about the use of their accounts. They can request information for any period of time, and the system will send a complete log of the system usage. 5.7 - Netmail special users. If a user sends a netmail to "help", and "help" is a text file in a special subdirectory, MG will send the "help file to the user who requested it 6 - Echomail Local Server 6.1 - The system may send text messages to certain Echomail areas. 7 - Remote DOS maintenance. 7.1 - Users may send DOS commands to your system, provided they have the proper password. Each password is the name of a text file in the system that contains the list of all commands allowed to be executed. 8 - Message Base. Read, reply, write, encrypt Fax, Fido or UUCP messages. 8.1 - Access to the MSG netmail base. 8.2 - Access to the Hudson message base. I hope everything is listed here. They are very summarized but can give you an idea of the features that MailGate provides. This will be our policy related to the release of MailGate, shareware version: - Each public release will have versions ending in only one decimal, for example, MG 0.1, MG 0.2, MG 0.3 and so on. If a newer version has to be released due to a serious bug to be fixed, a beta version will be distributed, and the identification that the version is still in beta mode is also in the version number, that will now contain 2 decimals, for example: MG 0.11, MG 0.12. It is our intention to delay no longer than 45 days between one public release and the next one. Beta releases may be distributed at any time. Major releases are the ones that change the digit before the decimal point in the version number, for example: MG 1.0, MG 2.0, MG 3.0 and so on. MailGate packages will be named as follows: MGabcd.ZIP where abcd stands for the version number. For example: MG 1.02 will be released as MG102.ZIP As explained in the "Registering MailGate" section, MailGate shareware version is on a promotional registration fee. This fee will only be valid until the next major release, which will be MG 1.0. Once a user registered his copy of MailGate, this registration will be valid for all subsequent releases of MailGate shareware version, regardless of any changes in the registration fee. We think it is a matter of acknowledgement with all those users who committed themselves with MailGate and registered it, giving their support to us. We also believe that unregistered programs should not be crippled or have any function disabled to the user. We are giving the first step in trusting you and providing you with a full functional version of MailGate. However, this is not a policy and we reserve the right to change it whenever we see it is necessary. We kindly ask you to take in consideration the great effort put in creating this program. There is an Echomail conference available in Fidonet Brazil, MAILGATE, and the main feed is node 4:808/2. The conference is available in the RBT network. There is also a List conference in the Internet, called MG-L, that can be reached by Internet users after they send their subscription command to listserv@ear.anpe.br. We are also running a small UseNet network, and the same conference is available to UUCP links as newsgroup ALT.BBS.MAILGATE. Finally, the messages are also sent to a special group of users who read the mail after receiving it by Fax by means of a Fax mailing list. As a matter o fact, all conferences have exactly the same messages, since we use MailGate to have them in gateway. These first releases of MailGate come with a very simple documentation, for which we apologize. There are many other new features we want to see in MailGate. For this to become true, and also to have other features and improvements, we wish to count with your help. Please send your suggestions, complaints, criticisms, they will be very welcome. We would like to hear from you. Once again, thank you very much for taking the time to try MailGate! You can get the newest versions of MailGate from the systems listed in the MGSITES.DOC file, available in the original package of MG. If you establish a stable link with us, you will be entitled to also distribute MailGate, and your system will be listed in the next versions. File request the newest version with the MAGIC name MAILGATE. For Internet users, there are two ways to retrieve the newest version, either via ftp or via uuencode mail. For those who have access to FTP, MailGate can be requested by anonymous FTP from the sites listed in the MGSITES.DOC file. Log in as "anonymous" and supply your Internet address at the password prompt. A more updated list of ftp sites and Fido BBSes can be requested by RBT netmail : sending a netmail to user "mgsites", at 12:1280/1 Internet email : sending an email to mgsites@ear.anpe.br Yes, these special users are automatically managed by MailGate. System Requirements Software and Hardware * An IBM PC, XT, AT or compatible, i386/i486 CPU supported * DOS 3.31 (or above) or OS/2 2.x DOS compatibility box * Any *.MSG and *.PKT compatible BBS software (Front-End Mailer) * A Fax delivering program * A UUCICO.EXE delivering program for UUCP mail * Memory requirements: At least 512 Kbytes of memory. MailGate needs dynamic memory that is allocated during run-time and that depends on your configuration. If you run a disk-cache program, MailGate will operate much faster, since it depends heavily on the Hard Disk. Your system should have extended memory, otherwise MailGate will slow down considerably. FILES=30 or more in your config.sys file. At least one of these (de)compression utilities: * PKZIP/PKUNZIP * ARJ * LHA * PKPAK/PKUNPAK * ARC * ZOO * uncompre, compress or gzip MailGate is a gateway package, and as such, it assumes that you already have a BBS system running. It is not a front-end mailer. MailGate does not depend on any message base format. It generates PKT packets that must be processed by your echomail utility and tossed into your message base. It also assumes that you are hooked up to a Internet site with which your system can exchange UUCP mail. However, MailGate can successfully work under Fidonet only, Internet only, or in the most complete configuration, in both environments. Your system does not need to have access to the Internet to be able to use the Fidonet features of MailGate. Your system does not need to have a Fidonet BBS running to be able to use the UUCP features. Thanks to my beta testers, support sites, participants of the MG-L List, without whom I could not go further. The list below is not complete, but special thanks go to: Fabio Becker, Adriano Garcia, Jorge Eduardo, Bruno Santos, Jeronimo Barros, Isamar Maia, Troy Engel, John Mudge, Hartmut Karrasch, Don Packwood, Craig Thompson, Walter Longeman, William Woo, Marijn Raaijmakers, Philippe Cheve, Jorge Santos, all members of our RBT network and so many others who have been showing us support. A very, very special "Thank you!" goes to Troy Engel, from California. MG021 could only become true with his precious help. Almost every day, in the last 6 months, we have been exchanging ideas, and his suggestions, feedback, expertise, gave me conditions to have MG go under such a major upgrade. For all of his effort and attention, I send him my best regards. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ I dedicate this program to my son, whose birth gave me reasons to carry on. Thanks to my wife, who has been very patient and supportive. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ This version of MailGate was compiled on 15 Jun 95 21:19:03 All products mentioned here are trademarks of their respective owners .. [001] Tropical Reefs A note on Tropical Reefs Inc. Tropical Reefs Inc. is located in the city of Recife, in the Northeast region of Brazil. It can be easily found on the map, since it is in the closest point from South America to Africa. We live in one of the most beautiful regions of Brazil, with thousands of miles of sunny beaches and ecological resorts. MailGate is the first product released by Tropical Reefs, and we hope to release other projects that are being implemented and will receive more care after the first release of MailGate is sent to the public. This name is in honor of the city of Recife, which means "reef", since our Atlantic coast is cut by a long line of reefs. Snail mail: Tropical Reefs Inc. Caixa Postal 4711 Pina - Recife - PE 51011-020 - Brazil .. [002] Legal Notice License Information "MG" refers to the executable programs and text files contained in the MailGate distribution archives released by Tropical Reefs Inc. 1. This is copyrighted software owned by Clovis Lacerda. This is not public domain or freeware. Clovis Lacerda grants you a temporary license to try this software for evaluation purposes only. MG may only be used in accordance with the conditions set out in this license agreement. 2. You may use MG for a period of thirty days on a trial basis in order to determine it's suitability for your particular application. After this period you MUST register each copy of MG that you run simultaneously. 3. Registration entitles you to use MG and any future versions of MG for as long as you wish, subject to any special licensing conditions attached to future versions. For details on the registration procedure, refer to the section in this document "REGISTERING MAILGATE". 4. Neither Clovis Lacerda nor Tropical Reefs Inc. are in any way obligated to provide future versions of, or support for, MG. 6. You may not modify or otherwise reverse-engineer MG. 7. You are encouraged to distribute MG provided that no fee is charged for its distribution, and that the distribution archive is not modified in any way. Pay Bulletin Board Systems may however charge their normal fee provided that no additional charge for MG is levied. 8. MG may not be included as part of any software library which is distributed on a commercial basis (commercial = "for money") without prior written permission from Clovis Lacerda. 9. MG may not be used in any unlawful or illegal manner. 10. MailGate is provided "as is", without warranty of any kind, neither expressed nor implied. The author only guarantees that MailGate and the included tools occupy disk space. 11. In no event will the author be liable to you for any damages, including lost profits, lost savings or other incidental or consequential damages arising out of the use of this program. 12. After registering your copy of MailGate with us, you will receive a file called MG.KEY, which is unique to your system, and under NO circumstances should it be made available to anyone else. Doing so is a direct violation of the agreement set between you and the owner of MailGate, according to the conditions of this License agreement. .. [003] Registering MailGate Registering MailGate After you have tested MailGate within the period of 30 days, and if you decide to continue using it, you must register your copy with us. Registration shows us that you support our product and help us keep improving it. In the end, you will benefit from registering, since better products will be made available to you and you will no longer need to register MailGate, shareware version, again. As stated before, until the next major release of MailGate shareware version, the registration fee will be on promotion. To register one copy, the registration fee is: US$ 39 Dollars There are special discounts if ONE person registers more than 10 copies, no matter if the registration keys are for different people. This is only valid if the registrations are made at ONE single time. The discounts are: (10%) 10 to 20 registrations - Each registration fee: US$ 35.10 dollars (20%) 21 to 30 registrations - Each registration fee: US$ 31.20 dollars (30%) 31 or more registrations - Each registration fee: US$ 27.30 dollars To register your copy, you must fill out this form and send it to us, attached to a copy of the bank deposit, confirming that you paid the registration fee. Registration Form Name : ____________________________________________ Main Node Number : ____________________________________________ Attention: The two lines above *must* be exactly the same as configured in the "Sysop Name" and the "Main AKA Node" options of MGSETUP Home/Business Address: ____________________________________________ ____________________________________________ ____________________________________________ ____________________________________________ ____________________________________________ BBS Name :____________________________________________ BBS phone number :____________________________________________ Hour of BBS operation:____________________________________________ Number of registrations: ________________________________________ Discount (10 or more) : ________________________________________ Final Price : ________________________________________ Type of payment (money, check or VISA/MASTERCARD): _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Att: Please check if the bank deposit will have any ammount deduced because of bank fees. If so, you have to cover for these extra values. This is specially true for deposits in checks. Suggestions to improve MailGate: ________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ Registration in Brazil: To: Clovis Lacerda Leite Filho Banco Real cc: 4706901-0 agencia: 0686 We are also accepting registrations through international credit cards. Please send the number and the expiration date of your VISA MASTERCARD via crash mail to us. RBT node: 12:1280/1 Internet email: clovis@ear.anpe.br 3- Snail mail: Tropical Reefs Inc. Caixa Postal 4711 Pina - Recife - PE - 51011-020 - Brazil Other brazilian registration sites are listed in the MGSITES.DOC file For registration in other countries, through our registration sites, please refer to the *.REG files, supplied in the original package of MG. .. [004] MGTOOLS.EXE Running MGTOOLS MGTOOLS is a utility that provides important functions that you will need to maintain your system running, and also a set of important tools that you may find useful to use in many different applications. Run MGTOOLS ? for details on how to use all functions available. The HELP Menu displayed by MGTOOLS ? will be shown after you exit this screen by pressing ESC. Syntax: MGTOOLS FUNCTION FUNCTION is one of the available functions listed below. COMPILE- Compiles Primary and Secondary Nodelists TIC - Sends Help and Notify to Downlinks. NET - Netmail Generator. DUMP - Dumps the contents of the compiled Fido/UUCP Nodelists RAUSER - Save all local users in ASCII as a CTL control file, that can be used by the MSG server. Only for Remote Access 2.00 In all options, run MGTOOLS FUNCTION ? for more details Compiling Nodelists: MGTOOLS COMPILE -N1 -N2 -N1 compiles the nodelist for PRIMBBS, as specified in the configuration file. -N2 compiles the nodelist for SECDBBS, as specified in the configuration file. Syntax: MGTOOLS NET -B[nodeFrom] -O[userFrom] -D[userTo] -N[nodeTo] -S[subject] -U[Internet_node] -T[message] -I[IDs] -#[flags] -C[user] -P[link] -Z -M -G -A -Y -F[days] -L[days] -B NodeFrom=node number of netmail -O UserFrom=sender of netmail -D UserTo=destination user -N NodeTo=destination node in valid Fidonet 4D format -S Subject. If file name, supply full path/name -T Message body. Supply full path/name of message file -U Uucp destination user. The Destination node defaults to the UUCP Gate -C UUCP Cost for user. If the user is not specified, default is -D. -Z Costs for all users at -N are processed. Destination overriden by -D -Y Summary of UUCP cost for the entire system in -N -I Send the list of UUCP VIP users that match the [ID] identification(s) -M The system will mark processed mail as "processed" -G The system will ignore mail marked as "processed" and include it -A The system will not include detailed information of each mail -F Number of days the system will start to log. Default: 30 days -L Number of days the system will stop to log. Default: 0 days -P Log costs for UUCP [link]. Send to postmasters as in Node Manager -# F=File P=Private K=Kill/Sent H=Hold C=Crash D=Dir E=Del File T=Trunc Ex 1: NET -B12:12/0 -DBruno_Santos -N12:12/1 -SHi -T\txt\msg.txt -#PKH Ex 2: NET -B12:12/1 -OJoe_Hodges -DFabio_Becker -N12:12/0 -S\prg.arj -#PKF Ex 3: NET -B12:12/0 -Duucp -Uclovis@ear.anpe.br -SHi_Clovis -#PKC Ex 4: NET -DEduardo_Wei -N12:1241/2 -Iabc EX 5: NET -DJorge_Eduardo -N12:1231/2 -CJorge_Eduardo -M -G -F40 -L10 EX 6: NET -Z -N12:1241/2 EX 7: NET -Y -C -N1:125/3150 -DTroy_Engel Syntax: MGTOOLS TIC NOTIFY/HELP MGTOOLS MAINT You may use NOTIFY and/or HELP in the same command line. Following these commands, you add as many nodes as you want. To send to all nodes in the Node Manager, use *. It is also possible to use * to delimiter part of the node, for example, 12:1280/* The MAINT function performs clean-up service in the HOLD directory, where *.TIC files are stored. TIC files without file attaches will be deleted, as well as files in the HOLD\TEMP subdirectory without file attaches. These files are stored in the TEMP directory because they had their original compression converted to another one, which means that the converted file was imported to the BBS, while the original file had to be moved to TEMP for TIC transmission to downlinks. Syntax: MGTOOLS DUMP -N1 -N2 -U[IDs] -N1 Primary Nodelist -N2 Secondary Nodelist -U* nodelist, with optional User ID. If omitted, all users are included, if not, only those users that match the same IDs in their configuration. The optional switch will force -N1 or -N2 to dump a complete list with all information for each BBS. If ommitted, only the node number and the Name of the Sysop will be displayed. The Fido_*.HED and FIDO_*.FOT files in the "Nodelist Directory" will be included in the result. Syntax: MGTOOLS RAUSER DestFile NodeFrom Subject UsersDir where: DestFile - Name of the destination file. It will be placed in the MSG subdirectory, inside "Fido Server Path" NodeFrom - Node of the BBS Subject - Subject of the message. Use _ instead of spaces. UsersDir - Directory where the RA user database is located This function will create a text control file, compatible with the netmail server of MG, containing all local users of the BBS, located in the user database of RA 2.00 or compatible. Syntax: MGTOOLS MAINT Maintenance of the system. 1 - TIC control files without file attaches will be deleted. .. [005] MG*.EXE MailGate Main programs. MGSETUP.EXE, MG.EXE and MGE.EXE MGSETUP.EXE is the program that allows you to configure every single detail of the operation of MailGate. If you are installing MailGate for the first time, that is, if you have just unpacked the original MailGate package, you will have to run MGSETUP, writing INSTALL in the DOS command line. MGSETUP detects the MGINSTAL parameter and installs MailGate in your Hard Disk, with all important subdirectories and all files in the corresponding places. In almost all options of MGSETUP, you can press F1 to obtain an on-line help, which is exactly the same you have in the MG.DOC file. MGE.EXE is the message base editor program, that gives access to the netmail folder and to echomail areas, allowing you to read, edit, manage all messages in the system. MG.EXE is the main executable file in the MailGate package. After you press ESC to exit this menu, the same help menu of MailGate that you get by running MG ? will be displayed. Syntax: MG ....[optional extensions] Switches override the configuration setup. +M (Process Fidonet Netmail folder) -M (disable) +T (Toss Inbound UUCP email as PKT) -T (disable) +U (Gateway Fido Netmail to Internet) -U (disable) +F (Netmail Gateway between 2 Fido nets) -F (disable) +S (Process UUCP Server requests) -S (disable) +R (Process FIDO Server requests) -R (disable) +Z (Process netmail automatic Server) -Z (disable) +W (Process echomail automatic Server) -W (disable) +E (Fidonet files to Internet) -E (disable) +A (Netmail to Fax messages) -A (disable) +I (Execute all TIC functions) -I (disable) +Q (Execute netmail ALIAS manager) -Q (disable) +J (Execute customized program Exit) -J (disable) +X[grades] (Send-Fax. Grades determine fax priority. *=All) -X (disable) +Y[grades] (Send-Fax. Exit with Fax errorlevel) -Y (disable) System errorlevels 0 - Nothing was processed 1 - PKT mail generated 2 - UUCP mail generated 3 - PKT and UUCP mail generated 4 - MSG mail generated 5 - PKT and MSG mail generated 6 - UUCP and MSG mail generated 7 - PKT, UUCP and MSG mail generated 8 - FAX mail generated 9 - PKT and FAX mail generated 10 - UUCP and FAX mail generated 11 - PKT, UUCP and FAX mail generated 12 - MSG and FAX mail generated 13 - PKT, MSG and FAX mail generated 14 - UUCP, MSG and FAX mail generated 15 - PKT, UUCP, MSG and FAX mail generated 32 - Error in configuration or invalid registration key 33 - Write disk error. Disk may be full 40 - Fatal error in the system. Please inform us about it! .. [006] MGDOC.TXT Creating and customizing your own DOC The original package of MailGate comes with a relatively simple DOC. You may wish to improve it, translate it to another language, or just start from scratch. The first step is to create a file called MGDOC.TXT, that contains all menus and commands found in MGSETUP. You will only need to include your own text after each line. After you finish your DOC, compile it, creating the final DOC file called MG.DOC. This file cannot be modified under any circunstances. It looks like a normal text file, but in fact, it is a typed file that is accessed by MG with the help of an index file. .. [007] MG.DOC Create the final version of your DOC. MailGate will compile the previously updated MGDOC.TXT file and the result will be the file MG.DOC and an index file, MGDOC.IDX. After this compilation, the help on line function, F1, will start working. .. [008] MailGate FAQs This option will be constantly updated by us and by our users who wish to send their contribution. Any update in the DOCS is easy to be implemented. The original package of MG contains the MGDOC.TXT file, which is the main source information MG needs to compile and create the final indexed DOC, MG.DOC. What will have to be done is include new information in MGDOC.TXT and then compile MG.DOC afterwards. We will rely on the good will of our users for the improvement of the current DOC. Credits will be given, the name of the sysop and information about his system will be supplied with the DOC update he sends. .. [010] MailGate Information General information about the program, included in the beginning of this help file. .. [011] FIDO config Basic Fidonet configuration such as system information, nodelist names and echomail areas for special operations should be entered here. You have to supply information about the 2 Fidonet networks you operate with. Each network must be identified by one letter. These 2 letters will be used by MailGate to name some directories and database files. When compiling the nodelists of your 2 networks, they will be named according to these Net IDs. If you run only one network, give a generic identification for the network not in use and leave the entries for the nodelist names empty. System information will be used in the TIC process of files, when sending echomail and netmail return receipts. If you are a registered user, do not forget to match the sysop name with the supplied name in your registration key. If you leave the nodelist names without extension, Mailgate will look for the first file that has a valid numeric extension, and compile it. .. [012] UUCP config UUCP stands for Unix-To-Unix Copy. It is used as a means for two Unix machines to communicate and exchange data. Some implementations of this protocol were created to make it possible for a non-Unix machine to exchange data with a Unix machine. This way, your PC compatible computer can send and receive mail and files to the Internet, UUCP network, Usenet and so on. It works in a way similar to the Front-end mailers BBS's use to communicate. "UUCP" and "Internet", even though they are two distinct things, are sometimes used when the other one is more appropriate. For the sake of simplicity, we will refer to UUCP in MailGate, meaning the protocol itself, the software package used to run it, or any other network, like Internet or Usenet. To run UUCP with MailGate, you will need one of the many UUCP packages available everywhere. In the DOC, we recommend the one that is actually running in our system. .. [013] TIC config TIC processing enables you to control the flow of files in and out of your system automatically. It works in a way similar to echomail. You may distribute files to nodes listed in a specific area. Inbound files, coming from systems allowed to send them, will be distributed to the other systems that are listed in your configuration as well. Your system can also scan some file areas locally, search for new files, and automatically distribute them. Numbered release of files, like NODEDIFF and NODELIST are compressed and hatched to your downlinks. Some special status may be issued to some systems so that they can control your TIC manager remotely. MAGIC files are also allowed, thus giving particular and customized actions when such files are processed. You may also provide a DOS batch file for each TIC area, so that the received files may be processed the way you want. 26 groups of TIC areas are available for organizing your TIC areas. TIC processing may be sent to echomail areas. RAID support is available for remote maintenance. You may select FILES.BBS or the internal Remote Access file database to be used in individual TIC areas. FILE_ID.DIZ files are removed from inbound files and used as a complete file description. .. [014] System General options of the MailGate configuration are entered here. One part consists of how MailGate will swap to and from memory whenever a second EXEcutable file is executed by MailGate. If no memory is available, MailGate will swap itself on disk, which considerably slows down the operation of MailGate. Extended memory will be needed by MailGate quite often, since most of its functions will be swap to and from memory. Please check for the existence of an extended manager in your system. MailGate will send a message when it is executed, saying whether or not it managed to activate the extended memory manager. .. [015] Area Manager This is the heart of the program. All message areas are located here, and within each area, everything related to echomail gateway, listservers, newsgroups, fax gateway and so on, are configured. .. [016] Text Files Some text files are used by the system to notify users when they try to use one of the functions available in MailGate. Edit them and customize these files to meet your needs. They must all be stored in the directory that you configure in the DIRECTORY menu, designed for this purpose. Note that the system comes with all text files you need to start working. Just change them when necessary. Some special characters are used inside these files, so that they can be substituted by the SUBJECT, DATE and USERTO of the processed mail. They are: %D for the Date/time %S for the Subject %L for the UserTo or for a List name in case of mail to the ListServer These switches MUST be in capital letters. In some of the Text files, these switches will have different purposes. Please check the Help for each entry and also, verify how each sample .. [017] Fax config MailGate provides a very powerful Fax mail Server. You may run your Fax server in different ways. First, all users may use the gateway with no restrictions, that is, any phone number or database entry may be used. The second option, only VIP users identified in your FAX nodelist may use the gateway, provided they use the correct password. Optionally, you may allow non-VIP users to send local Faxes, or disable non-VIP access totally. Faxes may be sent to destinations listed in Database files you configure in the system. For example, if a database is created under the name of COMPUTERS, any netmail sent with subject COMPUTERS will be Faxed to all entries. VIP users, non-VIP users and Database files can be assigned with Fax priority flags. By running Mailgate with the proper switches, you may select the Fax mail to be sent. A Fax program of your choice must be known by MailGate for proper operation. MailGate has the option to exit with the Fax errorlevel. Run MG -? for details about the switches. You may include a front page in all Fax messages. Just create a file called BANNER.FAX and place it in the "FAX Path". .. [018] Alias config MailGate provides a very powerful ALIAS manager. It operates in the UUCP and FAX servers. Mail to the UUCP gateway must be sent to the user "UUCP", in the UUCP node number. But most common UUCP destinations can be given an ALIAS, and also a specific destination node. If such ALIAS receives mail, the UUCP server will send the mail to the real UUCP destination, as configured in the ALIAS entry. The same method applies to FAX mail. Mail to the FAX server must be sent to the user "FAX", in one of your BBS/Gateway nodes. But you may define an ALIAS user (that may be a real user name), and any mail received to this ALIAS user will be faxed to either a phone number or a Database file, according to what you configured in the ALIAS entry. .. [019] Change user This option allows a new user to enter the system, without having to leave MGSETUP. .. [01A] Color config Customize the look of all menus, selecting colors for the background, foreground, border, menu bars. .. [01B] DOS shell Access to the DOS prompt. After you finish the DOS shell, type EXIT to return to MGSETUP. .. [01C] Exit Exit the system and save any update in the configuration. .. [020] Run-Time Options Several flags are provided for the system to operate according to your specific needs. They are used to enable or disable almost all functions of MailGate. Once configured, they are used as default settings for the operation of MailGate. They can, however, be overridden by the DOS command line. Run MailGate using one or more switches as explained in the ON-LINE Help. If you run MG -? you will get the list of switches. .. [021] Node Numbers Node numbers needed for the network to operate in Fidonet gateway mode. MailGate can deal with 2 Fidonet-compatible networks. They are called Primary and Secondary networks. The system will need information for the Primary network, and it is optional to provide information for the Secondary network, if there is any. These 4 node numbers are very important. For each network, primary or secondary, there are two node numbers, the first called "BBS" and the second, "Gateway". One example will make it clear to understand what these nodes are for. The "BBS" node is used by MG as the node that will receive any notification via netmail, all netmail reports and automatic replies. MG will automatically select which one, Primary or Secondary, will match the netmail in which it is operate on. The "gateway" node will only be used if any kind of echomail gateway will be done using the "fake" system. When generating PKT (echomail), MailGate may use the fake gateway system, instead of operating directly in the message base, as would do any echomail tosser. Instead of depending on any particular type of message area, MG creates PKT files, that will be processed by the echomail tosser afterwards. In this situation, the same PKT file may be processed by a Squish-compatible tosser, or JAM, Hudson, or any other type. But for the PKT file to be generated, it needs a From: and a To: node numbers. As a matter of fact, if there is a PKT file around, it is because a node number generated it to another node number. Here is where the Gateway node operates. Since the BBS node is probably one of the AKA nodes of your system, the gateway node will generate the PKT file to the BBS node. Therefore, It must not be a node LOCAL to your system. Imagine the gateway node as the node from the system across the system, that send you echomail regularly, in other words, the gateway node is one of the up/downlinks in your echomail system. For a matter of simplicity, let us assume that the gateway node is a point of your BBS. With examples, this is how things should work: BBS Node : 4:808/2 (local to the system) Gateway node: 4:808/2.1 (remote node) Taking one echomail area as an example, BBSING, MailGate will generate PKT files from: 4:808/2.1 to: 4:808/2. For the PKT to be tossed properly by my echomail utility, 4:808/2 must be the main node of BBSING and 4:808/2.1 must be one of the downlinks of this area. Similar situation takes place for the nodes in the secondary area. But these nodes, BBS and Gateway, are not only used for the PKT gateway system. They are also used for netmail-to-netmail gateway between the primary and secondary networks. Suppose that the Primary network is Fidonet (using the same example above), and that the secondary network is RBT (BBS Node: 12:1280/1 and Gateway node 12:1280/1.1). A netmail sent to 4:808/2.1, in the Fidonet domain, will be sent to RBT from: 12:1280/1.1 and vice versa. How to send netmail through the primary and secondary networks will be covered below. The process discussed here is documented in FSC-0078. You may read the official document or read the original scratch below, as it was sent to the Fidonet standards committee. Note: An outdated reference to the Secondary network was made as "Fakenet", which was substituted after some sysops claimed it could be dubious. ABSTRACT The word FakeNet will be used in this abstract to refer to any Fido-compatible network that is not in the Fidonet nodelist, thus using node numbers not found in the 1-through-6 Fidonet zones. A Fakenet uses its own nodelist. There is a large number of Fakenets all over, each one unaware of the existence of the others, some using the same node numbers in their own nodelists. We shall try to put these networks together, not by forcing any of them into a single nodelist, but by making them aware of the existence of the others, and providing gateways in each of these networks so that mail can flow in both directions. IMPLEMENTATION For a gateway to be implemented, extra information must be provided in the netmail. Normally, two user names, From: and To: define the sender and the addressee. The node numbers go "inside" the netmail and have their existences checked in the nodelist of the network in question by the local running software. Since we now have 2 networks, the extra information must be the remote node in the destination network, which obviously cannot be found in the local nodelist, and the local node that must reach the remote addressee, otherwise a reply cannot be made. Suppose, for example, that there are 2 Fakenets, one based in zone 10 (network 1), the other one in zone 11 (network 2), and that user John Green in node 10:100/1 wants to send a netmail to Paul Brown in 11:200/1. In both networks, a gateway node (common to both nodelists) must be provided. Let us say that node 10:10/1 is the gateway in network 1, named "Gateway system A" and node 11:11/1, named "Gateway system B" is the gateway in network 2. What John, from network 1, will have to do is: Send a netmail to his local gateway node, which is 10:10/1. In the To: field, he will put, besides the name of the addressee, Paul Brown, PAUL'S NODE NUMBER, 11:200/1, inside (). This is the extra information needed for the gateway to work. What will happen is: This netmail, in the domain of network 1, will travel the route and reach the gateway, 10:10/1. This gateway system must do the following: Change the domain of the netmail from network 1 to network 2. This means that any reference to node numbers in the netmail header must be updated. Thus, the netmail will now have the node 11:11/1 as the originating node, and 11:200/1 as the destination node, "hard coded" in its header. But we can see that John's node number must be provided, otherwise Paul will not be capable of replying. This is done by the gateway software that includes John's node number in his From: name field, inside (). When Paul receives John's netmail, he will reply, and the From: field will automatically become the new To: field, and will contain John's name and node number. The netmail will reach back 11:11/1 and the process will be exactly the same, finally returning to John. In short, this is the odyssey of John's netmail to Paul: 1 - John enters his message to Paul. Since Paul is not in John's network, John will have to use the gateway. He sends a netmail to his local gateway system, 10:10/1 which looks like this: From: John Green, John's BBS (10:100/1) To : Paul Brown (11:200/1), Gateway System A (10:10/1) Re : Hello ------ body of message ...... Note that John had to MANUALLY enter Paul's node number and put it in the To: field, together with Paul's name. This netmail is addressed to Gateway System A, node 10:10/1. 2 - After arriving in 10:10/1, the gateway software will create a new netmail that looks like this: From: John Green (10:100/1), Gateway System B (11:11/1) To : Paul Brown, Paul's BBS (11:200/1) Re : Hello ---- body of message.... Note that John's node number was inserted in the From: field, which is the information needed for bi-directional gateway to work. 3 - This netmail is now in the domain of network 2. It will travel the normal route and reach Paul. When he replies, the local message editor will make the From: field become the To: field. The netmail-reply will look like this: From: Paul Brown, Paul's system (11:200/1) To : John Green (10:100/1), Gateway System B (11:11/1) Re : Hello ---- body of new message..... This netmail will travel the route and reach 11:11/1. The process now is exactly the one used to gate the original netmail from network 1 to 2. The gateway software will create a new netmail that looks like this: From: Paul Brown (11:200/1), Gateway System A (10:10/1) To : John Green, John's system (10:100/1) Re : Hello ---- body of new message.... Note that Paul's node number was inserted in the From: field, finishing the gateway process. The only trade-off in the current proposal is obvious. The limited length of the name fields, which, according to FSC-0001, is 36 characters long, and that may not allow the inclusion of the person's node number in it. For example, if John's full name were John Green Richardson Smith Jr., he would have sent his netmail to Paul, but the gateway system would fail when attempting to include his node, 10:100/1 together with his name. In this case, the netmail is bounced back with a warning message, and it will be John's responsibility to use a shorter version of his name or an alias. It seems that more and more people are being practical and using only 2-word names, so this is a problem that can be easily worked out by the local BBS operator. Lastly, ^aINTL kludges must be issued in all netmail flowing through the 2 networks. This proposal follows FSC-0034 and FSC-0001. It also allows immediate application, since it relies on what Fidonet is in essence, FSC-0001. .. [022] Directories These directories are needed for MailGate to work properly. If not correctly configured, MailGate will abort and send a warning message. Some of these directories must match with those specified in the other BBS programs you run, since MailGate will read and write mail and information to them. The names are suggestive and the pre-configured directories will give you no doubt about what they are for. If you do not provide the drive name, MailGate can operate throughout a network based system. Note that a SET statement should be provided in your AUTOEXEC.BAT to help MailGate locate the main configuration directory. Use SET MG=C:\MG if this is the directory where you configured MailGate and MG.CFG. Add in the PATH line where the EXE files are and MailGate can run from any directory. MailGate will first look for MG.CFG in the current path, then in the SET command. In this manner, you can have as many different configurations as you want, and different configurations may share the same directories. .. [023] Site Information This is where you will supply all the important information about your system, that will be used by MailGate in TIC netmail distribution and TIC echomail reports. .. [024] Fidonet Nodelists Configuration of Nodelist files and Fidonet mailer system in use. .. [025] Special users MailGate treats netmail addressed to certain users in a special manner. For example, netmail sent to "fax" may be forwarded to the fax server, netmail to "mgserver" may be processed by the netmail server, and so on. You may also define up to 5 special users, and netmail sent to them will be stored in ascii files in a special subdirectory inside the Fido path. This subdirectory will be named after the special user's name. This is particularly useful for programmers who wish to have full control over netmail messages. For example, if there is a special user called PROCDATA, any netmail sent to this user will be saved in \MG\FIDO\PROCDATA, and a special program may update a database. .. [026] Origin lines Set of origin lines that may be called and used during the configuration of echomail areas in the Areas manager. .. [027] Node Manager Configuration of Fidonet systems that exchange echomail with your BBS. This will only be available in future releases of MailGate, when there will be an internal echomail tosser. .. [028] Primary ID Use any letter or number to uniquely identify the nodelist of the Fidonet domain of this configuration of MailGate. The system will use this identification to create the subdirectory that will contain the compiled nodelist. The compiled nodelist is stored in the "Node Path". The subdirectory will have the name FIDO_*, where * is the identification, as configured here. This is useful if you are going to run multiple configurations of MailGate ("MailGate Information" Menu. It also avoids the duplication of nodelist compilations. .. [029] Secondary ID This is the letter that identifies the Secondary Network. It is used to name the nodelist subdirectory where the compilations of the secondary nodelist are stored. .. [02A] Message size in PKT Maximum size of individual messages within a PKT file. Almost all echomail tossers limit the sizes of a message in 64kbytes. Messages larger than that are discarded. Set to 0, MG will not split an individual message in many others that would fit the limit defined here. This is particularly useful when MG tosses mail from the Internet, where very large messages are not uncommon. .. [02B] Maximum size of PKT Some sysops like to sort out the messages within a PKT file, and the size of the PKT file is important. Set to a value different than 0, MG will start working on a new PKT file whenever the current file exceeds the limit established here. .. [02C] MSG Size Echomail tossers are generally the programs that also import a netmail message into the message base. They also pack netmail within an echomail bundle. During these processes, netmail messages may be truncated if they are larger than a certain limit (also no larger than 64k). If this is the case, force MG to split a message into as many *.MSG as needed. .. [02D] MSGID standard Type of MSGID generated for new Fido and UUCP mail and also during gateway between Fido and UUCP. .. [030] Process Netmail Folder This is a global option that overrides all other options that define the operation of functions over netmail. If OFF, the NetMail folder will not be scanned and no function related to netmail will be executed. .. [031] Netmail-to-Netmail Process netmail addressed to the gateway between Primary and Secondary networks. Check the Help for Primary Node for details. .. [032] Fido Server If ON, MailGate will execute netmail addressed to the "MGSERVER" function. The netmail information will be saved in a .MGF file located in the \MG\FIDO\MGSERVER directory. If a function is recognized to be an internal function of the "MGSERVER", MailGate will process it and send the result of the request back to the sender. If a function is not one of the internal functions of MailGate, they will be saved in the .MGF file so that third part utilities can process them as desired. .. [033] DOS Server Accept and process netmail addressed to the DOS server. Netmail sent to this user will be saved as a *.BAT file and executed by a call to COMMAND.COM. In the subject field of the netmail must come the name of the file, located in \MG\FIDO\PASSWORD, with extension *.PSW, that contains the valid commands that may be called by the batch file. If the commands are not found, they will not be executed. If the subject fields does not match a text file in the PASSWORD directory, the function will be aborted. .. [034] Alias Server MailGate provides a powerful function for the UUCP and Fax servers. You may define different users and names and ask MailGate to interpret mail to these users as mail either to the UUCP Gateway or to the FAX Gateway. The configuration of the ALIAS Database has to be done in the ALIAS menu. For example, any netmail to INTERNATIONAL HOTEL at 12:1280/10 may be sent to the Fax server as a Fax message for phone 341-4241. Mail to UNIVERSITY at 12:1280/15 may be sent to the UUCP gateway as mail postmast@univ.edu. This works as if the netmail were sent to the traditional UUCP user and the TO: line was inserted in the first line with the UUCP destination, postmast@univ.edu. .. [035] FIDO MSG Server MailGate can send customized text messages as netmail to destinations you desire, provided you edit the .CTL file in the Fido Server Path, inside the subdirectory MSG. The text files have to be located in the Fido Server Path, with extensions .TXT. Please refer to the "Directories" Menu, and select the option to configure the "Fido Server Path" for more details. This option cannot be set to ON in here. The only way to activate this function is via the proper switch when running MailGate from the DOS prompt. Run MG -? for details on the switches. .. [036] FIDO PKT Server MailGate can send customized text messages as echomail to Echomail Areas you desire, provided you edit the .CTL file in the "Fido Server Path", inside the subdirectory PKT. The text files have to be located in the "Fido Server Path", with extensions .TXT. This option cannot be set to ON in here. The only way to activate this function is via the proper switch when running MailGate from the DOS prompt. Run MG -? for details on the switches. .. [037] Notify Error in Name During the Fidonet-Fidonet gateway of netmail, if the name of the originating user is too long, the system will be unable to insert the originating node, because of the way MailGate processes this kind of gateway. This text can be configured in the Text Files Menu. .. [038] Notify Not in Nodelist If ON, a warning message will be sent to the user who tried to send a netmail to the netmail-netmail gateway, but whose node is not found in the nodelist. MailGate works with two nodelists. They are compiled using the utility MGTOOLS (refer to the "MailGate Information" Menu for details). MailGate will only check for the existence of the originating node in the nodelist if the "Ignore Nodelists" option is set to OFF. This text message message can be configured and edited in the "Text Files" Menu. .. [040] Notify Fido If ON, MailGate will send a confirmation receipt to a user after netmail to the Fidonet Gateway is processed. The text message can be configured and edited in the "Text FiLes" Menu. .. [041] Dump netmail If ON, MailGate will save all processed netmail in an ASCII file, which is configured in the "System" Menu. This will be done on all netmail processed by any of the functions of MailGate. .. [042] KILL-SENT This option overrides the "Kill" flag of the netmail, forcing MailGate to delete all netmail processed by any of the functions of MailGate. If this option is set to OFF and the netmail does not have the "Kill" flag, MailGate will assign the netmail with the "Sent" flag. .. [043] DEL-SENT If ON, MailGate will delete files attached to netmail that has been processed by any of the functions of MailGate. This often occurs with the "Echomail to Echomail gateway". If the netmail file attach does not have the "Kill after sent" flag ON, MailGate will issue the "Sent" flag to this netmail. .. [044] DEL Bad Netmail If ON, MailGate will delete any netmail that seems to be in bad format. This is done basically when a netmail has a size less than 190 bytes or has control heading larger than 2 Kbytes. Please use this option only if you are sure it is necessary. Sometimes, there are situations where an echomail utility wrongly generates crippled netmail (less than 190 bytes), and it may be useful to delete it. .. [045] Auto Node MG.EXE and MGSETUP.EXE will automatically check if the configured Primary/Secondary nodelists have been previously compiled by MGTOOLS, or if they have been damaged. If problems are detected, MailGate will compile the nodelists again. .. [046] Full Quote If ON, MailGate will use the initials of the sender of a message that you are going to quote, in reply to the original message. If OFF, MailGate will only use the symbol > for the quote. .. [047] Convert Files This option will only be useful if you use Binkley or Portal of Power. If netmail file attaches are created, using Front-door's format, MG will find these netmail messages and update the corresponding Binkley files in the outbound directory. This might be useful if you are using MG's message editor and want to send a file attach without too much work. .. [048] Ignore Nodelists Normally, MailGate validates To: and From: node numbers from netmail to the Fidonet Gateway system. This avoids wrong netmail flowing through the netmail gateway, but will take a little bit of extra time for MailGate to scan through the nodelist database. If this flag is set to ON, MailGate will process mail through the netmail gateway without restriction. .. [050] BBS Sysop Name of the local System operator (Sysop). This entry must match with the name supplied when your registration key was created, otherwise the registration key will be ignored. .. [051] BBS Name Supply the name of your system here. .. [052] BBS Info1 This entry is available for any information about your system. .. [053] BBS Info2 This entry is available for any information about your system. .. [054] BBS Phone The phone number of your system is configured here. .. [055] BBS Flags Supply general information about the operation of your system, if it is CM (Crash mail), the type of modem you have (V32, V32b, V42b) and other useful flags. .. [060] Fido Nodelist 1 Full path/name of the main nodelist in the primary network. .. [061] Fido Nodelist 2 Full path/name of the secondary nodelist in the primary network. .. [062] Secd Nodelist 1 Full path/name of the primary nodelist in the secondary network. .. [063] Secd Nodelist 2 Full path/name of the secondary nodelist in the secondary network. .. [064] Semaphore File used to force a rescan in the netmail folder of your Front-end mailer. This file is generally necessary whenever a program creates netmail messages and the mailer needs to update its indexes. .. [065] Mailer Type MailGate needs to look for echomail file attaches addressed to one of the gateway nodes. File attaches may be compatible with the Front-Door system or with the system used by Binkley and Portal of Power. For operation under Binkley, please refer to MGBINK.BAT for details on how to generate netmail file attaches for some functions that cannot run if not enough information is supplied. .. [070] ARCmail The universal name used for Echomail file attaches is ARCmail, but you can supply a different name. MailGate searches for netmail file attaches originated by this "user" to identify and later process echomail functions, such as Echomail to Echomail gateway, echomail to UUCP Gateway, Echomail to Fax Gateway and Echomail to FileFix gateway. .. [071] FileFix Echomail or netmail sent to this user will be processed by the FileFix function of the TIC server. MailGate will scan the file base of the system and look for files that match what was requested in the subject line. Please refer to the FileFix database in the TIC menu for more details. .. [072] Fax user Netmail sent to this user will be converted to text file and sent to the spool fax directory for later delivery by the Fax server. User "Fax" comes pre-configured. .. [073] DOS server Accept and process netmail addressed to the DOS server. Netmail sent to this user will be saved as a *.BAT file and executed by a call to COMMAND.COM. In the subject field of the netmail must come the name of the file, located in \MG\FIDO\PASSWORD, with extension *.PSW, that contains the valid commands that may be called by the batch file. If the commands are not found, they will not be executed. If the subject fields does not match a text file in the PASSWORD directory, the function will be aborted. .. [074] MG server Netmail sent to this user will be processed by the internal netmail server of MailGate. Please check the help for the Fido Server Path for more details. .. [075] Fido AreaFix Netmail sent to this user will be processed by the echomail areafix of MailGate. This function is not available until the echomail tosser is implemented in future releases of MailGate. .. [076] Special user 1 The mgserver function is internal to MailGate, with the functions already explained in the Fido Server Path section of this DOC. But you may wish to force Mailgate to save netmail messages as they arrive in your system, addressed to special users. For example, a netmail sent to "update" will be saved in \MG\FIDO\UPDATE, and another utility might operate on this text message. .. [077] Special user 2 The mgserver function is internal to MailGate, with the functions already explained in the Fido Server Path section of this DOC. But you may wish to force Mailgate to save netmail messages as they arrive in your system, addressed to special users. For example, a netmail sent to "update" will be saved in \MG\FIDO\UPDATE, and another utility might operate on this text message. .. [078] Special user 3 The mgserver function is internal to MailGate, with the functions already explained in the Fido Server Path section of this DOC. But you may wish to force Mailgate to save netmail messages as they arrive in your system, addressed to special users. For example, a netmail sent to "update" will be saved in \MG\FIDO\UPDATE, and another utility might operate on this text message. .. [079] Special user 4 The mgserver function is internal to MailGate, with the functions already explained in the Fido Server Path section of this DOC. But you may wish to force Mailgate to save netmail messages as they arrive in your system, addressed to special users. For example, a netmail sent to "update" will be saved in \MG\FIDO\UPDATE, and another utility might operate on this text message. .. [07A] Special user 5 The mgserver function is internal to MailGate, with the functions already explained in the Fido Server Path section of this DOC. But you may wish to force Mailgate to save netmail messages as they arrive in your system, addressed to special users. For example, a netmail sent to "update" will be saved in \MG\FIDO\UPDATE, and another utility might operate on this text message. .. [080] Origin Line Edit the origin line that will be used when configuring message areas in the Area Manager. .. [090] NodeNumber Node number that has access to the echomail system and areafix server. .. [091] Sysop Name of system operator of NodeNumber. .. [092] Packet pwd Password required for protecting the PKT files. This is optional. .. [093] AreaFix Pwd Password needed to access the areafix server for this node. This password must be sent in the subject line of the requesting netmail. .. [094] Compressor Type of compression used to archive echomail packets to NodeNumber. .. [095] Flags 1 Operational flags that define the behavior of NodeNumber. .. [096] Flags 2 Operational flags that define the behavior of NodeNumber. .. [0A0] UUCP Server Path This directory processes requests and commands from special UUCP users, and in this current version, LISTSERV is available. For the server to work, a subdirectory with exactly the same name must be created inside this Path. MailGate goes as far as processing inbound/outbound UUCP mail that flows through the system. A third part package will do the job of transferring the UUCP Mail to your Host site. Please pay special attention to the copyright and legal restrictions of such packages. We will not be held responsible for the legal aspects or any problems that arise from the misuse of them, nor will any of these package owners be responsible for MailGate. Inside this directory, you must create four subdirectories: LISTSERV and LISTSERV\PUBLIC ALIASES and REQUEST LISTSERV activates the local Listserver that MailGate uses to manage the local generated Lists of your system. LISTSERV\PUBLIC will allow your system to have public files that can be requested by anyone when issuing the GET command. The users will not have to subscribe on any of the local Lists to request files from the system. They must, however, be located in the PUBLIC subdirectory or listed in the GETALIAS.SRV file. In the LISTSERV subdirectory you must create these text files: HELP.SRV - Text sent when the Listserver receives the HELP command QUERY.SRV - Text sent when the Listserver receives the QUERY command RELEASE.SRV - Text sent when the Listserver receives the RELEASE command INFO.SRV - Text sent when the Listserver receives the INFO command LISTS.SRV - Text sent when the Listserver receives the LIST command GETALIAS.SRV - List with Alias files available for the GET command INFO files (requested with the INFO command) must have name extension .INF and be located in the LISTSERV subdirectory. The GETALIAS.SRV file contains a list of files available for the GET command, but different directories. The format is: ALIASFILE FULL_PATH/NAME ALIASES subdirectory - This directory stores the text files that contain UUCP destinations to be requested by messages in Carbon copy. If a message to the UUCP Gateway contains a To:, cc: or Bcc:, followed by a filename located in this directory, MailGate will carbon copy the message to all destinations found in the alias file. REQUEST subdirectory - Special text files, normally announcements, ads, help messages may be stored here. Remote Internet users may request these files automatically. For example, if a message is sent to help@ear.anpe.br, MailGate will look for the file HELP in the REQUEST directory, and if found, the text will be sent to the requesting user. The original message, however, will still be sent to the postmaster. Two sample files are given. The first one if an example of an alias file, the second one is an example of a REQUESTable file. ;this is a list of common UUCP destinations ; ;the letters ; or # are used for comments, and are ignored. #the REQUEST subdirectory may contain any number of text files. # clovis@ear.anpe.br john@ear.anpe.br paul@ttbbs.ax.apc.org richard@ttbbs.ibase.org.br Dear friend, Thanks for your message. This is a help file that contains detailed information about our system, and what you need to do to become a registered user ........ .. [0A1] UUE FilePath One of the powerful features of MailGate is to transparently transport compressed FidoNet echomail between UUCP remote sites as if these files were single text messages. You do not need to worry about making phone calls to route your echomail compressed packets. Nor should you have to transfer binary files with the FTP protocol. Neither should you lose time manually encoding and decoding binary files into and from text messages because MailGate will handle all of this for you, automatically and efficiently. An example will help us explain how the process occurs and how it should be monitored by you. Echomail compressed packets (those familiar *.MO1, *.TU1, *.WE4) are normally exchanged between Fidonet systems through Fidonet telephone sessions, with the use of many good Front-End mailers. These files are binary, which means that, unlike ASCII text messages, they hold data in an unpredictable manner, with bytes ranging from 0 to 255 in value. Of course, it is impossible to simply "insert" these files in a message and send them to a remote site. Binary files, however, can be encoded to a suitable ASCII format, thus being able to be sent as a normal message. The other end will pick up the message and decode it into the original binary file. The methods UUENCODE/UUDECODE and XXENCODE/XXDECODE are the most commonly used in the Unix world, and ended up being widely used in the PC world as well. This way, two Internet users can exchange binary files even if they do not have access to TELNET or FTP, and can only access their mail-boxes. Even though this is possible, manual processes are needed to encode the binary file, send it as messages, receive, sort, rename and re-build them through decodification, therefore having the final binary file as it originally existed. With this process, Fidonet sysops exchange Echomail binary files without the need of a Fidonet phone mail session, but the process would still be manual. MailGate overcomes all of these difficulties and manages the whole process without the intervention of anybody. For this to happen, certain procedures must be followed: a) Only one system is running MailGate on one end; b) The two systems are running MailGate on both ends a) The system NOT running MailGate must manually encode/decode the binary file and send it to the UUCP user, for example, "fileserv" (Check how the other end configured its ECHO VIP users). In the subject line, he should supply an 8 bit identification, followed by the number of the current file against the total number of encoded file messages. Suppose that 12345678.MO1 will be encoded and sent to fileserv@bbs.com. After encoding the echomail file, the result were 5 ASCII files. The process should be: Manually send all files to: fileserv@bbs.com. Choosing abcdefgh as the ID (identification) for the 5 files, the subject of all 5 messages must be "abcdefgh 001/005" (first message), "abcdefgh 002/005" and so on. The "" characters are NOT to be used. b) If both users use MailGate, the process will be transparent. When mail to the UUCP user "fileserv" starts to arrive, the system will keep storing them in the UUE Directory. MailGate will later look for the complete set of messages and decode all of them into the original binary file, placing it in the FILES Directory. Refer to the "Run-Time options" for the proper flag and to MG -? for forced operation. Question: How will MailGate know which binary files to encode? Answer: Special Echomail VIP users are configured in the UUCP ECHO Nodelist ("UUCP Config" Menu). In this nodelist, you will list those user/nodes that will have file attaches to them encoded and mailed. You will supply: Full Fidonet User Name and Node number. The destination UUCP address must also be provided. This works for the destination system, but MailGate needs to identify the users who can send file attaches to the ECHO users. This way, in the UUCP VIP nodelist, you must create a VIP User with the ECH flag ON and the UUP flag also ON. The UUP flag does not need to be ON, but is usually set to ON in these cases. Question: What are the UUP and ECH Flags used for? Answer: The UUP flag will disable normal netmail messages to be sent through the UUCP gateway. The ECH flag will indicate to MailGate that file attaches generated by this Fidonet user will be sent. If you wish to send echomail bundles, create a UUCP VIP user named ARCMAIL, since this is the universally accepted user name for echomail file attaches. You might have noticed how flexible the system is. In fact, you can issue the ECH flag to any one of your UUCP VIP users, and as such, any binary file can be sent to any UUCP destination. MailGate works with the UUENCODE/UUDECODE algorithm, and these two functions are handled by MailGate internally. To finish this topic, a complete example on how to operate and use this feature will be given. Assume that two nodes want to exchange Echomail bundles through the Internet. These nodes are: System A - Node: 4:808/2 Sysop: Clovis Lacerda System B - Node: 4:805/4 Sysop: Alessandro Oliveira System A is in the Internet under the domain: ear.anpe.br System B is in the Internet under the domain: rbt.anrs.br Instead of exchanging Echomail bundles via Fidonet phone sessions, these systems will do it through the Internet. System A will configure his system as follows: He will select the "UUCP Config" Menu and choose the "Edit UUCP Users" Menu. This is the entry for System A in the configuration: UUCP User : fileserv@ear.anpe.br FidoNet Node : 4:808/2 User Name : ARCmail In the FLAG option, UUP and ECH will be set to ON The user fileserv could be any other one. The Fidonet Name is ARCmail, which is the name needed for MailGate to locate the Echomail bundles. Now, system A chooses the "Edit Echo Users" Menu and enters: UUCP User : drago@rbt.anrs.br FidoNet Node : 4:805/4 User Name : Alessandro Oliveira This is the configuration for system B: UUCP User : fileserv@rbt.anrs.br FidoNet Node : 4:805/4 User Name : ARCmail In the FLAG option, UUP and ECH will be set to ON Now, system B chooses the "Edit Echo Users" Menu and enters: UUCP User : clovis@ear.anpe.br FidoNet Node : 4:808/2 User Name : Clovis Lacerda After going through these steps, systems A and B are ready to exchange Echomail through their Internet mail-boxes. This is how MailGate operates: MailGate, in system A, will scan the netmail folder, searching for netmail file attaches from user "ARCmail". Once found, MailGate will look for ARCmail in the UUCP VIP nodelist, comparing name and node, plus the ECH flag. If this step is successful, MailGate will look for the netmail Destination user, hopefully Alessandro Oliveira in 4:805/4. If this is true, MailGate will UUENCODE the file attach (Echomail bundle) and send the result as e-mail to "MailGate File Server" . When these messages arrive in rbt.anrs.br, the other copy of MailGate will detect their arrival and temporarily store them in the "UUE FilePath". When all copies have arrived, and if the UUE Process is allowed, MailGate will restore the original binary file and place it in the FILES Directory. The file is ready to be tossed. This system has actually been working under tests, and the two domains mentioned above do exist, rbt.anrs.br is the domain of the Brazilian Fidonet-Compatible Network, RBT (Rede Brasileira de Tele-Informatica), and ear.anpe.br is the domain of the American School of Recife, generously provided and supported by the local academic community at the Federal University of PE and ITEP (Institute of Technology, PE). Our thanks go to RNP (Brazilian National Research Network) without which Internet would not be widely spread in our country. .. [0A2] UUCP Spool Path This is where your uucico program stores UUCP inbound and outbound mail. MailGate operates directly on this mail, and the format recognized by MG is compatible with Waffle's uucico, in particular, fxuucico is highly recommended. .. [0B0] Run-Time Options Several flags are provided for the system to operate according to your specific needs. They are used to enable or disable almost all functions of MailGate. Once configured, they are used as default settings for the operation of MailGate. They can, however, be overridden by the DOS command line. Run MailGate using one or more switches as explained in the ON-LINE Help. If you run MG -? you will get the list of switches. .. [0B1] Directories These directories are needed for MailGate to work properly. If not correctly configured, MailGate will abort and send a warning message. Some of these directories must match with those specified in the other BBS programs you run, since MailGate will read and write mail and information to them. The names are suggestive and the pre-configured directories will give you no doubt about what they are for. If you do not provide the drive name, MailGate can operate throughout a network based system. Note that a SET statement should be provided in your AUTOEXEC.BAT to help MailGate locate the main configuration directory. Use SET MG=C:\MG if this is the directory where you configured MailGate and MG.CFG. Add in the PATH line where the EXE files are and MailGate can run from any directory. MailGate will first look for MG.CFG in the current path, then in the SET command. In this manner, you can have as many different configurations as you want, and different configurations may share the same directories. .. [0B2] Email Gateway This menu will give you access to all details on netmail-to-email conversion and gateway. .. [0B3] UUCP system Here is where your UUCP account is configured, as well as your UUCP provider. .. [0B4] UUCP Grades UUCP mail may be assigned different priorities, depending on what they are. Different priorities are taken in consideration when mail is exchanged between two UUCP sites, and in some cases, some UUCP mail may be kept on hold and only sent in a different time of the day. MailGate provides 4 different sets of UUCP grade: Private email, mail from local listserver, UUEncoded files and newsgroups. .. [0B5] Listserver config Basic configuration to fine tune the operation of the Listserver. .. [0B6] Node Manager Configuration of UUCP systems that exchange UUCP mail with your machine. It is very important to, at least, include the main Internet provider with which your system is connected, otherwise the import (toss) operation will not occur. .. [0B7] UUCP Maps This menu gives you access to the UUCP MAP systems. This is important if you are going to supply UUCP mail to other systems in the Fidonet format (ie, netmail and echomail). MailGate has two basic ways to exchange mail with other UUCP systems: 1 - Via UUCP. For example, suppose your machine is TTBBS.COM, and you define a second machine, ABC, under your domain. In this case, the other system is assigned the ABC.TTBBS.COM domain. Mail received from your provider, destined to ABC.TTBBS.COM will be forwarded to the spool directory assigned to machine ABC. TTBBS.COM and ABC.TTBBS.COM will exchange pure UUCP mail, with no Fidonet involved. It must also be noted that the proper UUCP routing for machine ABC must be configured in the UUCP Route file, that can be found in the UUCP System Menu. This will make sure that all mail addressed to ABC will be forwarded to the right spool subdirectory. If ABC is configured in the MAP database as Fidonet node 4:808/20, MG will not create UUCP mail and forward to the ABC spool directory. Instead, it will convert the incoming UUCP mail into the Fidonet format. So, if an email comes addressed to john.green@abc.ttbbs.com, this email will become a netmail to: John Green at fidonet node 4:808/20. In the other way around, netmail coming from any user at system 4:808/20, addressed to the UUCP gateway node, will be converted to email, originated from user@abc.ttbbs.com, and placed in the main spool directory for your system be able to send it over, via your UUCP provider. .. [0B8] UUCP VIP users MailGate gives you conditions to have special users in the system, who can be assigned with unique Internet accounts, overlapping the traditional way of converting names and nodes. VIP users have privileges in the system. Netmail sent to them, coming from the Internet, can be configured to have their status set to crash mail, direct mail, hold or kill after sent. Other privileges will be detailed in the help of internal flags. .. [0B9] Echo users As explained in the "UUE FilePath" help, MailGate can send binary files to some UUCP destinations as email. This database will allow you to add the special UUCP destinations that will operate with your system. .. [0BA] Uucp special MailGate can configure up to 12 special UUCP destinations, giving remote users access to the servers of the system. 2 of them are internal to MG, the listserver and the UUCP areafix managers. The other 10 are left for you to process according to your particular needs and other external programs. .. [0BB] XLat Table Mail from Fidonet, when converted to UUCP, needs to have some characters changed to valid ASCII values, since the Internet does not welcome non-ASCII characters most of the time. Whenever the 7-bit flag is ON, either for netmail to email conversion or for PKT (echomail) to UUCP mail conversion, MG will detect the characters higher than 127 and convert according to the translation table defined in this option. .. [0C0] Toss UUCP mail If ON, MailGate will toss UUCP Mail found in the Spool directory. This option may be overridden by the proper switch in the DOS command line when running MailGate. Please run MG -? for details. UUCP Mail will then become netmail from the UUCP server or PKT (echomail) from Lists and/or Newsgroups. .. [0C1] Netmail-to-Email If ON, MailGate will process all netmail sent to the UUCP gateway at the UUCP Gateway Node. Attention: MailGate will only convert *.MSG files located in the netmail folder. By no means will you pack the netmail messages in the echomail packet. Execute MG before your system packs outbound netmail to other systems. .. [0C2] Fido-to-UUCP files The system is allowed to send file attaches, addressed to the UUCP gateway node, convert them to the uuencode format, and send to the UUCP destinations. If a netmail arrives in the system with a file attach, MG will send the text of the netmail to the destinations and, in other messages, the uuencode conversion of the file attaches. If you are using a Binkley type of system, you need to run MGBINK.BAT to be able to create netmail file attaches containing the files to be sent. .. [0C3] Convert UUE files If ON, MailGate will convert any UUENCODED file that came from the UUCP gateway. When files are converted, they are moved to the "File Path" of MG. Please refer to the "UUE FilePath" help for details. .. [0C4] Process Listserver If ON, MailGate will process mail sent to the Listserver. .. [0C5] Dump UUCP bundle After Mailgate tosses UUCP Mail, you may want to save the processed mail or simply discard it after processed. If ON, this option will force the system to move the UUCP processed files to the Spool directory, under the BACKUP subdirectory. If OFF, the system will delete processed UUCP mail. .. [0C6] UUCP VIP If ON, only VIP users found in the UUCP Nodelist may send netmail to the Internet. When OFF, any user who has a valid originating node may send mail to the Internet. Email from users not found in the UUCP Nodelist will be sent according to the UUCP address format: Username%Fnode.Nnet.Zzone.Ppoint@domain if the True gateway flag is OFF, or it will have the format username@Fnode.Nnet.Zzone.Ppoint.domain if the True gateway flag is ON. Username is the name in the FROM: field of the netmail, % is the gateway character (that can be configured in the Email Gateway Menu), and the node number is represented in the format accepted by Fidonet. The UUCP domain follows right after. Example: Netmail from John Brown at 4:808/1 will be sent as: John.Brown%f1.n808.z4@ear.anpe.br (True gateway OFF) or as John.Brown@f1.n808.z4.ear.anpe.br (True gateway ON) Mailgate follows a defined sequence to determine the type of level a message to/from the Internet must have: 1 - Check if the user is UUCP VIP 2 - Check if the user belongs to one of the MAP UUCP systems 3 - Check if the user is LOCAL VIP 4 - Check if the node number is configured in the nodelist For example: If a netmail from: John Green comes from node 4:808/20, MG will check number one. If valid, John's email might look like john@ear.anpe.br (as configured in John's entry in the UUCP VIP database). If step 1 fails, MG will look for 4:808/20 in the MAP database. If this node number is mapped with the ABC subdomain, then John's email will be John.Green@abc.ear.anpe.br (if True Gateway is ON) or John.Green%abc@ear.anpe.br ( if True Gateway is OFF) If step number 2 fails. MG will check if node 4:808/20 is listed in the AKA node menu of MGSETUP, indicating that 4:808/20 is a local node. If so, John's email will be John.Green@ear.anpe.br After step number 3, MG will only proceed if the UUCP VIP flag is OFF, indicating that non-VIP users may also use the gateway. If step 3 fails, MG will check if 4:808/20 can be found in the Fidonet nodelists, and it will do so if the "Ignore nodelist" flag is OFF. If 4:808/20 is not found, MG will discard the message and forward it to the postmaster. If MG is configured to ignore the nodelists, MG will convert the message and John's email will be John.Green%f20.n808.z4@ear.anpe.br (if True Gateway is OFF) or John.Green@f20.n808.z4.ear.anpe.br (if True Gateway s ON) .. [0C7] Local VIP If ON, netmail sent by users local to your system (From: node is one of the AKAS), will be treated as mail from VIP users. Email will have the format Username@domain. For example, if John Green sends a netmail to the UUCP gateway node, and his netmail is one of the AKA nodes, his email will be John.Green@domain. The dot separating the user name may be changed to underscore, which can be done in the Email Gateway Menu. .. [0C8] Purge Re: It is common to see subject lines from UUCP messages coming with the word RE:. If you want to remove this, set this option to ON. .. [0C9] Notify UUCP If ON, MailGate will send a confirmation receipt to a user after netmail to the UUCP Gateway is processed. The text message can be configured and edited in the "Text FiLes" Menu. .. [0CA] Notify Error UUCP If ON, the system will send a warning message to users who attempted to send netmail to the UUCP gateway but whose message did not follow the right syntax. In the "Text Files" Menu, you can configure the message that is sent to the user. Users have to send netmail to "UUCP", and in the first lines of the netmail, include a TO: line with the first addressee, and, if you wish, followed by CC: or BCC: lines with other destinations. If CC: is used, the email will include a CC: line with this destination, and if BCC: is used, the destination user will not be listed in the email. This last option is called "Blind carbon copy". All destinations users must be names containing the @ character, and they must follow one of these different ways of naming users: To: "Clovis Lacerda" Cc: clovis@ear.anpe.br (Clovis Lacerda) Bcc:clovis@ear.anpe.br Cc: The system will only process the first 8 Kbytes of netmail, where the to:, Cc: and Bcc: lines should be. This is equivalent to no less than 100 destinations in carbon copy. If the To: UUCP flag is set to ON, netmail may be addressed to the Internet destination, rather than to UUCP, and it will be processed and sent to the destination. CC: and BCC: are done as usual, in the beginning of the message text. .. [0CB] Include UUCP mail If ON, the original message will be appended to the return receipt for netmail sent to the UUCP gateway, but with wrong syntax. This will avoid having the user write the entire message again. .. [0CC] Bad UUCP Reply If ON, MailGate will keep users not found in the UUCP VIP nodelist from sending mail to some UUCP destinations. The list of bad UUCP destinations is edited in the MGUBAD_*.LST, located in the "UUCP Server Path". * indicate the number of the UUCP network, as defined in the "UUCP Config" Menu, option "UUCP Nodelist". It is useful to prevent non-Vip users from sending mail to destinations such as listserv, archie, ftpmail, which would increase the flow of mail through your system. .. [0D0] Bang Style Older UUCP systems use the bang-path type for naming a UUCP destination. In this case, the name of the destination and the full path that message has to travel is included. For example, a destination might be clovis!ear!itep!fapesp, which means that, to reach clovis, the message has to be forwarded on and on through 3 machines. Modern naming convention does not include the path of the message, since the routing process is already managed by the linked systems and is transparent to the end user. For example, mail to clovis@ear.anpe.br will reach me, no matter the route the message will go through. If this flag is set to ON, all originating names in the system will be converted to the Bang-path style. Otherwise, leave it OFF and the Internet will take care of the rest. .. [0D1] CC: Vip Only If ON, only those users with the status of UUCP VIP will be able to send netmail with carbon copy destinations. This avoids the general public from issuing messages with many destinations. If OFF, anyone may send netmail with carbon copies. .. [0D2] 7 Bits Mail from Fidonet may contain characters that are not ASCII, that is, characters higher that 127. These characters may not be welcome in the Internet highway, so you may wish to force MG to convert them to ASCII characters. MG will use the XLAT table (translation table) to convert non-ASCII characters to corresponding ASCII characters. .. [0D3] UUCP notification Mail from the Internet may be addressed to someone at your system who does not exist. This may be true if your system is only allowed to process mail from/to UUCP VIP users. In this case, you may wish to warn the original sender of the message that the destination was not found and thus, the original message was forwarded to the postmaster. .. [0D4] Not to PostMasters If the UUCP notification is ON, many times the original message was sent by the postmaster of a system. If this message reaches an unknown user at your system, a reply to that message will reach back the remote postmaster, who may probably reply and a dup loop takes place. Mail from "postmasters" are generally not issued by a human, but by an automatic service. Replying to these messages is usually annoying , so leave this option set to ON in most cases. This is also likely to occur when your system is running local lists. There may be users subscribed on the list, whose addresses may not be valid anymore, but they forgot to unsubscribe from the list. When messages are sent to these users by the listserver, they will be returned to your system as "undelivered", and the message will come back FROM: a postmaster. Set this option to ON to force MailGate not to reply to such warning messages. .. [0D5] New MSGID If set to ON, MailGate will create a new message ID in the converted netmail, as an email comes from the Internet. If OFF, MG will use the message ID of the email as the ID of the netmail. .. [0D6] Log Costs If ON, MailGate will log the usage of the gateway system by all users, in the cost database. This will allow you to control what people have been doing with the gateway. MGTOOLS has a function to process the log of any user, giving all the information for every message sent or received during a particular period of time. The final cost in kbytes will be sent in the netmail. Please check the help of MGTOOLS for more details. .. [0D7] AREA Costs If ON, MG will also log those messages that are considered echomail, which is the case of all email from remote listservers that are converted to echomail through the area manager. If OFF, only email will be logged. .. [0D8] To: UUCP If ON, MailGate will also look for a UUCP destination user in the TO: field of the netmail addressed to the UUCP gateway node. If OFF, MG will only look for destinations in the beginning of the netmail. Warning: To prevent a UUCP dup loop inside your spool directory, do not set this flag ON if the UUCP gateway node is exactly the same as the BBS node defined in the Fido Menu. What happens is that MG generates confirmation replies to every use of the system, using the BBS node number. If this node is also the UUCP gateway node, in the next run, MG will erroneously think that there is a new netmail addressed to the UUCP gateway, and take the To: field of such netmail as the UUCP destination.Since the To: field contains a name without @domain, MG considers this message as being addressed to a local user (local users do not need to be addressed by full Internet name). The message will be forwarded to the spool directory, but being local, it will be converted back to netmail, addressed to the gateway node (same as BBS node), and the whole wrong process starts again. If your UUCP gateway node is equal to the BBS node, set the To: UUCP flag OFF. As was said, UUCP destinations without the full Internet name is considered local to the system. For example, if I want to send a message to myself, I may either send it to: clovis@ear.anpe.br or simply to: clovis. The lack of domain indicates that the user is local to the configured domain. .. [0D9] From: UUCP If ON, email from the Internet, after converted to netmail, will include the Internet address of the original sender in the From: field of the netmail. If OFF, MG will put the UUCP user in the From: field. Use this option if you want to make life as easy as possible to your users, and use it in conjunction with the To: UUCP flag. This way, after receiving a netmail from the Internet, the user will just need to reply the message. The From: containing the original UUCP user will become the TO: field, and the system will normally process the reply. .. [0DA] True Gateway This flag will define the type of gateway that will be applied to email generated from any UUCP machine linked to your system. There are 2 domain methods used by MG: Assuming UUCP machine "abc" connected to local domain, ear.anpe.br 1 - True domain: clovis.lacerda@abc.ear.anpe.br 2 - Fake subdomain: clovis.lacerda%abc@ear.anpe.br where the gateway character, %, may be changed in the configuration of MG. .. [0DB] No PKT Origin Messages from echomail, converted to lists or newsgroups, will include the origin line in the converted UUCP mail, but may be totally removed if this flag is set to ON. If you wish to remove any indication that your mail comes from Fidonet, set it to ON, if you wish other users to have information about the BBS the message came from, leave it OFF. .. [0E0] Mgserver UCOSTS For any reason, you may wish to avoid the system from sending the final cost of a user's UUCP account when the user sends the UCOSTS command via netmail request to MGSERVER. MG will supply the log for the specified period, but will not include the final cost. If OFF, MG will include it. .. [0E1] Process News If OFF, MG will not process inbound newsgroups in the spool directory. This might be useful if you wish to have other programs process your newsgroups. If ON, MG will process inbound newsgroups according to the configuration from the Areas manager. .. [0E2] Notify BAD News Newsgroups not configured in the Areas manager will not be properly processed by the echomail tosser, and will eventually end up in the bad folder. In his case, the sysop will be warned of the unknown area via netmail, in case this flag is set to ON. .. [0E3] Toss bad news Newsgroups not found in the Areas manager may still be included in the PKT file. The AREA: field, in this case,will contain the entire Newsgroups: line from the RFC-822 news header. .. [0E4] List => PKT For every inbound UUCP message, MG checks if the message comes from a remote listserver, and is configured in the Areas manager to be converted to echomail, rather than a netmail to the subscribed user. This process slows down the speed of the system since the Areas database has to be accessed all the times. If no remote list is being converted to echomail, leave this flag OFF. .. [0E5] Scan VIP Users For messages being converted from echomail to UUCP (either from listservers or newsgroups), MG will check if the fidonet from: user of the message is a UUCP VIP, located in the VIP database. If so, MG will use his email rather than using the standard conversion technique that includes the fidonet node inside the email address. If this flag is set to OFF, it will avoid MG from searching the UUCP VIP database, making the system work faster. .. [0E6] Fast News This is a flag that should only be activated if you need MG working at its fastest mode. It has some restrictions: - The size of individual news messages are limited by the largest amount of RAM allocated during run-time, which may reach up to 350Kbytes in a system with few TSRs programs. Larger news will be truncated. - The newsgroups will not be forwarded to any UUCP downlinks, mail will be simply tossed to PKT (echomail). - The message will not be checked for an eventual duplication in the PATH: line of the RFC-822 header. MG assumes the other systems took care of this business. - The video will be turned off for best performance. - The Main/Gateway nodes will be taken from the default Areas configuration. - Bad news will not be tossed, nor will the sysop be notified. If your system is simply tossing Newsgroups into PKT mail, and if it processes many messages per day in many newsgroups, this option may be important. .. [0E7] Toggle UUCP machines If ON, MG, during import and export of UUCP mail, will check if the UUCP machine, configured in the UUCP Node manager, has the CNV flag set to ON, which means that out/inbound mail will have names switched. This is only needed if any of the UUCP nodes linked to your system is accessing the same computer system, via a LAN for example. .. [0E8] Alias UUCP Fidolist This flag is important if your system is going to automatically route in-transit netmail through the Internet, using information from the nodelist. MailGate provides a very powerful feature that allows this kind of gateway. The detailed description of the process is given below, and is part of a FSC proposal to the Fidonet Standard Committee. .. [0E9] Netmail info to RFC822 If the Alias UUCP Fidolist flag is active, it might be important to force MailGate to include in the processed UUCP mail (converted from in-transit netmail), the RFC-822 information from the Received: fields. This will allow the netmail receipient to track the entire path of the email/netmail, using the ^AVIA lines at the bottom of the processed netmail message. .. [0EA] RFC822 info to Netmail If the Alias UUCP Fidolist flag is active, it might be important to force MailGate to include in the processed netmail (converted from inbound UUCP mail), the netmail information from the ^AVIA fields. This will allow the Internet receipient to track the entire path of the netmail/email, using the Received: fields at the top of the processed email message. .. [0F0] Primary UUCP This node is responsible for the gateway between netmail and the UUCP manager, allowing users to send messages to the Internet. Mail to this node must follow the syntax described below: Netmail has to be send to the UUCP user. It has to be addressed to one of the UUCP gateway nodes. In the very first line of the message, the destination UUCP address has to come, following the TO: string. For example: From: Clovis Lacerda, (4:808/1) To: uucp, (4:808/2) Re: Testing ------ TO:clovis@ear.anpe.br This is a test. The TO: UUCP destination has to have to @ character, and can be written in the various formats commonly used in the UUCP world, such as: TO: "Clovis Lacerda" TO: clovis@ear.anpe.br (Clovis Lacerda) MailGate processes mail from users in two basic ways, according to how it was configured in the "Run-Time options" Menu. 1 - Any user may send mail to the Internet MailGate will first look for the originating user and node number in the UUCP VIP nodelist. If the user is found, his Internet address will be used in the UUCP message to be sent to the destination. Example of a netmail from a UUCP VIP user: From: John Brown, (4:808/1) To: uucp, (4:808/2) Re: hello --------- TO:clovis@ttbbs.ax.apc.org Hi Clovis, this is only a test. Please reply. MailGate will look for the user "John Brown", from 4:808/1 in the UUCP VIP nodelist, maintained in the UUCP Menu. The system will find this user and node under the UUCP address of john@ear.anpe.br. This way, the original netmail will be sent to the UUCP gateway as an email whose FSC-822 header looks like: From: "John Brown" To: clovis@ttbbs.ax.apc.org Reply-to: "John Brown" Subject: hello Organization: American School of Recife - Brazil X-Mailer: MailGate 0.21+ Hi Clovis, this is only a test. Please reply. In the second way of handling mail to the UUCP gateway, the system will check to see if the originating Node is listed in the nodelist. Assuming that John Brown is no longer a VIP user, but 4:808/1 is listed in the nodelist, and also that the UUCP VIP option is set to OFF in the "Run-Time options" Menu, this is what happens to his mail: From: "John Brown" To: clovis@ttbbs.ax.apc.org Reply-to: "John Brown" Subject: hello Organization: American School of Recife - Brazil X-Mailer: MailGate 0.21 Hi Clovis, this is only a test. Please reply. As can be seen, his node number was automatically inserted in his UUCP address. This is what happens to any mail coming from users not found in the UUCP VIP nodelist. As a matter of fact, any user or any sysop who sends netmail to the UUCP gateway from any node found in the nodelist is a valid user in the Internet world. If any mail comes from the Internet addressed to a user whose email address is FirstName.LastName%zone.net.node.point@ear.anpe.br MailGate will send mail as netmail to the user "First Name Last Name" in the zone:net/node.point system. This only happens if the UUCP VIP flag is set to OFF in the "Run-Time options", otherwise only users found in the UUCP VIP nodelist may user the UUCP gateway. The system may also be configured to allow any local user to have an account on the Internet, even if the UUCP VIP flag is ON and the user is not listed in the UUCP nodelist. Set the "UUCP Local VIP" flag ON and netmail to the UUCP gateway coming from a node listed in the Node Manager will be processed. The Internet address of the user will take the format: If the User Name is "Adriano Garcia", his account will be: adriano.garcia@ear.anpe.br Files may be easily sent uuencoded to Internet destinations. Just send the file attached to a netmail, addressed to the UUCP node, the UUCP user, as would be done with a normal message. The file will be uuencoded and sent to the destination. Mail with carbon copies is also accepted, and only UUCP VIP users will be able to send them. A message may contain normal carbon copies and/or blind carbon copies. In the first option, the RFC-822 message header of all destinations will contain the list of users who received carbon copies, while blind carbon copies will not. External alias files may be used to automatically import UUCP destinations. The following sample message illustrates how to send carbon copies: From: Clovis Lacerda, (4:808/1) To: uucp, (4:808/2) Re: Testing ------ TO:clovis@ear.anpe.br CC:bruno.santos@phoenix.uucp Bcc:jorge.eduardo@louca.uucp cc:alias Bcc:flavio.veras%12.282.0@rbt.anrs.br This is a test. As can be seen, normal cc: are mixed with Bcc and an external alias file is requested to be included in the process. MailGate will look for \MG\UUCP\ALIASES\ALIAS and, if found, will import all of the listed UUCP destinations and include in a normal cc: carbon copy. The header of a message to the UUCP gateway may contain as much as 8Kbytes of UUCP destinations in carbon copy. If files need to be sent to a UUCP destination via UUENCODE, simply create a netmail file attach, addressed to the UUCP gateway, and with subject line containing the full path/name of the file to be uuencoded. The "File" flag is issued in the netmail. In the body of the message, proceed as usual, writing the names of all UUCP destinations. .. [0F1] Secondary UUCP Same as Primary UUCP, but this time, applied to the Secondary network domain. .. [0F2] UUCP User The user to whom netmail to the UUCP gateway will be sent. MG comes with "UUCP" already pre-configured, but for any other reason, you may wish to modify it. .. [0F3] Username delimiter User names are normally separated by a dot ".". You may wish to use an underscore to separate the names. This way, a user may have one of the following email address: clovis.lacerda@ear.anpe.br or clovis_lacerda@ear.anpe.br .. [0F4] Gateway delimiter When non UUCP VIP users send netmail to the UUCP gateway, considering that the operation is allowed, MailGate will follow the UUCP syntax of the gateway to generate the corresponding FROM: and REPLY-TO: lines of the RFC-822 header. This delimiting character will only be used if the True Gateway is OFF. To separate the user name from the node number, MailGate needs a special character. This letter is used to indicate that mail is being processed by a non UUCP VIP user. Generally, this letter is %, but if you notice that your Host UUCP system is getting confused by this character, you may choose another one, for example, &. In this case, a user may have the following email: clovis.lacerda&f2.n808.z4@ear.anpe.br .. [0F5] UUE Lines When MailGate creates UUEncoded files to send to a UUCP destination user, the original file is encoded as multiple files. You may want to limit the size of each of these files, by supplying the maximum number of encoded lines to be sent in one message. If you want the entire file in a single message, enter 0 in this field. .. [0F6] Max RMAIL Users It is important to know if your Internet Host is capable of processing more than one user in a single command to RMAIL. This is useful if your system is providing local Lists, and, instead of sending one copy of the same message to all subscribed users, which would take a lot of disk space and time, MailGate can send as many users as the maximum number configured here, all of them in one single RMAIL command request. That is, one message would be directed to multiple recipients. This is also used for email to multiple users sent from carbon copied netmail to the UUCP gateway. .. [0F7] UUCP Nodelist ID used to identify the UUCP VIP database and other UUCP related files. This will only be important when your system runs multiple configs of MG and share (or not) the same UUCP files. .. [0F8] UUCP Cost The UUCP Cost manager of MailGate can keep track of individual VIP accounts. The MGTOOLS utility can send reports to the UUCP VIP users of the system, listing all mail that was sent and received, the names of sender and receiver, the date/time and the size of the messages. MailGate can supply the total cost for a certain period of time. Use this entry to supply the cost in $$ for every Kbyte of mail. MGTOOLS will calculate the total cost and display it in the Cost report. Individual UUCP VIP users may have different costs. You must change the configuration of such users, providing a different Cost Rate for their accounts. .. [0F9] Currency Currency that your system will use to send reports of UUCP Costs to VIP users. .. [0FA] Local VIP Flags If your system is configured to accept local users as UUCP VIP, use these flags to determine how mail should be handled, when UUCP mail is converted to netmail. HLD DIR CSH KIL ECH UUP OUT UAS BAD OFF HLD, DIR, CSH, KIL - Netmail flags for mail generated for this user, that can be confirmation receipts, converted UUCP mail, and so on. ECH This flag is a little hard to understand, and should only be set active if your system is going to exchange Fidonet files via uuencoded messages, in the automatic process that was explained in the UUE FilePath help. Having this flag ON, MailGate will look for file attaches in the netmail folder, originated from this user. After finding any, it will check if the destination of such netmail is configured in the UUCP Echo database. If so, the UUCP manager has the From: (this current user) and the To: (taken from the UUCP echo database) to successfully convert the file and send it to the destination as uuencoded messages. If the remote system is configured in exactly the opposite way, the file will be converted back to its original format and placed in the inbound files directory of the remote system, making it believe that the file was automagically sent via a Fidonet session. UUP This flag should only be used if the current entry is not allowed to send netmail messages to the UUCP gateway. This will only be evident if the current user has the ECH flag set to ON, and the original intention is to only have file attaches sent to the UUCP gateway. OUT This flag is useful if the user is "out of town", and wishes to warn users whom send him mail that he is out and will be reading his mail when he arrives. MG will automatically reply to his messages. Such message can be edited and configured in the Text Files Menu. This flag can only be set by the local postmaster. UAS This flag is very useful for the postmaster or any user with high level of access in your system. It allows the postmaster to send a message to the Internet AS if he were another user. This will help the postmaster unsubscribe unsolicited lists, etc. This is one example: From: Clovis Lacerda To : UUCP Re : unsub ------- as:john@ear.anpe.br to:listserv@templevm.bitnet unsub XXX-L This message, instead of leaving the system From:clovis@ear.anpe.br, it will actually be from:john@ear.anpe.br. BAD VIP users may have the destination of their email checked against a bad list of destinations, or they may have full privilege in the system, being able to send email to whoever they want. If this flag is ON, MG will check if the destination is in the bad UUCP list. If so, the process will be aborted and a warning message will be sent to the user. This message can be edited and configured in the Text Files Menu. OFF Disable the current entry. .. [0FB] Non VIP Flags These are the behavioral flags for users that are not local to your system nor UUCP VIP. HLD DIR CSH KIL ECH UUP OUT UAS BAD OFF HLD, DIR, CSH, KIL - Netmail flags for mail generated for this user, that can be confirmation receipts, converted UUCP mail, and so on. ECH This flag is a little hard to understand, and should only be set active if your system is going to exchange Fidonet files via uuencoded messages, in the automatic process that was explained in the UUE FilePath help. Having this flag ON, MailGate will look for file attaches in the netmail folder, originated from this user. After finding any, it will check if the destination of such netmail is configured in the UUCP Echo database. If so, the UUCP manager has the From: (this current user) and the To: (taken from the UUCP echo database) to successfully convert the file and send it to the destination as uuencoded messages. If the remote system is configured in exactly the opposite way, the file will be converted back to its original format and placed in the inbound files directory of the remote system, making it believe that the file was automagically sent via a Fidonet session. UUP This flag should only be used if the current entry is not allowed to send netmail messages to the UUCP gateway. This will only be evident if the current user has the ECH flag set to ON, and the original intention is to only have file attaches sent to the UUCP gateway. OUT This flag is useful if the user is "out of town", and wishes to warn users whom send him mail that he is out and will be reading his mail when he arrives. MG will automatically reply to his messages. Such message can be edited and configured in the Text Files Menu. This flag can only be set by the local postmaster. UAS This flag is very useful for the postmaster or any user with high level of access in your system. It allows the postmaster to send a message to the Internet AS if he were another user. This will help the postmaster unsubscribe unsolicited lists, etc. This is one example: From: Clovis Lacerda To : UUCP Re : unsub ------- as:john@ear.anpe.br to:listserv@templevm.bitnet unsub XXX-L This message, instead of leaving the system From:clovis@ear.anpe.br, it will actually be from:john@ear.anpe.br. BAD VIP users may have the destination of their email checked against a bad list of destinations, or they may have full privilege in the system, being able to send email to whoever they want. If this flag is ON, MG will check if the destination is in the bad UUCP list. If so, the process will be aborted and a warning message will be sent to the user. This message can be edited and configured in the Text Files Menu. OFF Disable the current entry. .. [0FC] RFC822 header The header of an email gives complete information about itself. For most purposes, however, a converted netmail should only contain the basic information about the original email, in this case, the original sender, the reply-to and the original date the email was written. This option will allow MG to import the complete RFC-822 header, only important information, or no information at all. .. [0FD] UUCP Bad users Edit the list of bad destination users to whom some users are not allowed to send mail. Netmail to the UUCP gateway addressed to one of these destinations will be aborted and a warning message will be sent back to the original user. .. [100] UUCP Node Name This is the UUCP Node that has been assigned to you. It identifies your system in the UUCP network. .. [101] Main UUCP Domain This is the main UUCP Domain that has been assigned to your system, besides the node name. .. [102] UUCP Domain Alias 1 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [103] UUCP Domain Alias 2 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [104] UUCP Domain Alias 3 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [105] UUCP Domain Alias 4 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [106] UUCP Domain Alias 5 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [107] UUCP Domain Alias 6 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [108] UUCP Domain Alias 7 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [109] UUCP Domain Alias 8 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [10A] UUCP Domain Alias 9 Your system may have up to 9 UUCP alias domains. Mail addressed to users at these domains are treated as local, and tossed into the system. .. [10B] Default Host This is the name of the main UUCP Host system with which your system exchanges mail to and from the Internet (probably your provider). It is similar to your UUCP node name, but in the domain of your Host. .. [10C] Organization This is the name of your organization, or BBS if you want. It is included in the ORGANIZATION: field of the RFC-822 header of all outbound UUCP messages from your system. If your copy of MailGate is not registered, the system will override this entry and include a warning that your copy is still not registered. .. [10D] Uucp Route This is the most important file in your system if you are going to manage an UUCP based network. It will contain the routing definitions that will indicate the systems and what will be routed through them. An example will make it easier to understand. Suppose your system is EAR and there are 10 other UUCP machines, exchanging mail with each other. Suppose these other 10 machines are: BBS1, BBS2, BBS3, BBS4, BBS5, BBS6, BBS7, BBS8, BBS9 and BBS10. Suppose also that EAR is the only link to the Internet, via a UUCP provider named BRONLINE. All machines agreed that they will route UUCP mail as follows: BBS1 to BBS4 exchange mail with EAR, which in turn forwards everything to the Internet via BRONLINE. BBS10 exchange mail with BBS1, BBS5 with BBS2, BBS6 to BBS9 exchange mail with BBS4. The UUCP route for EAR will be: ;-------- BBS1 BBS1 BBS10 BBS2 BBS2 BBS5 FIDONET.ORG BBS3 BBS3 Z4.FIDONET.ORG BBS4 BBS4 BBS6 BBS7 BBS8 BBS9 ;-------- Note that BRONLINE did not need to be included since it is the Default UUCP Host, as configured in MGSETUP. All other systems will include the main uplink (the closest link they have to BRONLINE) as their Default UUCP Host. Note that the UUCP route was simple to be configured, since any mail without any specific direction defined in the route is automatically forwarded to the Default Host. If a Host to the Internet is not available, and a closed UUCP network needs to be built, the UUCP route file needs to be complete, including all possibilities for UUCP routing throughout the entire net. Full domain systems can also be routed through one UUCP machine, for example BBS1 Z1.FIDONET.ORG LACOSA.COM RBT.COM This means that any system that has domains like f1.n100.z1.fidonet.org, f10n222.z1.fidonet.org, lacosa.com, ttbbs.rbt.com will be routed via the BBS1 machine. According to the example above, all mail to fidonet systems will be routed via BBS2, and all mail to Zone 4, Fidonet, will be route via BBS3. Please note the order in which the routes are entered, subsequent lines will override the previous ones, and even if the routing is determined, MailGate will go on checking the next lines. A special character is provided for UUCP re-routing. For example, if the first line is ALTERNATE * It means that all mail will be routed via ALTERNATE, instead of the Default UUCP host. Subsequent lines may change the routing scheme, and if * is used, it is mandatory to include all UUCP downlinks in the routing file, otherwise their mail will be routed via ALTERNATE. This overrides the old method that, by default, would route mail to UUCP downlinks via themselves, without the need of specifying them in the route file. The use of the * option is important if the main UUCP provider is down and mail should be delivered via another link. .. [110] A - Email The letter configured here will be used as the UUCP grade for all email messages generated in the system. Grades generally range from a to Z. .. [111] B - Lists The letter configured here will be used as the UUCP grade for all List messages generated in the system. Grades generally range from a to Z. .. [112] C - News The letter configured here will be used as the UUCP grade for all News batches generated in the system. Grades generally range from a to Z. .. [113] D - UUE The letter configured here will be used as the UUCP grade for all UUEncoded file messages generated in the system. Grades generally range from a to Z. .. [120] Listserver Commands This maximum number will allow you to control the number of requests that the Listserver receives from any user in a single message. Anyone wishing to hang up your system, could just send a large number of HELP or GET commands to the Listserver. This option allows you to control this situation. .. [121] Digest days If a local List is set as DIG (DIGEST), subscribed users will not receive broadcasted mail in the usual way. Instead, mail will be sent it DIGEST format, which means that, periodically, all accumulated mail will be sent at once. Use this option to define how frequent the DIGEST mail will be broadcasted to all subscribed users who have the DIG flag set to ON. .. [130] UUCP Node Name of UUCP machine that will be subscribed on your system. This machine will eventually exchange UUCP mail, newsgroups with your machine, and MG need information on how to treat mail sent and received from this node. .. [131] Postmaster Name of operator in the remote machine who is allowed to send requests to the UUCP areafix server. Also, UUCP cost for the current UUCP machine will be forwarded to the Postmaster. Use MGTOOLS NET for UUCP cost processing. .. [132] FidoNet Sysop If the UUCP machine is also on the Fidonet, supply his Fidonet name here. This will be used in case you configure the system to exchange UUCP mail using Fidonet technology. This feature will be explained in the Flags option. .. [133] Local Fido Node Local Fidonet node (if any) of your system, in case you will exchange UUCP mail via Fidonet file attaches with the remote Fidonet node. .. [134] Alternative Route This is the node of the Fidonet system that will receive the Fidonet file attaches (containing UUCP mail) from your system. .. [135] Inbound UUCP File If your system is going to exchange UUCP mail via Fidonet file attaches, you have to supply the file name that your system will RECEIVE from the remote Fidonet site. In the opposite way, the same name configured here must be configured in the remote site as the OUTBOUND UUCP file. An example will be given in the Flags option. .. [136] Outbound UUCP File If your system is going to exchange UUCP mail via Fidonet file attaches, you have to supply the file name that your system will SEND to the remote Fidonet site. In the opposite way, the same name configured here must be configured in the remote site as the INBOUND UUCP file. An example will be given in the Flags option. .. [137] AreaFix Pwd Password needed to access the areafix server for this node. This password must be sent in the subject line of the requesting netmail. .. [138] Fido ZIP Password Password that will protect the compressed file attach, containing the UUCP mail being exchanged with the remote UUCP/Fidonet site. This entry is optional, and will only work with ZIP, ARC and ARJ files. .. [139] Compressor Type of compression technique used to compress and decompress Newsgroups. .. [13A] File compressor Type of compression technique used to compress and decompress the UUCP mail that will be exchanged with the remote site via Fidonet file attaches. .. [13B] Flags These flags define the operational behavior of the current UUCP system. HLD DIR CSH KIL AFX BAT CUN STR ZIP GTW OUT BNK BAG CNV LOK OFF HLD, DIR, CSH, KIL - define the netmail status for the file attach that will eventually be created for UUCP exchange of mail via Fidonet. Note that the file attach will have the "Del file after sent" flag forced active, avoiding duplication of mail. FIX Postmaster is allowed to use the areafix server via email BAT If ON, Newsgroups will be sent to the remote system in batch format. CUN If you are using a news compression program that cannot add the "#! cunbatch\n" header in outbound compressed news, set this to ON to force MailGate to add the header before the news compressed file is sent to the spool directory. STR If you are using a news decompression program that does not handle inbound news with the "#! cunbatch\n" header, set this to ON to force MailGate to remove the header before the decompression program can be able to execute its function. ZIP If this flag is ON, MailGate will scan the UUCP Spool directory, compress outbound or inbound directory and file attach to the Fidonet node, configured in the Alternative Route. If the two systems are going to exchange mail in the traditional UUCP fashion, leave this flag OFF. GTW This flag will define the behavior of the UUCP-to-Fidonet type of transition. This flag is only active if ZIP is ON. An example will be given after the last flag is commented out. OUT Indicates that MG must compress UUCP OUTBOUND mail, compress and file attach to the Alternative Route (Fidonet node). This flag will only work if ZIP is ON. If OUT is OFF, MG will only compress and file attach INBOUND UUCP mail. BNK If ON, MG will generate the Fido file attach using Binkley convention. If OFF, MG will issue a netmail file attach, compatible with Front-Door. This flag will only be active if ZIP is ON. BAG If ON, besides looking for normal UUCP mail in the link's spool directory, MailGate will also look for compressed or uncompressed *.* files in the subdirectory BAG\, inside the link's spool directory. For example, if the main spool directory is \MG\SPOOL, and the UUCP link is TTBBS, MG will look for UUCP inbound mail in \MG\SPOOL\TTBBS\BAG\. This is particularly useful if your system is receive-only, and receives UUCP mail (normally batched news) from a satellite provider. MG also recognizes and processes private email, embedded in the batched news. These email messages come with a header like #! rmail 1234 clovis@er.anpe.br which is different when compared with the normal #! rnews 1234 header, where in this example, 1234 is the size in bytes of the entire message. The address right after the message size is the destination of the email. CNV Be careful when using this flag, which will rarely occur. If this UUCP system is actually LOCAL to your computer or LAN, in other words, if the UUCP machine does not pick up mail using UUCICO, but rather, have direct access to the spool directory via a LAN, for example, set this flag to ON. This will force MG to switch the naming convention of outbound and inbound mail. For example, if a message is generated to this UUCP node, instead of being named as *.XQT, *.CMT and *.DAT (outbound mail), the files will be named as it they were inbound mail, (*.D and *.X). This will make them ready for the UUCP node to accept them as inbound mail. When the UUCP node exports mail for delivery, your local system will understand the *.XQT, *.DAT, *.CMD files generated by the UUCP node as if they were inbound mail to be imported. MG will only recognize this CNV flag if the appropriate Run-time flag is also set to ON. LOK Lock tossing. Some providers forward mail from other systems. This means that inbound UUCP mail in the spool directory are not always generated by the provider. If this happens, set LOK to OFF to force MailGate to bypass the validation of the sender of the mail and process any inbound packet in the spool directories. If LOK is ON, MG will check the U command in the *.X control file and validate it only if it matches the UUCP machine of the link. OFF Temporarily disable the current entry from the system. /// /// /// Applications for some of these flags /// /// /// Please, pay attention to the following explanation, if you are going to use Fidonet to transport pure UUCP mail between UUCP sites. If this is not your case, skip to the next section. One of the drawbacks of UUCP is that it is an old protocol, inefficient in some ways, mail is mostly exchanged uncompressed, news compression is not efficient, and all of this is a synonym of longer transfer rates, more sensitive connections to noisy phone lines, etc. If the systems exchanging UUCP mail are also on the Fidonet, they can take advantage of this fact and exchange their UUCP mail using a Fidonet Front-end mailer. It is important to note that the UUCP mail will not be touched, altered, or whatever, Fidonet will only be used to transport the mail, and that is all. There are basically two distinct ways of using Fido to transport UUCP mail, and they will be explained by means of two examples. Situation number 1: The two systems are independent, meaning that one is not a subdomain of the other. Suppose these two UUCP machines exchange UUCP mail with an Internet provider, located in Santa Rosa, USA. BRONLINE (BRONLINE.COM) and LACOSA (LACOSA.COM). The problem is that BRONLINE, being located in Recife, Brazil, will have to make a long distance phone call to the USA to pick up its mail via UUCP, with the Internet provider. On the other side, LACOSA is in Santa Rosa, USA, which means that the UUCP provider is local. BRONLINE decided it would be much more efficient if it could get its UUCP mail using Fido to transport it, which would make the international phone calls much more efficient and less costly. Unfortunately, the UUCP provider does not support such alternative way of supplying UUCP mail. So here comes LACOSA.COM. BRONLINE and LACOSA make a deal that says the following: LACOSA would create a configuration in its local system, just to play BRONLINE with the UUCP provider. In other words, it will be the postmaster in LACOSA, not BRONLINE, that will pick up the UUCP mail with the provider, for the BRONLINE system. Doing so, it is obvious that the UUCP mail will be stored in the hard-disk of LACOSA (playing BRONLINE), and needs a way to reach BRONLINE in Brazil. The two systems will use Fidonet to transport such UUCP mail, via file attaches that contain the whole UUCP mail in compressed format. Going on with the suppositions, assume that LACOSA is Fidonet node 1:125/3150 and BRONLINE is 4:808/2. When BRONLINE generates mail to be sent to the provider, it needs a way to also compress this mail, file attach it and send over to LACOSA (1:125/3150) via Fidonet session. This is what 1:125/3150 must do: 1 - Set up an entire sub-system, just to play BRONLINE over there. 2 - Exchange UUCP mail with the provider, as if it were BRONLINE. 3 - Compress INBOUND UUCP mail (received from the provider) and file attach to the Fidonet node that belongs to BRONLINE, 4:808/2. 4 - Set to ON the following flags: ZIP 5 - Set to OFF the following flags: GTW OUT The GTW flag will only be used in the second example. The OUT flag, being disabled, indicates to the configuration of MG at 1:125/3150 that it will only compress INBOUND mail (received from the provider), compress it and file attach to the Fidonet node that belongs to BRONLINE, 4:808/2. 6 - The OUTBOUND file configured at 1:125/3150 is BROUT, and the INBOUND file configured at 1:125/3150 is BRIN. BRONLINE (4:808/2), must set up a similar configuration. This is what it will do, to be in synchronization with what 1:125/3150 did on its side: 1 - Set up, as normal, its BRONLINE configuration. 2 - Set to ON the following flags: ZIP OUT The OUT flag, in this case, indicates that MG, at 4:808/2, must compress and file attach to 1:125/3150, only OUTBOUND UUCP mail (the messages that should be sent out to the provider). 3 - Set to OFF the flag: GTW 4 - The OUTBOUND file configured at 4:808/2 is BRIN and the INBOUND file configured at 4:808/2 is BROUT (note that they must be reversed in the two configurations, at 4:808/2 and 1:125/3150). Finally, this is what will take place: 1:125/3150, playing BRONLINE in California, will exchange UUCP mail with the provider, as if it were BRONLINE. Outbound mail is normally sent to the provider, but received (inbound) mail, must be sent to the true BRONLINE system in Brazil, as if it had actually made the UUCP connection with the provider. The configuration of MG at 1:125/3150 will detect inbound UUCP mail in the spool directory of BRONLINE (*.X and *.D files). These files will be compressed as file BROUT, file attached From: 1:125/3150 To: 4:808/2 and finally deleted from the spool directory. 4:808/2 will, in turn, check if its local spool directory (BRONLINE) has OUTBOUND mail to be sent over to the provider (*.XQT, *.CMD and *.DAT files). If found, these files will be compressed in the BRIN file, file attached To: 1:125/3150 From:4:808/2, and then deleted. 1:125/3150 and 4:808/2 execute a Fidonet mailing session. File BROUT.ZIP (or whatever compression was chosen) is sent From:1:125/3150 To:4:808/2, and file BRIN.ZIP is sent From:4:808/2 To:1:125/3150. After receiving BRIN.ZIP, 1:125/3150 will execute MG.EXE. Mailgate will detect the BRIN.* file, check the configuration and determine that this file must be uncompressed and the result should be sent to the Spool directory of BRONLINE (remember, 1:125/3150 is playing BRONLINE in the USA). Since the files inside BRIN.* are UUCP OUTBOUND files, they will be ready to be sent over to the UUCP provider AS IF it had been the system in Brazil that made the UUCP connection! In the other hand, 4:808/2, after receiving BROUT.* from the USA, will run MG.EXE. MailGate will detect this file, and according to the configuration, it should be uncompressed and the result files moved to the spool directory of BRONLINE (the real one in Brazil). Since the result files are UUCP INBOUND mail (*.X, *.D), the whole process is over, and it will look like BRONLINE had exchanged UUCP mail with the provider in the USA, but this was not the case. Now, to the second example. This is the basic distinction between the following situation and the one just described above. In situation 1, the two systems never exchanged UUCP mail, but just used Fido to transport mail for one system, having the other as a bridge. In the following situation, the two systems exchange UUCP mail but they decide to use Fido as the transportation media. This is mostly like to occur with a system and one of its downlinks. Suppose LACOSA.COM has one system connected to it, say, BRONLINE.LACOSA.COM. LACOSA exchanges UUCP mail with the provider, and BRONLINE gets its mail from LACOSA. Having a node under its own domain, the configuration at LACOSA will work with a second subdirectory in the spool main directory, where mail to/from BRONLINE is processed. BRONLINE will get the mail stored in this subdirectory using the UUCICO program and UUCP protocol. When BRONLINE and LACOSA exchange mail using the UUCP protocol, this is what happens: Outbound mail at BRONLINE will be sent to LACOSA. During the transmission, a command file (*.CMD) at BRONLINE will make the Data (*.DAT) and the control (*.XQT) files be stored at LACOSA as *.D and *.X respectively. LACOSA will process this mail and eventually forward it to other systems, toss to its own message base, or whatever. What is important to consider is that outbound mail (*.DAT, *.CMD and *.XQT) become two files in the other end of the connection, *.D and *.X, no matter if mail is sent or received from/to LACOSA and BRONLINE. But LACOSA and BRONLINE decide they will exchange UUCP mail using Fidonet. What LACOSA and BRONLINE have to do is exactly what they did in the first example, with the only detail that they must ACTIVATE the GTW flag. This flag means "gateway", and instructs MailGate in both ends to promote the gateway of the UUCP mail (*.XQT, *.CMD and *.DAT become *.D and *.X), before compressing and file attaching these UUCP files. They must, also, have the OUT flag ACTIVE in both sides, since the two systems will only convert and exchange UUCP outbound mail. .. [13C] UUCICO Mailer Type of UUCICO program in use between your system and this UUCP node. We welcome you to send us your suggestions and sample files, if you need MG to support different formats. Make sure the files may be shared before sending. .. [140] UUCP Map Domain MAPS are only used if your system manages mail to/from UUCP machines and these machines are Fidonet systems. Inbound mail is automatically converted to Fido (netmail), and inbound netmail is converted to UUCP before being sent out. If the UUCP links connected to your system will receive pure UUCP mail, do not configure them in the MAP database. This entry is the subdomain for the Fidonet system. Use short words to clearly identify the name of the system. MailGate, as explained in other sections of this manual, has different ways to send and receive mail to/from the Internet. One of them works with the help of the UUCP Map. One BBS system may be assigned one UUCP subdomain, and all users from that BBS can send and receive mail. The UUCP Subdomain will identify the name of the system and route the mail to and from the right node number. For example, if the UUCP Subdomain is "spinner", any user from 12:2820/1 will have an account on the Internet in the form: firstname.lastname%spinner@ttbbs.ax.apc.org firstname and lastname are taken from the netmail that came from 12:2820/1. "spinner" is the corresponding UUCP Subdomain for 12:2820/1 and ttbbs.ax.apc.org is the local UUCP domain. In the other way, mail arriving from the Internet addressed to flavio.veras%spinner@ttbbs.ax.apc.org will be sent to Flavio Veras, 12:2820/1. .. [141] FidoNet Node This is the node of the BBS system that can route mail to and from the Internet under the subdomain assigned to it. .. [142] Description This field is used for purposes of documentation only, it is not used for any special function in the system. Use it to highlight details of this configuration. .. [143] FlaGs These flags define the operational behavior of the current UUCP MAP system. HLD DIR CSH KIL OFF BAD HLD DIR CSH KIL - Flag status for netmail generated to users at this node OFF - Temporarily disables the current MAP entry BAD - mail from users will be checked against bad UUCP destinations in \mg\uucp\mgubad*.lst. * is the UUCP ID configured previously. .. [150] UUCP User Name of the Internet account of this VIP UUCP user. Enter the complete name, for example, clovis@ear.anpe.br. If the domain of this user is the local UUCP domain, entering only the user name will force MG to append the local domain. .. [151] FidoNet Node Node number from which the user will send and receive his UUCP mail. This is one of the advantages of MailGate. Any user through the network can use the UUCP Gateway and have the privileges of a VIP UUCP user. .. [152] User Name Name of the user who is using this account. This is the name that comes in the name field of the netmail. .. [153] User ID This field is available for purposes of your control only. You may wish to separate different users and identify them with different letters, for example, one letter for the users of one particular BBS. MGTOOLS uses this field to create List reports. Please refer to the "MGTOOLS" help. .. [154] Info 1 General information about this UUCP VIP user, such as mailing address, when he became a member of your system, when his subscription expires, etc. .. [155] Info 2 General information about this UUCP VIP user, such as mailing address, when he became a member of your system, when his subscription expires, etc. .. [156] UUCP Cost Rate Use this entry to change the UUCP Cost for this VIP user, in relation to the UUCP Cost configured in the UUCP Menu. For example: If the UUCP Cost of every Kbyte of mail is 2 dollars and the Cost Rate is 0.5, the cost of Kbyte for this user will be 2 x 0.5 = 1. .. [157] FlaGs Special flags that define the behavior of this UUCP VIP user and his account. You may define the status of the netmail that will be sent to him, and the current status of his UUCP configuration. HLD DIR CSH KIL ECH UUP OUT UAS BAD OFF HLD, DIR, CSH, KIL - Netmail flags for mail generated for this user, that can be confirmation receipts, converted UUCP mail, and so on. ECH This flag is a little hard to understand, and should only be set active if your system is going to exchange Fidonet files via uuencoded messages, in the automatic process that was explained in the UUE FilePath help. Having this flag ON, MailGate will look for file attaches in the netmail folder, originated from this user. After finding any, it will check if the destination of such netmail is configured in the UUCP Echo database. If so, the UUCP manager has the From: (this current user) and the To: (taken from the UUCP echo database) to successfully convert the file and send it to the destination as uuencoded messages. If the remote system is configured in exactly the opposite way, the file will be converted back to its original format and placed in the inbound files directory of the remote system, making it believe that the file was automagically sent via a Fidonet session. UUP This flag should only be used if the current entry is not allowed to send netmail messages to the UUCP gateway. This will only be evident if the current user has the ECH flag set to ON, and the original intention is to only have file attaches sent to the UUCP gateway. OUT This flag is useful if the user is "out of town", and wishes to warn users whom send him mail that he is out and will be reading his mail when he arrives. MG will automatically reply to his messages. Such message can be edited and configured in the Text Files Menu. This flag can only be set by the local postmaster. UAS This flag is very useful for the postmaster or any user with high level of access in your system. It allows the postmaster to send a message to the Internet AS if he were another user. This will help the postmaster unsubscribe unsolicited lists, etc. This is one example: From: Clovis Lacerda To : UUCP Re : unsub ------- as:john@ear.anpe.br to:listserv@templevm.bitnet unsub XXX-L This message, instead of leaving the system From:clovis@ear.anpe.br, it will actually be from:john@ear.anpe.br. BAD VIP users may have the destination of their email checked against a bad list of destinations, or they may have full privilege in the system, being able to send email to whoever they want. If this flag is ON, MG will check if the destination is in the bad UUCP list. If so, the process will be aborted and a warning message will be sent to the user. This message can be edited and configured in the Text Files Menu. OFF Disable the current entry. .. [160] UUCP User This is the complete UUCP account of the echomail user who receives file bundles from your system automatically. Please refer to the "UUE FilePath" help. .. [161] FidoNet Node Fidonet node of the user whose file attach will be sent through the UUCP gateway. Any file attach addressed to this node and to the Echo Username will be sent to the Echomail UUCP user, considering that the addresser of the file attach is a UUCP VIP user who has the ECH flag option set to ON in his configuration. Please refer to the "UUE FilePath" help. .. [162] User Name This is the name of the user whose file attaches addressed to him will be processed by the Fileserver and sent to his UUCP account, as configured in the EchoMail UUCP user. For details, please refer to the "UUE FilePath" help. .. [163] FlaGs Operating flags that define the behavior of this Echo UUCP user. No options area available in this current version of MailGate. .. [170] Listserver Name of listserver user that will receive requests from users to join the local lists of your system. .. [171] Uucp AreaFix Name of areafix user that will receive requests from the postmasters of UUCP downlinks, connected to Newsgroups. The complete set of commands available for the UUCP areafix system is available in the text file that can be edited in the Text Files Menu. .. [172] UUCP 1 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [173] UUCP 2 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [174] UUCP 3 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [175] UUCP 4 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [176] UUCP 5 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [177] UUCP 6 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [178] UUCP 7 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [179] UUCP 8 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [17A] UUCP 9 Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [17B] UUCP A Besides the two specific Listserv and Areafix users, MG can handle up to 10 other general purpose special users. Whenever mail comes to one of these users, MG will simply forward the message and store it in the UUCP main directory. For example, if this special user is CONVERT, mail to convert@ear.anpe.br will be stored as text file in \MG\UUCP\CONVERT. This will allow other programs to take over and process these files accordingly. .. [180] Run-Time Options Several flags are provided for the system to operate according to your specific needs. They are used to enable or disable almost all functions of MailGate. Once configured, they are used as default settings for the operation of MailGate. They can, however, be overridden by the DOS command line. Run MailGate using one or more switches as explained in the ON-LINE Help. If you run MG -? you will get the list of switches. .. [181] Directories These directories are needed for MailGate to work properly. If not correctly configured, MailGate will abort and send a warning message. Some of these directories must match with those specified in the other BBS programs you run, since MailGate will read and write mail and information to them. The names are suggestive and the pre-configured directories will give you no doubt about what they are for. If you do not provide the drive name, MailGate can operate throughout a network based system. Note that a SET statement should be provided in your AUTOEXEC.BAT to help MailGate locate the main configuration directory. Use SET MG=C:\MG if this is the directory where you configured MailGate and MG.CFG. Add in the PATH line where the EXE files are and MailGate can run from any directory. MailGate will first look for MG.CFG in the current path, then in the SET command. In this manner, you can have as many different configurations as you want, and different configurations may share the same directories. .. [182] Default AREA config This menu gives access to the general configuration options of your TIC manager, related to new TIC areas that will eventually be created in the system. New areas will take their default configuration from here. .. [183] TIC Area Manager This Menu will give you access to the configuration of each individual TIC Area and its uplink/downlink nodes. .. [184] Node Manager Configuration of Fidonet systems that exchange echomail with your BBS. This will only be available in future releases of MailGate, when there will be an internal echomail tosser. .. [185] TIC Groups MG has 26 different groups that can be used to organize the different TIC file areas, according to particular needs. In this menu you will configure their descriptions. .. [186] RAID Alias Users that will receive requests by netmail and activate the RAID server. This server allows remote TIC nodes to update their configuration, activate, disable TIC areas. You may set up more than one destination in case you need to make sure MG will accept requests from systems that use different TIC managers. .. [187] FileFix Config If the EXT flag is set to ON in the "General Flags" option of a TIC file Area, MailGate will look for text files in \MG\TIC\FILEFIX, compatible with FILES.BBS, during a FileFix operation. Normally, TIC Areas that have the FIX flag ON will be scanned during an echomail FileFix request. In addition, MailGate can also look for the requested files in extra FILES.BBS files, most probably files that your system has available for other BBS systems, or off-line file lists that are not regularly maintained in your system. You may create an extra TIC Area, using the \MG\TIC\FILEFIX subdirectory to store the file lists that other BBSs send to your system. They would be available during the FileFix operation. Note, however, that, depending on the number of such files and their sizes, the FileFix function may take a long time to be completed. .. [188] Add banner Configuration of archive utilities that will add banner files to TIC files in distribution, if this process is active for the particular TIC area. .. [189] Convert archive Configuration of archive utilities that will convert one compression technique into another, for TIC files in distribution, if this process is active for the particular TIC area. .. [18A] HATCH files This Menu will allow you to hatch files from a TIC Area to the TIC nodes that are members of the Area. Please note that the file will not be automatically hatched by MGSETUP. A TOK file will be created in the TIC directory, and only when MG.EXE runs, it will be processed, and the file distributed. .. [18B] Globals You may add or remove downlink nodes from a set of TIC Areas that are in one specific TIC group. .. [18C] Import TICK210.CFG If you are using TICK 2.10 or compatible, you may avoid having to configure everything again by importing the already existing configuration. Please not that the process is not complete due to differences between the two programs. MG will import all TIC areas and connected links, as well as their particular flags in each area. MG will also import the Main TIC node, but MG will not change the configuration of inbound and outbound directories. This will be left for you to decide how your configuration of MG will be organized in this manner. MG will not import the configuration of each TIC node (flags and password), something that still needs to be done in the TIC Node Manager of MG. Check the result configuration to make the final adjustments. .. [190] Proc TIC If ON, MG will process the TIC functions during run-time. .. [191] TIC New Files If ON, MG will look for TIC areas that allow the system to search for new files, and if found, be distributed to its TIC links. Areas that have the SCN flag activated fall in this category. This is useful if you want to have some of your BBS directories scanned by MG and any new files automatically hatched in the corresponding TIC area. .. [192] TIC DIFF If ON, MG will look for TIC areas that have the DIF flag activated. These TIC areas are those that contain release files, like NODELIST and NODEDIFF. After finding new files, MG will compress them, append the corresponding numerical file extension, and distribute to the TIC downlinks. If you maintain the nodelist of your network using the MAKENL program, this option is useful for automatic delivery of new weekly releases of both files. TIC Areas must have the DIF flag set to ON if they are going to be scanned for DIF files. .. [1A0] TIC Directory The TIC main configuration file and the TIC Areas database files are stored in this directory. Two subdirectories are automatically managed by MailGate, one, the HOLD directory, stores the TIC control files (*.TIC) that are file attached as netmail to your downlinks. The DUP subdirectory contains the *.DUP files for each TIC area control, to avoid the flow of duplicated files. TIC operation is the process of sending files automatically between many BBS systems, without the intervention of the sysop. It works in a way similar to echomail messages. Once a file is sent for distribution (HATCH), the various TIC managers along the net will forward the file to the desired downlink systems, according to the way these systems are configured. Besides processing TIC files between Fidonet systems, MailGate and its Listserver manager in the UUCP system can handle distribution of files to Internet users, provided they are properly set in any of the local Lists of the system. Please refer to the HELP of the "UUCP Config" for details. .. [1A1] File base Path Directory where the file base, compatible with Remote Access 2.00, is maintained. MG needs to know where to find the RA file base if one or more TIC areas are connected to this file base. .. [1B0] TIC Main Node Default Node used as the Main TIC Node for new areas created in the system. This is the node that identifies your system to your downlinks and uplinks when exchanging TIC files in distribution. .. [1B1] Echo Node Default Echomail Node for new TIC areas in the system. MailGate uses this node to send echomail reports after inbound TIC files are processed. MailGate generates echomail from this node directed to the TIC Node. Warning: This node cannot be listed in the configuration of your echomail utility as a LOCAL node. Rather, it must be considered as a "remote" node, from which your system is receiving echomail. As such, it has to be known by the Node Manager of your echomail utility, and listed in the export list section of the Echomail Areas that are in gateway between the two domains. In the node configuration of your Front-end mailer, however, you can configure it as an AKA node, so that mail will not leave the netmail folder. It must also have the "Active" option in the node manager set ON (or any equivalent option). The "Active" option disables the node from receiving echomail. It will only generate echomail, which is the situation here. .. [1B2] Default ECHO This is the default Echomail Area used for automatic notifications in echomail when TIC files are processed by the system. It is used whenever a new TIC area is created by the sysop or when uplinks send new TIC files in distribution and are allowed to automatically create the new TIC Areas in your system. .. [1B3] Files.BBS TAB This is the number of spaces used to separate the file name from its description in the FILES.BBS text file. This option will not be used if the TIC file Area is configured to use the Remote Access file base, which can be done by setting the RAF flag to ON. .. [1B4] Virus Program Name of your virus utility that MailGate will use to scan the TIC files processed in the system against the present of virus. If any file is found to be infected by a virus, MailGate will not distribute it. You will only enter the name of the executable or batch file. It must be either in the current directory or in the PATH of your operating system. .. [1B5] Virus Command This is the command line passed to the Virus Scan program during its execution. .. [1B6] Errorlevel Your Virus utility must exit with an errorlevel, indicating that a virus was found during scanning. This errorlevel, that indicates the presence of virus must be configured here, otherwise MailGate will not know what your Virus program detected during execution. .. [1B7] DIF Compressor Please choose one of the available compression techniques to be used during the transmission of DIFF release files for certain TIC Areas that have the DIF flag set to ON in their configuration. .. [1B8] DIF Character During the compression of DIFF releases, MailGate uses this letter to create the extension name of the compressed file. For example, if you choose "A", and MailGate detects the file NODEDIFF.007, the compressed file will be NODEDIFF.A07. The compression program is selected in the "DIF Compressor" option of this Menu. .. [1B9] Alias File This is the ASCII file that is updated whenever MailGate processes a MAGIC file in distribution in your system. This file is generally used by most Front-End mailers as an easy way to provide Files for file-request, when the calling system requests a file by its MAGIC name. .. [1BA] Areas Flag 1 Each time a node is added in one of the TIC Areas of the system, MailGate will use these flags as their defaults. Flags from HLD to RCV define default settings for new nodes. The other flags define how the TIC Area will process the files. HLD=Hold, DIR=Direct, CSH=Crash, KIL=Kill. Default flags for TIC netmail. SND - Remote system may send files for distribution. RCV - Remote system can receive files. DUP - If ON, only files not found in the system will be distributed CRC - The system will check the 32 bit CRC of inbound/outbound TIC files. AUT - Allows privileged systems to subscribe on this TIC Area. VIR - The system will only process TIC files after a virus scan is done. RES - Resets the date/time of an inbound TIC file. DIF - Scans Area for new DIFF(numbered) releases SCN - Scans this Area in search of new files. TIC new files. FIX - FileFix searches are allowed in this Area. MAG - OFF for TIC file Areas and ON for MAGIC file Areas EXC - If ON, the file will be distributed only to the MAGIC nodes RAF - This file area is located in the Remote Access file database. The system will process the file database and ignore FILES.BBS. EXT - External FILES.BBS compatible files, located in TIC\FILEFIX, will be scanned during the FileFix function. If a message area is configured to accept requests to the FileFix server, this is how things will work: FileFix is a function used for searching files for in the system. The requests may be sent by any person from Echomail areas. It will look for messages sent to the FileFix user. In the subject line, the user must have written a list of files or descriptions to be searched in some of the TIC file directories of the system. These directories must be the ones used by your TIC areas, and the FileFix function must be enabled in the Flags settings of these areas for FileFix to work. The file names and descriptions are issued in the subject line of the message. Wildcards are valid. If the user wishes a search based on the description, or part of the description of the file, it will have to come between "". Multiple files are accepted, as well as file names and descriptions in the same message subject. Suppose that FINDFILE-RBT is an echomail area with the FIX flag set to ON. Assume that there are 4 TIC Areas in your system whose flags have the FIX option set to ON, allowing FileFix requests. The following example illustrates a valid message that will be processed by the system, and the result will be forwarded to the same echomail area. From: Clovis Lacerda To: FileFix Re: mg*.* "MailGate" "utility" ra*.* This message will be processed by MailGate, and the system will search all of the directories of the TIC Areas that have the FIX flag ON. It will look for files that match the mg*.* and ra*.* pattern, and also look for files that have the string "utility" in their descriptions. Only files that are listed in the FILES.BBS file will be recognized. The FileFix function is similar to the Archie server found in many Internet sites. It is very powerful and allows users to look for BBS systems that have some specific files in their directories. One single query in the echomail conference will activate FileFix search in all of the systems that have MailGate operating. During the FileFix operation, external FileFix files for other BBS may be searched for the requested files, and also, depending on the configuration of the FileFix manager, MG will send netmail requests to the MGSERVER user at some of these node numbers, which means that the local configuration of MG is passing on a request to other nodes. .. [1BB] Areas Flag 2 Each time a node is added in one of the TIC Areas of the system, MailGate will use these flags as their defaults. RA ON, this is a RA internal FileBase area SOP ON, send tic report to sysop instead of echomail PST ON Pass-through area. Do not hatch file to the local BBS system ARC ON Convert inbound files to a new compressor BAN ON Include banner in the file archive .. [1BC] FileFix Text In the echomail TIC reports, MailGate may append a default text file to the message. The text file is "TAGLINE.TIC" and should be located in \MG\TIC ("TIC Path"). If you want to have specific text files to be included in the echomail reports, check the same option as this one in the "TIC Area Manager". .. [1BD] TIC Banner Text file used as the banner that will be included in the compressed files in TIC distribution. It will only be included if the TIC area has the BAN flag set to ON. .. [1C0] Alias 1 Optional alias name for the RAID server. .. [1C1] Alias 2 Optional alias name for the RAID server. .. [1C2] Alias 3 Optional alias name for the RAID server. .. [1C3] Alias 4 Optional alias name for the RAID server. .. [1C4] Alias 5 Optional alias name for the RAID server. .. [1C5] Alias 6 Optional alias name for the RAID server. .. [1C6] Alias 7 Optional alias name for the RAID server. .. [1C7] Alias 8 Optional alias name for the RAID server. .. [1D0] AreaName For each TIC area there must be a unique name that identifies it. Try to use names that are suggestive to the type of files that will be distributed under this name. For example, your system might have a TIC Area named NODEDIFF for distribution of Nodediff files, another area named VIRUS for programs related to protection and detection of viruses, and so on. Each TIC Area may have a special DOS batch file. This batch file should be named with the same name of the TIC area, with extension .BAT. If MailGate detects the presence of this file when processing inbound TIC files for this TIC Area, it will execute the batch file, passing the file name as the DOS parameter. The batch file must be located in the TIC Directory. For example: TIC Area: MAILGATE DOS batch file: MAILGATE.BAT contents: pkunzip %1 \temp .. [1D1] Description Provide a description for this TIC Area. For example, for the NODEDIFF TIC Area, it may have a description such as "update and information of the nodelist". .. [1D2] Area Path This is where the files distributed from the TIC Area are located, and whose file list is maintained in the FILES.BBS text file, or whatever file you configured for this purpose. .. [1D3] RA Area Index If the RAF flag is set to ON, indicating that this TIC area operates with the Remote Access file database, you must supply the file index area that corresponds to the file area in question. Just check the number in the configuration of RA. The RAF flag and a number different than 0, in this field, are the only two things needed for MG to interface with the RA file base. .. [1D4] TIC Main Node Main node number of this TIC area. Netmail file attaches and echomail will be generated from this node. This node number will be the one used by your system to send files in distribution for your downlinks, and also to check for inbound TIC files for validation of your system as the true receipt of the incoming file. Since each TIC Area may have its own TIC node, MailGate can easily manage each TIC Area independently and provide you with flexibility to manage TIC processing from different networks. .. [1D5] Echo Node Echomail node used in the process of creating PKT mail for later processing by the echomail tosser. This node cannot be local to your system, and at the same time, must be one of the downlinks configured in the area manager of your echomail utility. Echomail TIC report will be sent From:Echo Node, To: Main Node. .. [1D6] FILES.BBS MailGate defaults to FILES.BBS as the text file that contains the updated list of all files and their descriptions. If your system works with a different kind of file, you may enter in this option the full path and name of such file. This may also be used if your system has a CD-ROM and has to keep its FILES.BBS files in different directories in your hard disk. If the RAF flag is ON, it means that this File Area is located in the Remote Access file database, which means that this entry will not have any effect. .. [1D7] File Desc This is useful when new TIC Areas are created by the system, which is something that occurs when some of your uplinks send TIC files originated from unknown areas to your system. If this happens, it is obvious that the system does not have the description of the TIC Area in question, for which you may supply a general statement that will be temporarily used for the created TIC Areas. .. [1D8] Echo Area If this entry is not blank, MailGate will send a report of the inbound files that are processed and later distributed by the system to this echomail area, as well as the operations that were executed on it and general information about your system. The originating node of the Echomail message will be the "Echo Node" and the destination node will be the "Tic Node". MailGate produces echomail packets as if they had arrived in your system through a remote uplink, and this is the purpose of the "Echo Node". It should not be one of your local nodes, but rather, a point not considered local in the configuration of your echomail utility, otherwise it may not toss the packets created by the Tic Manager. .. [1D9] Compressor Choose the compressor type to which incoming files will be converted. This will only happen if the Automatic file conversion is active, via the ARC flag set to ON. .. [1DA] TIC Group TIC Groups that are available for this System. The downlink system will only be allowed to activate the TIC areas that are members of the TIC groups listed here. Otherwise, the downlink system will only access these TIC Areas if you activate them manually. .. [1DB] Flags 1 Flags from HLD to RCV define default settings for new nodes. The other flags define how the TIC Area will process the files. HLD=Hold, DIR=Direct, CSH=Crash, KIL=Kill. Default flags for TIC netmail. SND - Remote system may send files for distribution. RCV - Remote system can receive files. DUP - If ON, only files not found in the system will be distributed CRC - The system will check the 32 bit CRC of inbound/outbound TIC files. AUT - Allows privileged systems to subscribe on this TIC Area. VIR - The system will only process TIC files after a virus scan is done. RES - Resets the date/time of an inbound TIC file. DIF - Scans Area for new DIFF(numbered) releases SCN - Scans this Area in search of new files. TIC new files. FIX - FileFix searches are allowed in this Area. MAG - OFF for TIC file Areas and ON for MAGIC file Areas EXC - If ON, the file will be distributed only to the MAGIC nodes .. [1DC] Flags 2 RAF - This file area is located in the Remote Access file database. The system will process the file database and ignore FILES.BBS. SOP ON, send tic report to sysop PST ON, Pass-through area. Do not hatch file to the local BBS system ARC ON, Convert inbound files to a new compressor BAN ON, Include banner in the file archive .. [1DD] TIC Nodes Access to the database containing all TIC nodes linked to this TIC Area. .. [1DE] User downlinks Access to the database containing individual systems and/or users that will receive a copy of the TIC file in distribution. .. [1DF] FileFix Text In the echomail TIC reports, MailGate may append a default text file to the message. The text file is "TAGLINE.TIC" and should be located in \MG\TIC ("TIC Path"). If you want to have specific text files to be included in the echomail reports, check the same option as this one in the "TIC Area Manager". .. [1DG] Banner Text Text file used as the banner that will be included in the compressed files in TIC distribution. It will only be included if the TIC area has the BAN flag set to ON. .. [1DH] Batch File Batch file that will be executed right before the inbound TIC file is distributed to TIC links in the corresponding area. Inside this batch file there may be as many commands as needed to do any particular and special operation on the file being distributed. .. [1E0] TIC Node Node number of the system that will be a member of the current TIC Area. .. [1E1] Flags The following 4 flags define the status of the TIC netmail with the corresponding attached file. HLD - Hold. TIC files are sent only when destination node makes the call DIR - Direct. Overrides the default route and points netmail to destination CSH - Crash. The system will force a call to destination node KIL - Netmail will be deleted after sent SND - This node may send files for TIC distribution RCV - This node may receive files from distribution ACT - This node is active to receive files BNK - Binkley compatible file attach. .. [1F0] User Name Name of user who will receive a copy of the file in distribution, or just a notification of the file being released. .. [1F1] Downlink Node Node number that will receive the file attach and/or notification. .. [1F2] Flags The following 4 flags define the status of the TIC netmail with the corresponding attached file. HLD - Hold. TIC files are sent only when destination node makes the call DIR - Direct. Overrides the default route and points netmail to destination CSH - Crash. The system will force a call to destination node KIL - Netmail will be deleted after sent RCV - This node may receive files from distribution ACT - This node is active to receive files BNK - Binkley compatible file attach. ATT - If ON, the user will receive a copy of the file, via file attach. OFF means that only the netmail report will be sent to the user. .. [200] Node Number This is the Node number of the TIC link system configured here. Only Nodes configured in the Node Manager will be able to be members of TIC Areas in the system. .. [201] Sysop Name of the sysop of the downlink system. This name will be used during transmission of TIC files in distribution, to replies to RAID requests, and to general notifications for the system. .. [202] TIC Password Password used to validate TIC files coming from this Node for distribution and also to send in the TIC file attaches. If this password does not match with the one issued in the "Pw" field of the TIC control file, the file in distribution will not be sent to the other downlinks, and the incoming TIC control file will be renamed to *.BAD. .. [203] RAID Password Password used to validate RAID requests from this downlink system. RAID requests are netmail messages sent to one of the RAID Aliases, or to RAID itself, at one of the Node numbers of your system. In the subject line of the netmail, the sysop must write the RAID password. If the password matches with the one configured here, the system will process the RAID request, otherwise the request will be cancelled. Below follows the complete set of commands available in the RAID manager of MailGate: This is the list of commands available to you. + Connect an area - Disconnect an area %HELP or %H This help message %LIST or %L To request a list of areas available to you %QUERY or %Q List of available areas to which you are connected %UNLINKED or %U List of available areas to which you are not connected %PASSWORD or %P Change your AreaFix password %-ALL Disconnect all areas %+ALL Connect all areas %NOTIFY=[On/Off] Turn the notify function on/off %MESSAGE=[On/Off] Turn the message function on/off %TICK=[On/Off] Turn the TICK file option on/off %STATUS Status report with configuration %INACTIVE Temporarily turn off all areas %ACTIVE Turn inactive areas back on %FROM [address] Remote maintenance for other nodes %RESEND file Resend a TIC file that has been already processed ---------- To send a request to the RAID manager, the user has to supply his RAID password in the subject line. In the subject line, the user can also send some summarized commands that will force MailGate to execute the same functions as if they were written in the body if the text. For example: From: John Green, 12:1280/7 To: Raid, 12:1280/1 Re:secret %h %q ---- +virus -nodediff %list The %h has the same effect as the %HELP command if sent in the netmail, and the %q has the same function as the %query if sent in the netmail. .. [204] Groups Set of groups to which the current node has access. Netmail sent to the RAID manager will only operate on the TIC areas that are configured in one of the groups listed here. .. [205] Flags The following 4 flags define the netmail status for RAID replies HLD - Hold. Netmail is sent only when destination node makes the call. DIR - Direct. Overrides the default route and points netmail to destination. CSH - Crash. The system will force a call to destination node. KIL - Netmail will be deleted after sent. FRW - Forward. The system may execute requests for other nodes in the system NEW - Insert. The system may create/remove new TIC areas in the system. AUT - Automatic. If this system sends a TIC file in an area where it is not subscribed, the file will be distributed and the node subscribed. MAG - Remote node may ADD a new MAGIC file not found in the system FMG - Sending node may UPDATE existing MAGIC file in the system NFY - Turn on/off the notify function for options MSG - turn on/off the message function BNK - This node will receive TIC files in Binkley format. OFF=Front-Door file attach. .. [210] FileFix database Database that contains all FileFix systems, allowing MG to process an ARCHIE file searching capability in a Fidonet compatible network. .. [211] Max FileFix files Maximum number of files to be processed in one single request to FILEFIX. This will avoid long messages and time consuming processing. .. [212] FileFix From: Define the name that will appear in the From: field of echomail or netmail replies, sent to requests to the FileFix server. .. [213] ATTACH database Text file that contains a list of subdirectories that MG has permission to access and search for files for the ATTACH command of the MGSERVER manager. .. [220] FILES.BBS MailGate defaults to FILES.BBS as the text file that contains the updated list of all files and their descriptions. If your system works with a different kind of file, you may enter in this option the full path and name of such file. This may also be used if your system has a CD-ROM and has to keep its FILES.BBS files in different directories in your hard disk. If the RAF flag is ON, it means that this File Area is located in the Remote Access file database, which means that this entry will not have any effect. .. [221] FidoNet Node Node number of the BBS system that supplied the "FILES.BBS" file for the FileFix manager. This node will be reported on the Echomail FileFix replies. MG may also create netmail requests to this node, if the file list of such node is not located in your system, and if it has the RQT flag set to ON. RQT means "Request", and this allows MG at one system to pass the request on to the next system, and this cycle of requests will eventually end up in the last system in the chain, and all systems that processed the request will be able to send the final report to the requesting user. .. [222] Description This is an optional entry that may be used to give more details about the system that supplied the "FILES.BBS" file. It will be used during FileFix replies in echomail. .. [223] Flags Flags defining the behavior of the current node. HLD DIR CSH KIL Define the status of the requesting netmail that may eventually be forwarded to the BBS system defined in this entry. This will only be used if the RQT flag is set to ON. RQT Instead of looking for files in the "Allfiles" file, MG will send a netmail to Mgserver, at the node defined in this entry, with the FILEFIX command inside the message, as defined in the syntax of the MGSERVER manager. .. [230] ARC Archive program, and syntax, used to add banners to TIC files in distribution. .. [231] ZIP Archive program, and syntax, used to add banners to TIC files in distribution. .. [232] ARJ Archive program, and syntax, used to add banners to TIC files in distribution. .. [233] LZH Archive program, and syntax, used to add banners to TIC files in distribution. .. [234] ZOO Archive program, and syntax, used to add banners to TIC files in distribution. .. [235] GZ Archive program, and syntax, used to add banners to TIC files in distribution. .. [240] ARC Archive program, and syntax, used to add banners to TIC files in distribution. .. [241] ZIP Archive program, and syntax, used to add banners to TIC files in distribution. .. [242] ARJ Archive program, and syntax, used to add banners to TIC files in distribution. .. [243] LZH Archive program, and syntax, used to add banners to TIC files in distribution. .. [244] ZOO Archive program, and syntax, used to add banners to TIC files in distribution. .. [245] GZ Archive program, and syntax, used to add banners to TIC files in distribution. .. [247] ARC Archive program, and syntax, used to add banners to TIC files in distribution. .. [248] ZIP Archive program, and syntax, used to add banners to TIC files in distribution. .. [249] ARJ Archive program, and syntax, used to add banners to TIC files in distribution. .. [24A] LZH Archive program, and syntax, used to add banners to TIC files in distribution. .. [24B] ZOO Archive program, and syntax, used to add banners to TIC files in distribution. .. [24C] UGZ Archive program, and syntax, used to unpack TIC files in distribution that will be converted to another type. .. [250] TIC Area Enter the name of the TIC Area from which you want your file to be hatched. If you type ENTER with this entry in blank, A list of all available TIC areas in the system will be displayed. .. [251] File Name Name of file that will be sent in distribution in the selected TIC Area. Type ENTER when this entry is blank to have a list of all files available in the subdirectory defined in the configuration of the TIC Area. .. [252] File Description This is the description of the file that will be hatched. .. [253] Directory If the file to be hatched is not located in the subdirectory of the TIC Area, you have to enter the proper directory where the file is located. .. [254] MAGIC Name If this file has a magic name and you wish to send it to the TIC links, you have to enter it here. Otherwise, leave this entry blank. .. [255] Release Date If you wish to force MailGate to hatch this file only after a certain date, enter the date the file has to be hatched. If MailGate has to distribute it now, leave this entry blank. .. [256] Release Time If you wish to force MailGate to hatch this file only after a certain time of the release day, enter the hour the file has to be hatched. If MailGate has to distribute it on the release day, at any time, leave this entry empty. .. [257] Send File! If everything is configured correctly, MailGate will start to blink at this entry, saying that it is ready to send the file. Note however, that the distribution is not done right away. MailGate creates a TIC file with extension .TOK in the TIC HOLD directory. When MailGate is executed with the TIC functions set to ON, it will look for .TOK files and then, treat them as if they were .TIC files and execute the functions required for the distribution to all downlinks of this TIC Area. .. [260] Delete Node Node to be deleted from a set of TIC Areas located in one specific TIC group. There are two basic ways of removing a node number from a TiC Area. First, in the individual configuration of the TIC Area, you remove the Node Number, and second, if you wish, you may remove one Node from a set of TIC Areas from one TIC Group. .. [261] Add Node Node to be added to a set of TIC Areas located in one specific TIC group. There are two basic ways of adding a node number to a TIC Area. First, in the individual configuration of the TIC Area, you add the Node Number, and second, if you want to add one Node to a set of TIC Areas from one TIC Group. .. [270] Primary BBS Main node for the Primary network. Mail locally generated by MG, in the domain of the Primary network, will be sent from this node. .. [271] Primary Gateway Node used for the gateway of netmail and echomail (using the fake system), in the domain of the Primary Network. .. [272] Secondary BBS Main node for the Secondary network. Mail locally generated by MG, in the domain of the Secondary network, will be sent from this node. .. [273] Secondary Gateway Node used for the gateway of netmail and echomail (using the fake system), in the domain of the Secondary Network. .. [280] Mail Path Directory where inbound/outbound netmail is stored (*.MSG files). MailGate will search this directory for netmail sent to the gateway servers. It must be the same directory as configured in your Front-end mailer and netmail/echomail utility. If you set the "EXit Batch" ON in the "Run-Time options" Menu, or if you do so when running MailGate with the +J switch (Run MG -? for switches), MailGate will execute a batch file named MSGEXIT.BAT, located in main configuration path. You can customize this DOS batch file to execute the functions you wish whenever MailGate creates one or more *.MSG message files. Either way, Mailgate exits with errorlevels when *.MSG is generated. Run MG -? for details. .. [281] File Path Directory where inbound files are received by your Front-end program. MailGate needs this directory to save new echomail packets in uncompressed PKT files, so that your echomail utility can toss them into the BBS system and forward them to your downlinks. MailGate does not compress PKT files created, since your echomail utility would have to uncompress them anyway. This way, make sure that your echomail utility is able to process uncompressed PKT files. MailGate generates PKT mail when: - Mail from Listservers or Newsgroups is received from the UUCP server; - Mail from the echomail gateway is processed; - Automatic replies from the TIC manager when TIC files are processed. Mailgate provides customized Exit process. In the main configuration path of MailGate, edit a file called PKTEXIT.BAT, and, if the "EXit Batch" option is set ON, MailGate will execute this batch file. Anyway, MailGate exits with an errorlevel whenever *.PKT mail is generated. Run MG -? for details. .. [282] Node Path This is the directory where MailGate will process its local database files with the Primary and Secondary nodelist compilations and the ALIAS Database files. This directory has nothing to do with the Nodelist Path configured in your Front-end program, even though you can use the same Path for the job. MailGate will automatically create sub-directories in the "Node Path", using the ID letters assigned to each Network. Inside these new sub-directories, MailGate will keep the database files. By correctly selecting ID letters for the networks you have in different configurations of MailGate, you can save space and time by having the same database files for the various configurations. This is needed in the case you run more than 2 Networks. .. [283] Fido Server Path The Fidonet servers need this directory to execute the NETMAIL, PKTMAIL (locally activated functions) and MGSERVER, MGDOS (remotely activated functions). Inside this directory, your system will store *.TXT files that will be the message texts for any function requesting them. The following subdirectories should be created inside the Fido Server Directory: MSG Automatically sends netmail to destinations listed in *.CTL files. The message text is *.TXT with same name. PKT Automatically sends echomail to AREAS listed in *.CTL files. The message text is *.TXT with same name. PASSWORD Remotely executes batch files sent in netmail to user MGDOS. The subject contains the name of the file with extension PSW, whose content are acceptable DOS commands. FILES Contains files available for the ATTACH command of MGSERVER A subdirectory MGSERVER will be automatically created by MailGate whenever netmail sent to the MGSERVER user is processed. MailGate stores the message texts of such netmail so that your own utilities can execute any command not found in the command set MailGate provides. There are basically 2 groups of functions in the Fidonet Server: 1 - Locally activated functions These functions are executed by the system locally, and can only be activated with the use of switches passed to MailGate in the DOS command line. According to MG -?, the switches are Z and W. +Z will execute the Netmail Server and +W will execute the PKT Server. 2 - Remotely activated functions These functions are executed whenever netmail come to one of the local nodes of the system.The netmail must be addressed to either MGSERVER or MGDOS users. 1.1 - MSG Netmail Server (activated when executing MG +Z) You can send netmail to any user/node, with text files as the body of the netmail. These text files must be located in the Fido Server Directory. Inside the MSG subdirectory, you will edit the netmail control files. For example, let us assume that the Fido Server Directory is \MG\FIDO. There is a file called TXT\NETMAIL.TXT in this directory, and you may want to send it to 100 users. You will edit NETMAIL.CTL inside \MG\FIDO\MSG whose format is: [Sender Node] [Sender User Name] [netmail subject] [Destination Node] [Destination User Name] 1.2 - PKT Echomail Server (activated when executing MG +W) You can send echomail to any area, with text files as the body of the message. These text files must be located in the Fido Server Directory. Inside the PKT subdirectory, you will edit the echomail control files. For example, let us assume that the Fido Server Directory is \MG\FIDO. There is a file called TXT\ECHOMAIL.TXT in this directory, and you may want to send it to 5 areas. You will edit ECHOMAIL.CTL inside \MG\FIDO\PKT whose format is: [Sender Node] [Sender User Name] [Destination Node] [Destination User Name] [echomail subject] [AREA1] [AREA2] [AREA3] .. .. The destination node must be a downlink listed on all echomail areas to where the message will be exported. The sender node will probably be your main node number (or the main node number of all areas). .. [284] Packet Path Main directory where outbound files are stored for later delivery by the Fidonet mailer system. .. [290] AREAS Path Directory where MG stores all configuration and data files used by the Area manager, local lists, message databases, listserver text files. .. [291] TXT Path MailGate will search this directory for any text message that will be sent as return replies for any request or usage of the system commands. Name them as you wish, and this menu will allow you to edit them according to your needs. Some hard coded file names must be placed here, for example, RAIDHELP.TXT, used as the HELP message for requests to the RAID remote manager. For more details on the RAID function, please refer to the TIC Menu. .. [292] MSGBASE Path Directory where the Hudson message base is maintained. .. [2A0] Directories These directories are needed for MailGate to work properly. If not correctly configured, MailGate will abort and send a warning message. Some of these directories must match with those specified in the other BBS programs you run, since MailGate will read and write mail and information to them. The names are suggestive and the pre-configured directories will give you no doubt about what they are for. If you do not provide the drive name, MailGate can operate throughout a network based system. Note that a SET statement should be provided in your AUTOEXEC.BAT to help MailGate locate the main configuration directory. Use SET MG=C:\MG if this is the directory where you configured MailGate and MG.CFG. Add in the PATH line where the EXE files are and MailGate can run from any directory. MailGate will first look for MG.CFG in the current path, then in the SET command. In this manner, you can have as many different configurations as you want, and different configurations may share the same directories. .. [2A1] Node Numbers Node numbers needed for the network to operate in Fidonet gateway mode. MailGate can deal with 2 Fidonet-compatible networks. They are called Primary and Secondary networks. The system will need information for the Primary network, and it is optional to provide information for the Secondary network, if there is any. These 4 node numbers are very important. For each network, primary or secondary, there are two node numbers, the first called "BBS" and the second, "Gateway". One example will make it clear to understand what these nodes are for. The "BBS" node is used by MG as the node that will receive any notification via netmail, all netmail reports and automatic replies. MG will automatically select which one, Primary or Secondary, will match the netmail in which it is operate on. The "gateway" node will only be used if any kind of echomail gateway will be done using the "fake" system. When generating PKT (echomail), MailGate may use the fake gateway system, instead of operating directly in the message base, as would do any echomail tosser. Instead of depending on any particular type of message area, MG creates PKT files, that will be processed by the echomail tosser afterwards. In this situation, the same PKT file may be processed by a Squish-compatible tosser, or JAM, Hudson, or any other type. But for the PKT file to be generated, it needs a From: and a To: node numbers. As a matter of fact, if there is a PKT file around, it is because a node number generated it to another node number. Here is where the Gateway node operates. Since the BBS node is probably one of the AKA nodes of your system, the gateway node will generate the PKT file to the BBS node. Therefore, It must not be a node LOCAL to your system. Imagine the gateway node as the node from the system across the system, that send you echomail regularly, in other words, the gateway node is one of the up/downlinks in your echomail system. For a matter of simplicity, let us assume that the gateway node is a point of your BBS. With examples, this is how things should work: BBS Node : 4:808/2 (local to the system) Gateway node: 4:808/2.1 (remote node) Taking one echomail area as an example, BBSING, MailGate will generate PKT files from: 4:808/2.1 to: 4:808/2. For the PKT to be tossed properly by my echomail utility, 4:808/2 must be the main node of BBSING and 4:808/2.1 must be one of the downlinks of this area. Similar situation takes place for the nodes in the secondary area. But these nodes, BBS and Gateway, are not only used for the PKT gateway system. They are also used for netmail-to-netmail gateway between the primary and secondary networks. Suppose that the Primary network is Fidonet (using the same example above), and that the secondary network is RBT (BBS Node: 12:1280/1 and Gateway node 12:1280/1.1). A netmail sent to 4:808/2.1, in the Fidonet domain, will be sent to RBT from: 12:1280/1.1 and vice versa. How to send netmail through the primary and secondary networks will be covered below. The process discussed here is documented in FSC-0078. You may read the official document or read the original scratch below, as it was sent to the Fidonet standards committee. Note: An outdated reference to the Secondary network was made as "Fakenet", which was substituted after some sysops claimed it could be dubious. ABSTRACT The word FakeNet will be used in this abstract to refer to any Fido-compatible network that is not in the Fidonet nodelist, thus using node numbers not found in the 1-through-6 Fidonet zones. A Fakenet uses its own nodelist. There is a large number of Fakenets all over, each one unaware of the existence of the others, some using the same node numbers in their own nodelists. We shall try to put these networks together, not by forcing any of them into a single nodelist, but by making them aware of the existence of the others, and providing gateways in each of these networks so that mail can flow in both directions. IMPLEMENTATION For a gateway to be implemented, extra information must be provided in the netmail. Normally, two user names, From: and To: define the sender and the addressee. The node numbers go "inside" the netmail and have their existences checked in the nodelist of the network in question by the local running software. Since we now have 2 networks, the extra information must be the remote node in the destination network, which obviously cannot be found in the local nodelist, and the local node that must reach the remote addressee, otherwise a reply cannot be made. Suppose, for example, that there are 2 Fakenets, one based in zone 10 (network 1), the other one in zone 11 (network 2), and that user John Green in node 10:100/1 wants to send a netmail to Paul Brown in 11:200/1. In both networks, a gateway node (common to both nodelists) must be provided. Let us say that node 10:10/1 is the gateway in network 1, named "Gateway system A" and node 11:11/1, named "Gateway system B" is the gateway in network 2. What John, from network 1, will have to do is: Send a netmail to his local gateway node, which is 10:10/1. In the To: field, he will put, besides the name of the addressee, Paul Brown, PAUL'S NODE NUMBER, 11:200/1, inside (). This is the extra information needed for the gateway to work. What will happen is: This netmail, in the domain of network 1, will travel the route and reach the gateway, 10:10/1. This gateway system must do the following: Change the domain of the netmail from network 1 to network 2. This means that any reference to node numbers in the netmail header must be updated. Thus, the netmail will now have the node 11:11/1 as the originating node, and 11:200/1 as the destination node, "hard coded" in its header. But we can see that John's node number must be provided, otherwise Paul will not be capable of replying. This is done by the gateway software that includes John's node number in his From: name field, inside (). When Paul receives John's netmail, he will reply, and the From: field will automatically become the new To: field, and will contain John's name and node number. The netmail will reach back 11:11/1 and the process will be exactly the same, finally returning to John. In short, this is the odyssey of John's netmail to Paul: 1 - John enters his message to Paul. Since Paul is not in John's network, John will have to use the gateway. He sends a netmail to his local gateway system, 10:10/1 which looks like this: From: John Green, John's BBS (10:100/1) To : Paul Brown (11:200/1), Gateway System A (10:10/1) Re : Hello ------ body of message ...... Note that John had to MANUALLY enter Paul's node number and put it in the To: field, together with Paul's name. This netmail is addressed to Gateway System A, node 10:10/1. 2 - After arriving in 10:10/1, the gateway software will create a new netmail that looks like this: From: John Green (10:100/1), Gateway System B (11:11/1) To : Paul Brown, Paul's BBS (11:200/1) Re : Hello ---- body of message.... Note that John's node number was inserted in the From: field, which is the information needed for bi-directional gateway to work. 3 - This netmail is now in the domain of network 2. It will travel the normal route and reach Paul. When he replies, the local message editor will make the From: field become the To: field. The netmail-reply will look like this: From: Paul Brown, Paul's system (11:200/1) To : John Green (10:100/1), Gateway System B (11:11/1) Re : Hello ---- body of new message..... This netmail will travel the route and reach 11:11/1. The process now is exactly the one used to gate the original netmail from network 1 to 2. The gateway software will create a new netmail that looks like this: From: Paul Brown (11:200/1), Gateway System A (10:10/1) To : John Green, John's system (10:100/1) Re : Hello ---- body of new message.... Note that Paul's node number was inserted in the From: field, finishing the gateway process. The only trade-off in the current proposal is obvious. The limited length of the name fields, which, according to FSC-0001, is 36 characters long, and that may not allow the inclusion of the person's node number in it. For example, if John's full name were John Green Richardson Smith Jr., he would have sent his netmail to Paul, but the gateway system would fail when attempting to include his node, 10:100/1 together with his name. In this case, the netmail is bounced back with a warning message, and it will be John's responsibility to use a shorter version of his name or an alias. It seems that more and more people are being practical and using only 2-word names, so this is a problem that can be easily worked out by the local BBS operator. Lastly, ^aINTL kludges must be issued in all netmail flowing through the 2 networks. This proposal follows FSC-0034 and FSC-0001. It also allows immediate application, since it relies on what Fidonet is in essence, FSC-0001. .. [2A2] Users Database containing all users who have permission to access MGSETUP. .. [2A3] Aliases Database containing the most frequent destinations used when writing messages in the message folder. Avoid having to manually type them every time you are sending a message. MGSETUP will prompt you to select one of the destinations configured here, and a simple click will include the destination in the body of your message. .. [2A4] AKA Match This configuration will define how MG will choose the local node number according to the node destination of a message, when written in the message editor or when MG is executing an automatic generation of netmail. .. [2A5] Domain Match To correctly assign the domain of a message in the Fidonet domain, MG needs information about the different networks names and the zones they are related to. This allows MG to correctly build a 5D node number. .. [2A6] All Nodelists Since MG operates with 2 distinct networks in one single configuration, there will be more than one network ID. For more configurations, with more networks involved, more IDs and nodelists will exist in the system. When using the message base, though, it is important to be able to access all possible nodelists used in one or more configurations of MG, so to avoid a netmail from not being correctly recognized. This menu allows the configuration of all IDs that are assigned to different networks in different configurations, forcing MG to scan through all nodelists to find the correct match for a specific netmail/node number. .. [2A7] Decompression Set of archiving programs that will allow MG to decompress files that are under process during run-time. .. [2A8] Compression Set of archiving programs that will allow MG to compress files that are under process during run-time. .. [2A9] External DOS General configuration for memory management when executing external programs. .. [2AA] CFG Identification Character used to identify the current configuration of MG. This byte is the first one in the binary MG.CFG, and is used to name the MGBUSY.* file that is created whenever MG.EXE is executed. This file will indicate to the system that there is a copy of MG running in that subdirectory, and this will avoid other copies from running in the same directory, concurrently. MailGate creates temporary files in the subdirectory is was run from, and these files cannot be deleted, specially files with extension *.$$$, removed only when MG.EXE finishes working. .. [2AB] External ASCII Editor External program used as a text editor when accessing text files or writing new messages in MGSETUP. .. [2AC] Log Type MailGate has three different levels of logging the process during execution. 0 means that no logging should be generated, 1 means that only the basic and important functions are to be logged, and 2 means that every single detail of the operation is to be processed, which may take up a lot of space. .. [2AD] Log File Enter the full path and name of the file that will hold the logging of the system. The path will be used to hold the ASCII dumping file, hard coded as MG.DMP. .. [2AE] Keyboard buffer You may configure a sequence of keystrokes that are mostly used when you start up MGSETUP. .. [2AF] Mouse Active If you do not want to use the mouse interface of MGSETUP, you may disable it with this option. Note that the mouse interface of MGSETUP will only be active if you installed a mouse driver when your machine was switched on. .. [2AG] Screen active For purposes of speed, writing messages on the screen takes a little delay. If your main concern is speed and you are sure that what you configured is working properly, you may set this option to ON to force MG to operate in silent mode. .. [2AH] Time Zone Time Zone used for time stamps in UUCP mail. Previous versions of MailGate were searching for the TZ variable in the DOS environment. .. [2B0] A - Main Node This is the main local Fidonet node of the system. .. [2B1] B - AKA 1 One of the local Fidonet AKAS of the system. .. [2B2] C - AKA 2 One of the local Fidonet AKAS of the system. .. [2B3] D - AKA 3 One of the local Fidonet AKAS of the system. .. [2B4] E - AKA 4 One of the local Fidonet AKAS of the system. .. [2B5] F - AKA 5 One of the local Fidonet AKAS of the system. .. [2B6] G - AKA 6 One of the local Fidonet AKAS of the system. .. [2B7] H - AKA 7 One of the local Fidonet AKAS of the system. .. [2B8] I - AKA 8 One of the local Fidonet AKAS of the system. .. [2B9] J - AKA 9 One of the local Fidonet AKAS of the system. .. [2BA] K - AKA 10 One of the local Fidonet AKAS of the system. .. [2BB] L - AKA 11 One of the local Fidonet AKAS of the system. .. [2BC] M - AKA 12 One of the local Fidonet AKAS of the system. .. [2BD] N - AKA 13 One of the local Fidonet AKAS of the system. .. [2BE] O - AKA 14 One of the local Fidonet AKAS of the system. .. [2BF] P - AKA 15 One of the local Fidonet AKAS of the system. .. [2BG] Q - AKA 16 One of the local Fidonet AKAS of the system. .. [2BH] R - AKA 17 One of the local Fidonet AKAS of the system. .. [2BI] S - AKA 18 One of the local Fidonet AKAS of the system. .. [2BJ] T - AKA 19 One of the local Fidonet AKAS of the system. .. [2C0] User Name Name of the user who is using this account. This is the name that comes in the name field of the netmail. .. [2C1] Password Password required to be granted access to MGSETUP. .. [2C2] Security Security level of user when using the functions of MGSETUP. This will be considered when writing, reading and maintaining the message base. .. [2C3] User Flags Operational flags for the current user. HLD DIR CSH KIL - Default netmail flags when writing messages in the netmail folder. SUP ON, User is supervisor. Only supervisors will have access to other menus from the Main Menu. Users without the SUP status can only go as far as the message base editor. .. [2D0] Main Alias Main user name used for an alias. An alias is divided in two parts, the main or fantasy name, and the real denomination, or destination. For example, on the Internet, my full address is "Clovis Lacerda" The first part is exactly equal to my name on the Fidonet, and is my main alias. The second part, the real information a message needs to reach me on the Internet, is called the "destination". For fax messages, the destination would be the phone number, and the Main Alias would be used just as a reference for the current user alias. .. [2D1] Destination The main information needed to address a message. Please check the help for the Main Alias option. .. [2D2] Alias Flags Operational flags for the current alias. HLD DIR CSH KIL - netmail flags used for netmail created to alias user NET ON, Netmail Destination FAX ON, Fax Destination (netmail will be directed to the fax user at the main node of your BBS). UUP ON, UUCP Destination (netmail will be directed to the UUCP user at the UUCP gateway node) BCC OFF - UUCP Carbon Copy. ON - UUCP Blind Carbon Copy .. [2E0] A - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E1] B - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E2] C - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E3] D - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E4] E - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E5] F - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E6] G - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E7] H - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E8] I - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2E9] J - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EA] K - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EB] L - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EC] M - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2ED] N - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EE] O - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EF] P - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EG] Q - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EH] R - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EI] S - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2EJ] T - Nodelist ID Nodelist ID, as configured in the Primary or Secondary Networks of the current or any other existing configuration of MG. .. [2F0] ARC Archive program, and syntax, used to add banners to TIC files in distribution. .. [2F1] ZIP Archive program, and syntax, used to add banners to TIC files in distribution. .. [2F2] ARJ Archive program, and syntax, used to add banners to TIC files in distribution. .. [2F3] LZH Archive program, and syntax, used to add banners to TIC files in distribution. .. [2F4] ZOO Archive program, and syntax, used to add banners to TIC files in distribution. .. [2F5] GZ Archive program, and syntax, used to add banners to TIC files in distribution. .. [300] ARC Archive program, and syntax, used to add banners to TIC files in distribution. .. [301] ZIP Archive program, and syntax, used to add banners to TIC files in distribution. .. [302] ARJ Archive program, and syntax, used to add banners to TIC files in distribution. .. [303] LZH Archive program, and syntax, used to add banners to TIC files in distribution. .. [304] ZOO Archive program, and syntax, used to add banners to TIC files in distribution. .. [305] GZ Archive program, and syntax, used to add banners to TIC files in distribution. .. [310] COMMAND.COM When executing external programs, MG invokes a new call to COMMAND.COM before running the program. This allows MG to execute batch files besides normal EXE files. If for any reason your system is having problems with the execution of external programs by MG (if you run MG from a DOS windows in a multitask operational system), try setting this option to OFF, thus forcing MG to execute the file directly, instead of loading COMMAND.COM. This option should be activated only in extreme cases and for purposes of debugging only. There is no reason for a call to COMMAND.COM fail. .. [311] Swap Path Path that will be temporary used to hold the swap file created by MailGate when executing external files. If you want the system to swap to memory, set EMS and XMS to ON. This will make execution of external files a little faster. .. [312] Swap EMS EMS will be used when executing external files and swapping memory. .. [313] Swap XMS XMS will be used when executing external files and swapping memory. .. [314] Exit Batch MailGate provides a very easy way of exiting after it has executed all the required functions. MailGate always exits with the correct errorlevels, according to what was processed during execution. But you can force the system to execute customized DOS batch files whenever netmail, echomail, UUCP or Fax mail is generated. In the Main directory where the *.EXE files are located, edit the files: MSGEXIT.BAT UUCPEXIT.BAT FAXEXIT.BAT PKTEXIT.BAT and include the programs you want to be executed by these batch files. This function can also be activated with the -J switch when running MailGate from the DOS prompt. MSGEXIT.BAT - Executed whenever MailGate generates netmail PKTEXIT.BAT - Executed whenever MailGate generates PKT mail UUCPEXIT.BAT - Executed whenever MailGate generates UUCP mail FAXEXIT.BAT - Executed whenever MailGate generates Fax mail MailGate will still exit with the proper errorlevels. .. [320] Areas This is the heart of MailGate. All important functions operate with a particular message area, if the message is not a private netmail/email, obviously. Echomail areas in gateway with newsgroups, listservers, fax server, FileFix server and all other functions of MG, are configured in the Areas database. .. [321] Groups Set of groups to which the current node has access. Netmail sent to the RAID manager will only operate on the TIC areas that are configured in one of the groups listed here. .. [322] Default Areas Default configuration for the message areas, that MG invokes every time a new message is being created by the sysop or when MG is automatically creating a new message area. .. [323] NetMail Folder Security level (default) for the netmail folder. This will affect the security level the various users of the system have, when accessing MGSETUP. .. [324] Global Global options to change the configuration of all message areas within a particular message group. Each message area may be individually changed in the Areas database, use this option to change message areas at one single time. .. [325] Import Config Import the message configuration from various systems that might be working in your system. .. [326] Export Config Export the current message area configuration of MG to other systems. .. [330] Echomail Area Name of echomail area for this message folder. This field is the one that defines the message area in the message base, as well as the AREA: definition in the PKT echomail file. .. [331] Hudson Board If this message area is configured in the Hudson message base, supply the message board number, that must be between 1 and 200. .. [332] Area group Message group this area belongs to. .. [333] Read level Security level a user need to have to be able to read messages in this area. .. [334] Write level Security level a user need to have to be able to write messages in this area. .. [335] Sysop level Security level a user need to have to be able to maintain this area. .. [336] Base Path If the area is JAM or Squish, supply the full path/name of the board. .. [337] Main Node Main Fidonet node that manages this message area. .. [338] Origin Line Edit the origin line that will be used when configuring message areas in the Area Manager. .. [339] Tear Line Tearline appended to messages generated in this area. .. [33A] Area Type Defines the message base type used for this area. - Hudson base - JAM base (not available in this current version) - Squish base (not available in this current version) - SyncNet base (not available in this current version) .. [33B] Echomail Toss ON, toss echomail directly. OFF, use fake downlink This flag is important and defines the operation mode MG will use when processing echomail. If the flag is ON, MG will toss and scan echomail directly from the message area. If OFF, MG will create PKT files that will need to be processed by an external echomail program. In this current version of MG, the internal echomail tosser is not available yet, so the only operation available is through the fake downlink. MG will create PKT files From: Fake Node To: Main Node. For example: If the Main Node of this area is 4:808/2, MG will look for this node in the configuration, and it must be either the Primary BBS or the Secondary BBS. If it is the Primary BBS, MG will use the Primary Gateway as the fake link node. Assuming that the Primary Gateway is 4:808/2.1, PKT will be generated by MG as being From: 4:808/2.1, To: 4:808/2. In this case, the external echomail utility must be configured as follows: The message area defined here must also be defined in the echomail utility. The main node of that area must be 4:808/2 The node 4:808/2.1 must be one of the downlinks of such area. This way, when the echomail utility is executed in TOSS mode, it will process the PKT file as if it had arrived in the system, sent by node link 4:808/2.1. The message will be tossed to whatever message base was defined, and forwarded to as many downlinks as the echomail area is configured to deal with. PKT files are generated whenever MG processes Newsgroups, List mail, FileFix reports, and so on. .. [33C] Echo/Net Area ON means that the area is echomail, OFF means that the message area is available for one of the local netmail AKAS. .. [33D] Gateway Menu that gives access to the configuration of all gateways being done with the current message area. .. [340] Gateway Area Echomail area that is in gateway with the current area. MailGate can provide the gateway of echomail between two Fidonet compatible networks, and in the current situation, between Primary and Secondary Networks. Echomail flowing in one network may also be flowing in the domain of the other network. For this to happen, one example will make it clear. Suppose that Primary Network has nodes Primary BBS - 4:808/2 Primary Gateway - 4:808/2.1 Secondary Network Secondary BBS - 12:1280/1 Secondary Gateway - 12:1280/1.1 In the Primary network, there is an echomail called MAILGATE-FIDO. In the Secondary network, there is an echomail called MAILGATE-RBT It is desired to have both echomail conferences in gateway between the two Fidonet networks. This is what must be done: 1 - Both networks must force the echomail program to create echomail packets to the gateway nodes. In the Primary network, a new feed must be supplied to 4:808/2.1 This means that an echomail file attach will be created and addressed to 4:808/2.1. The same is done in the Secondary network, ending up with the creation of echomail packets to 12:1280/1.1. When MG is executed, it will look for echomail file attaches addressed to one of the Gateway nodes. After finding the file addressed to 4:808/2.1, MG will decompress it and create a new PKT file, in the inbound file directory, now From: 12:1280/1.1 To: 12:1280/1. The new created file is in the domain of the Secondary Network. When the echomail program is executed, this message will be tossed and processed in the domain of 12:1280/1. The opposite situation takes place when MG detects the presence of an echomail file attach addressed to 12:1280/1.1. This is how both echomail areas must be configured: For each one of them, an entry must be created in the Areas manager. If the Echomail Area is MAILGATE-RBT, then the Gateway Area is MAILGATE-FIDO. The flag PKT (indicating a gateway between PKT<>PKT) must be set to ON in flags 3. The opposite must be made for Echomail Area MAILGATE-FIDO, having MAILGATE-RBT as the Gateway Area, and flag PKT set active. Finally, it must be noted that, following the given example, that the Main node of MAILGATE-RBT is 12:1280/1 (corresponding to the Secondary Network), and the Main node of MAILGATE-FIDO is 4:808/2 (corresponding to the Primary network). .. [341] Newsgroup Name of newsgroup area in gateway with the current echomail Area. For a newsgroup to be definitely in gateway, the NWS flag must be set ON (flags 2). Finally, one very important thing that must not be forgotten: In every newsgroup area, you MUST include at least one UUCP news link. in particular, the Default UUCP host. If this is not done, MG will toss the messages from PKT, but will forward them to no place and you will wonder what made the messages disappear. .. [342] Distribution Applied only to newsgroups. This field defines the range of the distribution of this newsgroup area. .. [343] List Area There are two ways of dealing with Listserver mail. First, you may define the current echomail area as being in gateway with the local listserver managed by MailGate. This way, users on the Internet may subscribe to this area and receive the messages via email. For this to happen, the List Area must be under your UUCP domain, for example, MG-L@EAR.ANPE.BR. The following flags must be active: Flags 2 - LST LOC LST = List LOC = Local You must also supply the name of the file that will contain the name of users who subscribe to the list. This way, the List User base must have a valid file name. This file will be maintained in \MG\AREAS. To check if the configuration of the local list is correct, type F2 and you should have access to the List user database. If the F2 function does not work, there might be something missing in the configuration. There is also another way to operate with mail from listservers. When you subscribe to a remote listserver area, mail in distribution from the list arrives in your system as private mail to your address. You may wish to have these messages sent to an echomail, rather than to your mail-box. Doing so, you will allow your users and your net to have access to this mail. One example should make the configuration clear: Suppose user clovis@ear.anpe.br subscribed to the HELP-ME list available at listserv@univers.com. The configuration should be List Area: HELP-ME@UNIVERS.COM PostMaster: clovis@ear.anpe.br Active flags: Flags 2: LST The List Area must be the full name of the address of the list, to where mail for distribution should be sent (and consequently, where mail in distribution comes from). The Postmaster is the person who subscribed to the list. Mail in gateway will be sent to the listserver From: this user, who is the only one allowed to send mail. Being so, the only way to identify the real person who sent the message is via the REPLY-TO field. If a user writes a message in echomail HELP, and if this area is in gateway with HELP-ME, here is how things will work: From: Bruno Santos, (4:803/3) To: All Re:Need information ----- Hi all, I need to find the address of a friend who studies in Norway. What should I do? Thanks Bruno. The originating node was highlighted only for the purpose of clarity, but we all know that it comes hidden in the echomail message header. The TO: field is irrelevant, since mail in lists do not go to specific users, but rather, to a list of subscribed users. This is what will be made of his mail when sent to the Internet domain, according to the RFC-822 message header (part of it): From: "Clovis Lacerda" To:help-me@univers.com Reply-To: "Bruno Santos" Subject: Need information X-Mailer: MailGate 0.21 Hi all, I need to find the address of a friend who studies in Norway. What should I do? Thanks Bruno. This is the trick that makes the message be accepted. The From: field, does not contain Bruno's address, which would inevitably force the Listserver at UNIVERS.COM to reject it (after all, it is not Bruno who is subscribed on the list). MailGate inserted the Postmaster in the From: field, thus forcing the mail to be accepted and broadcasted by the Listserver. Note however, that this mail was sent under the name of the Postmaster, who will be held responsible for the contents of any mail flowing through the gateway. Please, be careful. For the mail to reach Bruno is that his address was listed in the Reply-To field, which is actually the one that mail readers give preference to. The "PostMaster" field is confusing at first, but it becomes clear that this denomination is useful if the list is local to your system, and the postmaster would be the person in charge of maintaining the list. If you set the LOC flag to ON for remote lists in gateway, you will also be able to accept subscriptions sent to your system, and re-distribute mail sent from the main listserv source. This procedure, however, will surely need the formal permission from the List owner, who may or may not allow you to do so. There are more flags that determine the behavior of Listserv mail, all of them located in Flags 2. VIP - Only VIP users may use the gateway PUB - Mail from Internet users not subscribed on the list will be distributed. PUB=Public. PVT - Subscriptions will not be automatically processed. The Postmaster will receive the request and proceed accordingly. 822 - If ON, the entire RFC-822 header of inbound mail will be included in the PKT converted messages. FRW - Forward. Besides converting List mail to echomail, forward a copy of the message to the postmaster, via netmail. NID - New Identification. MG gets the Message-ID from the RFC-822 header when creating PKT mail. If you detect duplicate mail, force MG to always create a new Message-ID, by setting this flag to ON. TO: - MailGate will scan the echomail area for messages that contain a valid Internet destination in the TO: field. If so, the message will be forwarded to the destination via netmail. .. [344] List Title Needed only for LOCal lists. It is the definition what the List and appears in the SENDER: field. .. [345] PostMaster Full user+domain name of the person who subscribed to this remote list, or is the manager of this list, if Local. Examples: Suppose that list HELP-NET, from a remote listserver, is to be imported as echomail of same name. There must exist a user who subscribed to that list in the first place. If such user was clovis@ear.anpe.br, this is they postmaster that must come in this entry. All mail leaving the system, addressed to HELP-NET will go with a From: clovis@ear.anpe.br, even though the message was not originally written by him. The real address of the user who sent the message goes in the Reply-To: of the RFC-822 header. This way, all messages leave the system under the responsibility of the "postmaster", who is the only person subscribed to the remote list. .. [346] List Userbase Used only for LOCal lists. This file is mandatory, since it will store the names of all users who subscribed to the local listserver. .. [347] List files Text files and subdirectories used by local lists. .. [348] Fax Base Phone number or Fax database file that contains the fax destinations that will receive a copy of mail from this Area. .. [349] Fax Grade Fax Grade used to identify all Fax messages originated from this message area. .. [34A] Flags 2 These options define the behavior of the gateway made with the Internet. They were all explained, and a summary is given below. VIP NWS LST LOC PVT PUB FIL 822 FRW NID TO: DIG CLS FRM INF POM Summarized: VIP Only UUCP VIP users may use the UUCP<->Echo gateway NWS Newsgroup activated. This area is in gateway with "newsgroup" LST List activated. Remote or local full domain of area LOC List is local. Activate listserver + subscription PVT ON, Private List, subscription requests are sent to the sysop PUB ON, Local List Area is Public. Mail from Internet is accepted FIL ON, area will be scanned for UUCP files in automatic release 822 ON, include full RFC-822 header in echomail messages FRW Forward a copy via netmail to the subscribed user NID ON, MG generates new msgid for PKT mail created from UUCP mail TO: look for valid uucp To: destination in PKT message and send as email DIG Digest. This local list is allowed to process DIGEST type of mail CLS No RFC822 header from converted UUCP mail FRM User Name in PKT From: instead of Internet address INF Include destination of PKT mail when converted to Newsgroup POM Send copies of requests to the PostMaster Detailed: PVT - Private. If ON, users will not be allowed to automatically subscribe on this List with the SUBSCRIBE command, but the request will be sent to the Postmaster PUB - If ON, any user, even if not subscribed, may send mail to the List for distribution. If OFF, only previously subscribed users may send mail to the list. FIL - Files. If ON, any *new* file located in the File Server subdirectory of this area will be automatically sent to the subscribed users who have the FIL flag ON in the List Users Database (Use F2 to Edit) Warning: Files in distribution will only be accepted if: 1 - They are located in the FileServer subdirectory; 2 - They are listed in the FILES.BBS file; 3 - They are not listed as DUPlicates in the FILES.DUP file. 822 ON, MG will include the complete RFC-822 header in converted Fidonet mail. If OFF, MG will only include 4 or 5 lines with the basic and most important information. FRW If this echomail area is in gateway with a remote list, it means that email received to the "postmaster" (who is a local user in your system), will be forwarded to the PKT file, instead of being sent to him via netmail. If this flag is set to ON, MG will process the gateway and also send a copy of the email to postmaster, as it would normally happen. NID If you notice echomail duplicate messages, set this flag to ON to force MG to issue a new message-id to every message. When OFF, MG removes the message-id from the original RFC-822 header and uses it as the echomail message-id. TO: This flag is useful if you need MG to check if messages written in this echomail area has a valid Internet destination issued in the To: field. If found, MG, besides doing the normal gateway operation, will forward a copy of the message via private email to the destination user. This can also be used to force MG to scan certain echomail areas for valid Internet destinations. DIG This Local list area is allowed to create DIGEST files. Every message in gateway with this echomail<>List will be saved in a text file with file name equals to the UserBase and extension .DIG, and stored in the Areas Path. During certain days of the week, as configured in MG, this file will be broadcasted to all subscribed users who have the DIG flag set to ON in their individual configurations. This status may be set by the subscribed user via a command to the listserver. For example SET MG-L DIGEST will set the user's account to DIGEST SET MG-L NODIGEST will set the account back to normal CLS If ON, this flag overrides the 822 flag. It will not allow MG to import any RFC822 header information from UUCP mail, when converted to echomail. FRM MG usually imports the sender's Internet address into the FROM: field of echomail, when converting newsgroups or lists. If you want MG to import the user's name rather than his address, set this option to ON. For example, if the newsgroup's from: field is From: clovis@ear.anpe.br (Clovis Lacerda) The From: in the PKT will be From: clovis@ear.anpe.br if FRM is OFF or it will be From: Clovis Lacerda if FRM is ON. INF When writing messages in echomail areas, the TO: destination user is defined. However, when this message is converted to Newsgroups, the destination user will be ignored, and only information about the sender of the message will come in the RFC822 header. However, if INF is set to ON, MailGate will automatically include a line such as * Message originally to xxxxxx where xxxxxx is the destination user of the Fido echomail message. POM If set to ON, all requests to the listserver, such as subscription, unsubscription, etc, will be forwarded to the PostMaster, who will, in these cases of Local Lists, be considered the List Owner. .. [34B] Flags 3 These options define the behavior of other gateway servers available in the system. PKT FAX FIX NTY MOD PKT Gateway Pkt to Pkt active FAX Fax gateway active FIX Tic FileFix-echomail gateway. Search for file search requests addressed to user "FileFix". NTY if ON, filefix notification will be sent via netmail instead of in the echomail the request came from. MOD If the list is LOCal, the Postmaster is able to use the SUBSCRIBE, UNSUBSCRIBE and SET commands for any other user, making the list moderated. The syntax must be: SUB LISTSNAME user@domain Where user@domain must be the real email address of the user to be subscribed, on this example. .. [540] Welcome file Name of text file, located in \MG\AREAS, that contains the information sent to users right after their subscription request is accepted by MailGate. This option only works for LOCal lists. .. [541] Query file Name of text file sent to users in response to the QUERY command, sent to the listserver. This option only works for LOCal lists. .. [542] Signature Text file appended to all messages broadcasted from the list. .. [543] Get paths Text file name,ith extension .GET, that contains the list of subdirectories that will be scanned during a search of file for the GET listserver command. .. [544] File Server LOCal lists may maintain a subdirectory, where files are stored and possibly sent to some of the subscribed users, those who have the AFD (automatic file delivery) flag set to ON in their configuration. This will only be possible if the FIL flag is also ON in flags 2. .. [350] User Domain UUCP User that is subscribed on this current list, and therefore, entitled to send and/or receive mail from this list. .. [351] User Name Name of the user subscribed on the list. This entry is optional, and is related only to the complete name of the user that may accompany the user@domain address. For example, "Clovis Lacerda" can be configured to go together with the UUCP address. If this entry is blank, only the UUCP domain will be used and the TO: line will be To: clovis@ear.anpe.br, but if the name is configured here, the To: line would become To: Clovis Lacerda . .. [352] Flags User flags that define some characteristics of his subscription. NML - No Mail. If set to ON, mail in distribution will not be sent to the user. The user is still subscribed and can send mail. CEL - Conceal. One of the options from the Listserver. If ON, the address will NOT be sent to any user issuing the REVIEW command. ACK - Acknowledge. If ON, the user will receive a confirmation receipt for any message sent to any List. REP - Repro. If ON, a copy of a message sent for distribution to any List will be forwarded to the original poster VIP - VIP User. Set only by the postmaster. If ON, the user may request files with the GET/SEND Listserver command AFD - Automatic file delivery. Every time a new file is released by the system, the user will automatically receive a copy of it. FUI - File update information. Every time a new file is released by the system, the user will receive a notification notice. DIG - This subscribed user is set to receive mail in DIGEST format. .. [360] Group Name Name of message group. Each group can hold an unlimited number of echomail areas. .. [361] Group Number Number that defines the group. .. [362] Security Security level of user when using the functions of MGSETUP. This will be considered when writing, reading and maintaining the message base. .. [363] Flags Not available. .. [370] Area group Message group this area belongs to. .. [371] Read level Security level a user need to have to be able to read messages in this area. .. [372] Write level Select the level to write messages in this area. .. [373] Sysop level Select the sysop level to maintain this area. .. [374] Main Node Main Fidonet node that manages this message area. .. [375] Origin Line Edit the origin line that will be used when configuring message areas in the Area Manager. .. [376] Tear Line Tearline appended to messages generated in this area. .. [377] Area Type Defines the message base type used for this area. - Hudson base - JAM base (not available in this current version) - Squish base (not available in this current version) - SyncNet base (not available in this current version) .. [378] Echomail Toss ON, toss echomail directly. OFF, use fake downlink This flag is important and defines the operation mode MG will use when processing echomail. If the flag is ON, MG will toss and scan echomail directly from the message area. If OFF, MG will create PKT files that will need to be processed by an external echomail program. In this current version of MG, the internal echomail tosser is not available yet, so the only operation available is through the fake downlink. MG will create PKT files From: Fake Node To: Main Node. For example: If the Main Node of this area is 4:808/2, MG will look for this node in the configuration, and it must be either the Primary BBS or the Secondary BBS. If it is the Primary BBS, MG will use the Primary Gateway as the fake link node. Assuming that the Primary Gateway is 4:808/2.1, PKT will be generated by MG as being From: 4:808/2.1, To: 4:808/2. In this case, the external echomail utility must be configured as follows: The message area defined here must also be defined in the echomail utility. The main node of that area must be 4:808/2 The node 4:808/2.1 must be one of the downlinks of such area. This way, when the echomail utility is executed in TOSS mode, it will process the PKT file as if it had arrived in the system, sent by node link 4:808/2.1. The message will be tossed to whatever message base was defined, and forwarded to as many downlinks as the echomail area is configured to deal with. PKT files are generated whenever MG processes Newsgroups, List mail, FileFix reports, and so on. .. [379] Echo/Net Area ON means that the area is echomail, OFF means that the message area is available for one of the local netmail AKAS. .. [37A] News Name Use the name of echomail area as the name of the Newsgroup field, when creating/importing new areas into the system. .. [37B] List Name Use the name of echomail area as the name of the Listgroup field, when creating/importing new areas into the system. .. [380] PostMaster User who is subscribed to remote lists. This entry is mandatory if remote lists are being converted to echomail. .. [381] List Userbase Used only for LOCal lists. This file is mandatory, since it will store the names of all users who subscribed to the local listserver. .. [382] Welcome file Name of text file, located in \MG\AREAS, that contains the information sent to users right after their subscription request is accepted by MailGate. This option only works for LOCal lists. .. [383] Query file Name of text file sent to users in response to the QUERY command, sent to the listserver. This option only works for LOCal lists. .. [384] File Server LOCal lists may maintain a subdirectory, where files are stored and possibly sent to some of the subscribed users, those who have the AFD (automatic file delivery) flag set to ON in their configuration. This will only be possible if the FIL flag is also ON in flags 2. .. [385] Fax Base Phone number or Fax database file that contains the fax destinations that will receive a copy of mail from this Area. .. [386] Fax Grade Fax Grade used to identify all Fax messages originated from this message area. .. [387] Distribution Applied only to newsgroups. This field defines the range of the distribution of this newsgroup area. .. [388] Folder Flag 2 Flags that define the behavior of UUCP gateway, as explained in the help of an individual echomail area, in the Areas Menu. .. [389] Folder Flag 3 Flags that define the behavior of general gateway, as explained in the help of an individual echomail area, in the Areas Menu. .. [38A] Signature Text file appended to all messages broadcasted from the list. .. [38B] Get paths Text file name,ith extension .GET, that contains the list of subdirectories that will be scanned during a search of file for the GET listserver command. .. [38C] Fido Links List of Fidonet node links for the current echomail area. .. [38D] News Links List of UUCP node links for the current newsgroup area. .. [370] Area group Message group this area belongs to. .. [371] Read level Security level a user need to have to be able to read messages in this area. .. [372] Write level Select the level to write messages in this area .. [373] Sysop level Select the sysop level to maintain this area. .. [374] Main Node Main Fidonet node that manages this message area. .. [375] Origin Line Edit the origin line that will be used when configuring message areas in the Area Manager. .. [376] Tear Line Tearline appended to messages generated in this area. .. [377] Flags 1 Area flags, as defined and explained in the help of an individual echomail area, in the Areas Menu. .. [398] Execute! Update the message folders according to the current status defined in this configuration. .. [380] PostMaster User who is subscribed to remote lists. This entry is mandatory if remote lists are being converted to echomail. .. [381] List Userbase Used only for LOCal lists. This file is mandatory, since it will store the names of all users who subscribed to the local listserver. .. [382] Welcome file Name of text file, located in \MG\AREAS, that contains the information sent to users right after their subscription request is accepted by MailGate. This option only works for LOCal lists. .. [383] Query file Name of text file sent to users in response to the QUERY command, sent to the listserver. This option only works for LOCal lists. .. [384] File Server LOCal lists may maintain a subdirectory, where files are stored and possibly sent to some of the subscribed users, those who have the AFD (automatic file delivery) flag set to ON in their configuration. This will only be possible if the FIL flag is also ON in flags 2. .. [385] Fax Base Phone number or Fax database file that contains the fax destinations that will receive a copy of mail from this Area. .. [386] Fax Grade Fax Grade used to identify all Fax messages originated from this message area. .. [387] Distribution Applied only to newsgroups. This field defines the range of the distribution of this newsgroup area. .. [388] Folder Flag 2 Flags that define the behavior of UUCP gateway, as explained in the help of an individual echomail area, in the Areas Menu. .. [389] Folder Flag 3 Flags that define the behavior of general gateway, as explained in the help of an individual echomail area, in the Areas Menu. .. [38A] Fido Links List of Fidonet node links for the current echomail area. .. [38B] News Links List of UUCP node links for the current newsgroup area. .. [390] AREAS.BBS Import areas configuration from an AREAS.BBS compatible text file. .. [391] MESSAGES.RA Import areas configuration from Remote Access 2.00 or compatible. .. [392] MGROUPS.RA Import groups configuration from Remote Access 2.00 or compatible. .. [3A0] Message Base This will give the user access to the netmail folder and the local message base. Users may read, write and maintain the message areas. .. [3A1] File Name Name of file that will be sent in distribution in the selected TIC Area. Type ENTER when this entry is blank to have a list of all files available in the subdirectory defined in the configuration of the TIC Area. .. [3A2] Only Nodes If ON, MG will not import the area names, but will only update the current areas by importing the Fidonet node links from each area in AREAS.BBS. .. [3A3] Overwrite config MG may update the current configuration by adding only newer areas found in AREAS.BBS, or overwrite the current configuration by importing all areas from AREAS.BBS. .. [3A4] Execute! Update the message folders according to the current status defined in this configuration. .. [3B0] MESSAGES.RA Import areas configuration from Remote Access 2.00 or compatible. .. [3B1] CONFIG.RA Full path/name of CONFIG.RA configuration file. .. [3B2] Overwrite config MG may update the current configuration by adding only newer areas found in AREAS.BBS, or overwrite the current configuration by importing all areas from AREAS.BBS. .. [3B3] Execute! Update the message folders according to the current status defined in this configuration. .. [3C0] MGROUPS.RA Import groups configuration from Remote Access 2.00 or compatible. .. [3C1] Overwrite config MG may update the current configuration by adding only newer areas found in AREAS.BBS, or overwrite the current configuration by importing all areas from AREAS.BBS. .. [3C2] Execute! Update the message folders according to the current status defined in this configuration. .. [3D0] AREAS.BBS Import areas configuration from an AREAS.BBS compatible text file. .. [3E0] 1 - Listserv Reply Message sent to UUCP users after they send mail to one of your local Lists. This is a confirmation receipt that may or may not be sent to the original sender, providing he is subscribed on the list (the only way he has to send mail to your lists), and that he has the ACK flag set to ON in the "Flags" option of his configuration in the user database of the List in question. The ACK option can also be changed by the user by sending the "SET Listname ACK" command to the listserver. In the body of the message, you can use special characters that will be substituted by some information about the original message sent to the list. Use %D for the date, %S for the subject and %L for the name of the list. Below follows an example: * Automatically generated by MailGate Dear user: Your message was sent to %L on %D, with subject "%S". Regards PostMaster .. [3E1] 2 - Listserver Reply If a user tries to send mail to a list he is not subscribed on, the system will send a warning message. Generally, this message should say that the message was discarded and the procedures that should be taken for the user to be subscribed on the list. Below follows an example: * Automatically generated by Mailgate Warning: You cannot send messages to %L because you are not subscribed on this list. To subscribe, send message to listserv@ear.anpe.br, and in the body of the message, write: subscribe %L Your message was sent on %D, with subject "%S". .. [3E2] 3 - UUCP Fax Reply Users on the Internet can also use your Fax server and send faxes the same way users do with netmail. Your Fax server can be reached at the address Fax@mydomain, and in the subject line of the message, the syntax should be exactly the same as used with netmail. You may choose to work with the Fax@mydomain user or any other one. In any case, this user must be configured in the UUCP VIP users Database, where the user name is "fax" and the node number is one of your local BBS node numbers. If you wish to provide Fax capability to other locations, you can add as many "fax" users as you wish, supply different names for the UUCP user (fax1@mydomain, fax2@mydomain, etc), and different Node numbers, corresponding to the BBS systems these fax messages will be sent to. Since the "fax" user will not be allowed to send netmail to the UUCP gateway, you will need to set to ON the UUCP flag in each VIP UUCP/Fax entry in the UUCP VIP Database. Below follows an example: * Automatically generated by MailGate Dear user: Your message was sent to the Fax Server. You will be receiving a Fax report of the transmission as soon as possible. Regards PostMaster .. [3E3] 4 - Not in Node Warning message sent to a user who attempted to send netmail to the UUCP gateway, but whose node number was not found in the nodelist. Below follows an example: * Automatically generated by MailGate Warning: Your system is not allowed to gate netmail to Internet through our system because it is not listed in our Nodelist. Please, contact the Sysop before attempting to try it again. Netmail information: Date : %D Subject : %S To User : %L Regards Sysop. .. [3E4] 5 - Syntax UUCP If a user attempts to send a netmail to the UUCP gateway and it does not follow the right syntax, the system will reply with a warning message, explaining how to proceed next time. You may use a specific message to be replaced when the reply is sent. %D - Date %S - Subject %L - Destination UUCP user Below follows an example: * Automatically generated by MailGate You tried to send a netmail through the UUCP gateway node but it does not follow the right syntax. Read the help message below and try it again. Netmail information: Date : %D Subject : %S To User : %L Regards, Clovis Lacerda - How to send netmail to Internet - Send a netmail to uucp in the address 12:12/2, and, in the very first line, write: TO: body of message. .. [3E5] 6 - Long Fido Name This warning message is sent to any user who attempts to use the gateway of netmail between Primary and Secondary networks, but whose name is too long and the system is unable to add his node number in the From: field of the netmail. This is in agreement with the technical standards of the gateway of netmail. Below follows an example: * Automatically generated by MailGate Warning: This netmail could not be gated because your name is too long to accept the appending of your origin node. Contact your sysop. Netmail information: Date : %D Subject : %S To User : %L Regards, Clovis Lacerda .. [3E6] 7 - Node not found Warning message sent to a user who attempted to send netmail to the Fidonet or Fax gateway, but whose node number was not found in the nodelist. Below follows an example: * Automatically generated by MailGate Warning: This netmail could not be gated because the destination node is not in our nodelist. Please, contact your sysop. Netmail information: Date : %D Subject : %S To User : %L Regards, Clovis Lacerda .. [3E7] 8 - UUCP Receipt This is the confirmation receipt sent back to a user after the system had successfully processed a netmail to the UUCP gateway. Below follows an example: * Automatically generated by MailGate Dear user, The following message was successfully sent to Internet from our system. Netmail information: Date : %D Subject : %S To User : %L Regards Sysop. .. [3E8] 9 - Fido Receipt This is the confirmation receipt sent back to a user after the system had successfully processed a netmail to the Primary-Secondary Fidonet gateway. Below follows an example: * Automatically generated by MailGate Dear user, The following message was successfully sent through the gateway from our system. Netmail information: Date : %D Subject : %S To User : %L Regards Sysop. .. [3E9] A - Fido Footing This message is appended in all netmail that is sent through the Primary/Secondary Fidonet gateway. Below follows an example: ------------------------------------------------------- Netmail from RBT - Rede Brasileira de Tele-informatica ------------------------------------------------------- .. [3EA] B - UUCP Footing This message is appended in all netmail that is sent through the UUCP gateway. Below follows an example: -------------------------------------------------------- Tropical Reefs, Inc - Tropical Reefs BBS clovis@ttbbs.ax.apc.org -------------------------------------------------------- .. [3EB] C - Error Node Warning message sent to a user who attempted to send netmail to MGSERVER, but whose node number was not found in the nodelist. Below follows an example: * Automatically generated by MailGate Sorry, but your request could not be processed because your node was not found in our nodelist. If you have any questions, please send mail to Clovis Lacerda Address: 12:1280/1 or 4:808/2 In regard to your Message: Date : %D Subject : %S To User : %L .. [3EC] D - Error File Warning message sent to a user who attempted to send netmail to MGSERVER with the SEND command, but the text file was not found in the "TXT Path". Please refer to the "Fido Server Path" option for details on the use of the MGSERVER function. Below follows an example: * Automatically generated by MailGate Sorry, but the file you requested was not found in our directories. The list of available files goes below: (SEND command) HELPME ESTAT MG The list of available files for request (ATTACH command) MG021.ZIP - Newest version of MailGate The list of available files for Faxing (FAX command) INDICES - Indices economicos do dia EVENTOS - Eventos da semana In regard to your Message: Date : %D Subject : %S To User : %L .. [3ED] Next Menu Another set of text files. .. [3F0] 1 - Fax Error Warning message sent to a user who attempted to send a netmail to the Fax server, but was rejected by the system for one of many reasons. Please refer to the "Fax Mail" menu for details. Below follows an example: * Automatically generated by MailGate Error trying to send a message to the Fax Server. The subject of this reply will give you an idea of what went wrong. For further details, please contact the sysop. Depending on the configuration of the system you are using to send your mail, it may operate under one of these situations: 1 - Any user may send Fax messages, to any phone number; 2 - Only users listed in the VIP nodelist may send messages to any phone number or to Fax databases and 2.1 - Users not found in the VIP nodelist may only send faxes to local phone numbers, according to the configuration; 2.2 - Users not found in the VIP nodelist cannot send fax messages. Regards, Clovis Lacerda .. [3F1] 2 - UUCP Auto reply If a VIP UUCP user cannot reply to his mail, the system provides a way by which any UUCP mail received to him will be automatically replied. This is useful if a VIP user of your system is away and can only read his mail after he comes back. Meanwhile, every user who sends mail to him will be notified of the fact. Below follows an example: * Automatically generated by MailGate Dear %L, I cannot read your message now because I'm out of town. As soon as I read it, I will send you the reply. Yours virtually, %S .. [3F2] 3 - UUCP TIC MailGate allows your system to automatically hatch files to subscribed users of your local Lists, provided that the Lists you want to have this function activated have the FIL flag set to ON in the "Flag" option of the "Edit UUCP Areas" configuration, found in the "UUCP Config" Menu. The FILES subdirectory must exist inside the subdirectory of the List Area, and any new file found in this subdirectory will be sent to all List members who have the AFD flag set to ON in their individual subscriptions. If a member of a list has the FUI flag set to ON, he will be notified of new files in the list. New files are those found in the FILES.BBS file, in the FILES subdirectory, but not in the FILES.DUP, which is updated in the directory of the list. In this text message, you may use the special reserved words: %S - File name %L - List Name Members of list who have the FUI flag set to ON will be notified of new files by the text message configured in this option. Below follows an example: * Automatically generated by MailGate Dear user: This file is now available on List %L File: %S You may request it with the GET command to the Listserver. Regards PostMaster .. [3F3] 4 - RAID Help Message sent to netmail request to the RAID user, acknowledging the %HELP command. Below follows an example: This is the list of commands available to you. + Connect an area - Disconnect an area %HELP or %H This help message %LIST or %L To request a list of areas available to you %QUERY or %Q List of available areas to which you are connected %UNLINKED or %U List of available areas to which you are not connected %PASSWORD or %P Change your AreaFix password %-ALL Disconnect all areas %+ALL Connect all areas %NOTIFY=[On/Off] Turn the notify function on/off %MESSAGE=[On/Off] Turn the message function on/off %TICK=[On/Off] Turn the TICK file option on/off %STATUS Status report with configuration %INACTIVE Temporarily turn off all areas %ACTIVE Turn inactive areas back on %FROM [address] Remote maintenance for other nodes %RESEND file Resend a TIC file that has been already processed .. [3F4] 5 - BAD UUCP This is useful in case a non VIP UUCP user attempts to send a netmail to the UUCP gateway in which the destination is a bad UUCP user, as listed in the MGUBAD_*.LST. Please refer to the "Bad UUCP" option for details. Below follows an example: * Automatically generated by MailGate Dear user, You tried to send a message to a destination system that is not allowed in our system. Your mail has therefore been rejected. Please keep in mind that messages to the following users will not be sent by the system: listserv, archie, ftpmail, mailserv Netmail information: Date : %D Subject : %S To User : %L Regards Sysop. .. [3F5] 6 - UUCP Warning This message is sent to a remote UUCP user who sent a UUCP message to a destination user who was not found in your system. For example, the destination was a non VIP UUCP user, the message came in the standard format of mail to a non VIP UUCP user but the destination node was not found in the nodelist or the system only accepts mail to VIP users. Below follows an example: * Automatically generated by MailGate Dear user, The destination user was not found. Your message was discarded and sent to the postmaster. User not found: %L Subject of your mail: %S Original Date: %D Yours virtually, Postmast@ear.anpe.br .. [3F6] 7 - Fido Server This will allow you to edit the *.TXT files that the Fido Server of MailGate has available for the MGSERVER SEND command and for the Netmail and Echomail automatic distribution system. .. [3F7] 8 - MSG Server This will allow you to edit the *.CTL files that the Fido Server of MailGate has available for the NetMail automatic distribution. .. [3F8] 9 - PKT Server This will allow you to edit the *.CTL files that the Fido Server of MailGate has available for the EchoMail automatic distribution. .. [3F9] A - Listserver files This will allow you to edit the text files that the UUCP Listserver of MailGate has available. These files are part of the set of commands that the Listserver uses to interact with UUCP users. .. [3FA] B - Fax file request Text files available for netmail requests sent to MGSERVER, after the user issues the FAX command. These files will be forwarded to the fax server for later delivery to the phone number specified by the requesting user. Please refer to the MGSERVER help for details. .. [3FB] C - UUCP Request files Text files that are available for Internet users to automatically request. For example, if there is a text file called "help", any mail to user help@ear.anpe.br will be automatically replied, and file "help" will be the body of the message. Multiple files may also be sent to the requesting user, for example, files help, help.1, help.2, help.a, etc will be sent as replies to the message sent to help@ear.anpe.br. This option may be useful when making available multiple parts of an uuencoded file. .. [3FC] D - UUCP Aliases files Text files that contain lists of email addresses, used for fast Internet mailing. For example, if a user sends a netmail to the UUCP gateway, addressed to: alias, MG will first look for the file "alias" in this directory, and if found, the message will be forwarded to all users listed in this file. .. [3FD] E - Fido Request files Text files that are available for FidoNet users to automatically request. For example, if there is a text file called "help", any netmail to user help, at one of the local nodes of the system, will be automatically replied, and file "help" will be the body of the message. Multiple files may also be sent to the requesting user, for example, files help, help.1, help.2, help.a, etc will be sent as replies to the original message. This option may be useful when making available multiple parts of an uuencoded file. .. [400] Run-Time Options Several flags are provided for the system to operate according to your specific needs. They are used to enable or disable almost all functions of MailGate. Once configured, they are used as default settings for the operation of MailGate. They can, however, be overridden by the DOS command line. Run MailGate using one or more switches as explained in the ON-LINE Help. If you run MG -? you will get the list of switches. .. [401] Edit Fax Users Menu where your Fax VIP users will be configured. .. [402] Fax Directory This directory is used by the MailGate FAX manager. It will contain some subdirectories that are automatically created by MailGate. The Database files with the Fax VIP users and the Fax Phone book are stored here. The Fax text messages (*.FAX) and control files (*.FCX) are stored in a subdirectory called HOLD. The TXT subdirectory, which must be manually created, stores the TEXT messages that may be requested to be FAXed to a remote user. Please refer to the FAX command in the MGSERVER functions. Every time MailGate processes UUCP or Fido netmail addressed to the Fax manager, the messages are sent to HOLD. If the Fax manager is activated, in the "Run-Time options" or by means of a +X DOS switch when running MailGate, this mail will be sent as Fax messages. Processed mail will be moved to the OLD subdirectory and will remain there until you decide to delete them. Fax mail will be moved from the HOLD directory to the OLD directory when: - The Fax was successfully sent to the destination. This can only be verified if the Fax control file was updated by the external Fax-Log utility. MailGate provides one such utility to be used with a Fax program we recommend. Please refer to the FAX.DOC file. - The number of attempts to send a Fax message exceeded the maximum number of tries that are allowed by MailGate. This value is set in the Fax configuration menu of MailGate. This can only be processed if the "Ext LOG Program" is being used by the system. If the Fax-log utility does not exist, you will have to manually process the maintenance of your Fax mail in HOLD, since MailGate will continue to try to send them, even if they have already been sent. .. [403] DataBase This will give you access to the Configuration Menu of the Fax phone list Database. If you type ENTER with this entry in blank, you will receive a list of all existing database files in the system. In each of these files, you will enter as many phone numbers as you wish. For example, suppose that you choose HOTELS to edit. You will include the phone numbers of hotels. Each time a Fax message is sent with a subject line containing HOTELS, the system sends this Fax message to all phones listed in the HOTELS database. If the Fax VIP flag is ON in the Run-Time Menu, only Fax VIP users will be able to access the Fax phone books. Below is an example of what a Fax VIP user has to do to have a Fax message delivered to all hotels found in the HOTEL Fax database: From: John Brown, 12:1280/7 To: Fax, 12:1280/1 Re: -psecret hotels ------- This is a test .. [404] FAX Program This is the main Executable program that delivers your Fax messages. You can enter the name of the executable file or the name of a batch file that runs it. Both files must be located either in the current directory or in the PATH of your operating system. MailGate does not have the internal capacity of sending Fax message over the phone, it needs another program to do it. .. [405] Command Line This is the command line passed to the Fax program when MailGate exits to run it. It is the same as if you had executed the Fax program from DOS with a command line. MailGate uses two special characters that are replaced during the execution by the name of the text file to be sent as Fax and the phone number that must be dialed. In the command line, use % for the file name and @ for the phone number. .. [406] Ext LOG Program MailGate needs a special utility to process the Logging of the Fax transmissions, executed by the external Fax program you have already configured. Different Fax programs will surely produce different styles of transmission logging. This utility must read the transmission log of your Fax system and then, update the *.FCX Fax control files of the messages that were processed by the Fax server of MailGate. This is needed since MailGate has to keep track of the Fax transmissions, to provide a reply to the original sender of the Fax transmission status, and to avoid sending Fax messages more than once. MailGate provides one such Fax log utility. This program is important for the Fax server since it will work as a supplier of information to MailGate about the operation of your Fax system. Please refer to the FAX.DOC file for details. MailGate calls the External Fax logging program and passes the name of the Fax control file as the first parameter in the DOS command line. What the External Fax logging utility has to do will be detailed below, with an example of a Fax control file that MailGate has available for all individual Fax Messages. A Clovis Lacerda 1280/1 12:1280/7@rbt.org 341-4241 65740300.FAX Date Time Phone number Message Text Pgs Logon Status 04-03-94 07:00:00 341-4241 65740300.FAX 1 00:00 No Ans The first line includes the Fax grade of the Fax message. The second line contains the name of the user who sent the Fax message. The third line contains the node number of the destination system that received the Fax. The fourth line contains the node number of the user who sent the Fax. The firth line contains the name of the UUCP user who sent the Fax, if any, otherwise it will be left empty. This field is needed for MailGate to send the status of the Fax transmission back to the original UUCP user. The sixth line contains the phone number to which the Fax message will be sent, or it may contain the name of the Fax Database file from which MailGate will retrieve phone number for multiple transmissions. The seventh line contains the name of the Fax file that will be sent. It may be a text file, generally from a netmail or an email, or a binary file, that came attached to a netmail addressed to the Fax user. The eighth line is hard-coded, and contains the status information for the Fax transmissions. After this line, your External Fax log utility must update the control *.FCX file, including a line every time a transmission is attempted. .. [407] Max tries Maximum number or attempts to send a Fax message before giving up. This can only take effect if you have configured an available Fax logging utility. MailGate will scan all Fax control files, *.FCX files located in the Fax HOLD directory, and control the number of attempts to send a specific Fax message. This is how MailGate controls Fax messages: A Clovis Lacerda 1280/1 12:1280/1@rbt.org 341-4241 65740300.FAX Date Time Phone number Message Text Pgs Logon Status 04-03-94 07:00:00 341-4241 65740300.FAX 1 00:00 No Ans These lines have already been explained in the "External LOG" option of this menu. After the eighth line, which is the hard-coded status line supplied by MailGate, the system will count the number of subsequent lines, which are supposed to be from the Fax transmission log, and, after reaching the maximum number of configured attempts, MailGate will back up the Fax message and send the *.FCX control file back to the original sender, as a confirmation receipt of the Fax transmission. This is only done if your system is configured with the Fax External Log processor, otherwise you will have to control all *.FCX files so as to avoid having MailGate send them more than once. .. [408] Phone Grid Users that are not configured in the Fax VIP nodelist will have limited access to Fax messages. This will, of course, depend on how the Fax flags were configured in the Run-Time Menu. If you did not allow any user to use your Fax Server, that is, if you set the Fax VIP flag to OFF in the Run-Time Menu, non-Vip users can not send Fax messages. They may only do so if the "Local Fax" flag is set ton ON in the Run-Time Menu. If this is the case, Mailgate will only accept Fax messages from non-Vip users if the subject of their netmail contain phone numbers that conform to the Phone Grid. This is done to limit the range of phone numbers a Fax transmission can send mail to. For example, if the Phone Grid is XXX-XXXX, only phone numbers in this format will be processed, otherwise, they will be discarded and a warning message will be sent to the original user. If Fax VIP users want to overlap this restriction, they must supply their password in the subject line, before the destination Fax phone number, and using the "-p" option. For example: Fax netmail from a VIP user whose password in the Fax Vip nodelist is "secret", and who wants to send a Fax to a long distance phone number: From: John Brown, 12:1280/7 Re: -psecret 081-3261234 ------- This is a test MailGate will first check if the user and his node is configured in the Fax VIP Nodelist. If so, the next step is to check if the "-p" command was issued in the Subject line. If so, the password will be matched with the one from the user configuration in the Fax VIP Nodelist. If the password is validated, MailGate will accept the Fax message and send it to the Fax HOLD directory as two files, one is the message itself, the other one is the *.FCX Fax control file. The Fax grade will be taken from the user configuration. If the Fax message does not have a password, the system will consider the original message as being sent by a non VIP user, and as such, will apply the restrictions set in the system. .. [409] FAX Nodelist ID This letter is used to name the Fax Database files of the system. The files used by the Fax system are MGFAX_*.DAT and MGFAX_*.NDX. * is replaced by the Fax ID. The first file is the Fax VIP Nodelist and the second one contains the indexes of the first one. .. [40A] Local Fax Grade Non VIP users will have their Fax messages assigned with this Fax grade letter. Fax VIP users can have their own Fax grades, as configured in the Fax VIP Nodelist. Fax Grades are used to force MailGate to send some of the Fax messages only during certain times of the day, and it is useful if you want to control what kind of Fax messages your system will give priorities to, or what time of the day these faxes will be sent. For Fax messages to be sent by the system, MailGate has to run with the +X switch, followed by the Fax grade, or list of grades, that will be sent during this execution. Please run MG ? for details. .. [40B] Fax Banner You may include a front page in all Fax messages. Just create a file called BANNER.FAX and place it in the "FAX Path". Below follows a sample file for the Fax front page: ÛßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßÛ Û ±ÛÛÛÛÛÛÛ ±ÛÛÛÛÛÛÛ ±ÛÛÛÛÛÛÛÛ Û Û ±ÛÛ ±ÛÛ ±ÛÛ ±ÛÛ ±ÛÛ Û Û ±ÛÛÛÛÛÛÛ ±ÛÛÛÛÛÛÛÛ ±ÛÛ Û Û ±ÛÛ ±ÛÛ ±ÛÛ ±ÛÛ ±ÛÛ Û Û ±ÛÛ ±ÛÛÛ ±ÛÛÛÛÛÛÛÛ ±ÛÛ FAX Û ÛÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÛ Û Rede Brasileira de TeleInform tica Û ÛÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÛ Tropical Reefs BBS - Sysop: Clovis Lacerda Phone: 081-341-4241 Recife - PE - Brazil ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ .. [410] Netmail to Fax mail If ON, the system will look for netmail addressed to one of the local nodes and destination user "FAX". When found, the netmail will be checked for proper syntax and system restrictions and sent to the Fax Manager for later delivery. .. [411] Process Fax Server This option will force MG to send all waiting Fax mail every time it is executed. If OFF, MG will only deliver fax if the -X switch is passed to MG in the DOS command line. Please run MG /? for details. .. [412] Fax Vip If ON, only users found in the Fax Nodelist may send mail to the Fax manager. The user has to issue a valid password in the subject field of the netmail, otherwise the message will be rejected. Please refer to the "Fax Mail" Menu for detailed help on the syntax. If this option is set to OFF, any user may send Fax mail, including long distance calls. For this reason, be very careful when configuring your Fax Manager. .. [413] Local Fax If ON, Local Faxes will be allowed to be sent, even for users not found in the Fax VIP database. Any user sending netmail to the Fax Gateway may have their mail sent to local phone destinations, and the Fax number will be checked for validity against the "Phone Grid". Fax password is not required. .. [414] Fax Receipt If ON, MailGate will send a confirmation receipt to the user who sent netmail to the Fax server. The text message used is the same that the MSG server uses and can be customized in the "Text FiLes" Menu. .. [415] Process Fax Log If ON, MailGate will execute the Fax logging program that was configured in the "Fax Mail" Menu. For the Fax server to work, your system will need to run a Fax delivering program. Each different Fax program has its own way of logging the operation, especially the transmission of the Fax messages, which is of great importance for MailGate to be able to update every Fax message found in the HOLD directory. This update is needed because MailGate has to know if a Fax messages was correctly sent, how long it took during transmission, the number of pages. After Fax is sent by your Fax program, a Log processing utility has to be executed. This program will process the LOG file generated by the Fax program, locate the correct entry for the recent Fax transmission, and then update the .FCX control file of the Fax message in the Fax HOLD directory. MailGate comes with one Log utility to be used in conjunction with one specific Fax program. Please refer to the "Fax Mail" Menu and to the FAX.DOC file for details. The utility that is provided must be located in the main path of MailGate. If this option is set to OFF, you must provide a way to update your FAX mail in the HOLD directory, otherwise MailGate will continue trying to send them, even if they have already been sent. .. [416] FaX error Some Fax programs need to know the errorlevels they exited after operation. If this happens with the Fax program you are using with MailGate to send your Fax messages, you will need to force Mailgate not to exit with its own internal errorlevels, but rather, with the one provided by your Fax Program. Set this to ON if you really need to work with your Fax program errorlevel. Nevertheless, MailGate will execute the customized exit batch files after completion. .. [417] Fax Files If ON, MG will look for files attached to netmail messages sent to the Fax user, and if found, they will be forwarded to the Fax server for delivery. This is useful is you do not only want to send text messages to the Fax server. .. [420] User Name Name of the user, as it will be used in his netmail or in the From: field of the RFC-822 header, in case the user sends his Fax from the Internet. .. [421] Net or UUCP If ON, the user is in the Fidonet domain, otherwise, he is a user on the Internet. VIP Fax users may be either from the Internet or from Fidonet. Your system may allow Internet users to have full access to the Fax manager. The rules are the same that apply to a Fidonet user. .. [422] Session Pwd Password to be used whenever this user wants to have privileges of a VIP user. This is required to access the Fax phone Databases and to overlap the restriction set by the Phone grid for long distance Fax transmission. This password is always issued in the subject line of the netmail, following the "-p" command. Example: Re: -psecret 00-1-305-222-2222 If "secret" is the password as configured in this option, the Fax message from this user will be processed. .. [423] FidoNet Node Node that this user will send and receive messages from. The node number is used to validate the origin of the netmail, and also to be used as the return node when the system has to send a status message back to the user. .. [424] GraDe Fax Grade used in all Fax messages from this user. Fax Grades are used to differentiate and control the transmission of the various levels of Fax messages processed by the system. If the Fax Grade of this user is "S", his Fax mail will only be sent to the destination if Mailgate is run with the following command line: MG -XS -X is the switch used to activate the transmission of Fax mail, and S is the fax grade of the messages that area allowed to be transmitted during this session of MailGate. Please run MG ? for details. .. [425] FlaGs Flags used to determine the behavior of the netmail and subscription of this VIP Fax user. HLD - Hold. Netmail is sent only when destination node makes the call. DIR - Direct. Directs the netmail to the destination. CSH - Crash. The system will force a call to destination node. KIL - Netmail will be deleted after sent. .. [430] Fax Grade Fax grade used to determine the identification of all Fax messages processed from the current user. Run MG ? for details on the use of the -X switch for transmission of Fax graded messages. .. [431] Name Name of database entry. It is used only for information. .. [432] 1 - Information General description about current entry. .. [433] 2 - Information General description about current entry. .. [434] 3 - Information General description about current entry. .. [435] Voice phone Phone number voice messages will be sent to. (not implemented yet) .. [436] Fax phone Phone number fax messages will be sent to. .. [440] Alias ID MailGate uses a database to store the names of the ALIAS users used in your system. There are two files in the "Nodelist Path", named ALIAS_*.DAT and ALIAS_*.NDX, where * is the Alias ID configured here. .. [441] Edit Aliases This menu will allow you to edit the ALIAS users of the system. .. [450] To: User Name Name of the user to whom netmail is sent. This will indicate that a message has reached an ALIAS user, and thus, should receive special treatment. For example, if an incoming netmail is addressed to "College", and if "College" is an alias user, the netmail may be forwarded to an Internet destination, for example, admin@university.edu, depending on how the alias user was configured. .. [451] To: Node Number Netmail sent to this node will be considered mail to an ALIAS user if the "To: User Name" also matches with the one configured in the "To: User Name" of this Menu. A valid alias user must have these two entries matching with the netmail information. The destination user and node of the netmail are used to check whether the user is a valid alias of this system or not. .. [452] UUCP/Fax/Net Name of the destination user to whom the netmail will be forwarded. If the two restrictions set before, the To: User Name and the "To: Node Number" are successful, the netmail is confirmed to be a message to an ALIAS user, and therefore, will be processed as explained below: Suppose that the To: User Name is "Internet" and the To: Node Number is 12:1280/1. If the To: UUCP/Fax/Net is clovis@ear.anpe.br and the UUP flag is set on, the netmail will be sent to the UUCP gateway, destination clovis@ear.anpe.br. In other words, Mailgate treated the incoming netmail as if it had been sent to the UUCP Gateway. There are two variations for this system that occur when flags 1ST (first) or LST (last) are active. Suppose that 1ST is on and that UUCP/Fax/Net is @ttbbs.ax.apc.org (yes, there is no username before the @ sign). The 1ST flag forces MG to add the To: user name of netmail to the above Internet address. If the netmail were addressed to: John Green, the final UUCP destination would be john.green@ttbbs.ax.apc.org. This is very important if you want to dinamically re-route and forward netmail in transit through the Internet, directly to the domain of the system that would receive the same netmail via the normal Fidonet routing system. If the active flag is LST, for the same situation as above, and for a UUCP/Fax/Net address like ttbbs.ax.apc.org!, the final UUCP address would be ttbbs.ax.apc.org!john.green. Forwarding to the FAX server: From: John Green, 12:1280/7 To : International Hotel, 12:1280/1 Re : xxxxxx ------ This is a test If the FAX flag is set on, MailGate will treat this netmail as if it had been sent to the "Fax" user, and the procedures are exactly the same. The To: UUCP/Fax/Net entry is used as the Fax syntax, a fax phone or fax database. Finally, netmail may have the destination changed to another user+node. This is particularly useful if you travel and you want your mail routed to another user+node system. For example: From: John Green, 12:1280/7 To : Clovis Lacerda, 12:1280/1 Re : xxxxxx ------ This is a test If the NET flag is set on, the To: UUCP/Fax/Net is "Liliana Meneses" and the "Send To: Node" is 12:1280/20, the netmail will become From: John Green, 12:1280/7 To : Liliana Meneses, 12:1280/20 Re : xxxxxx ------ This is a test The original netmail will be kept "as is", and will probably be imported into your message base. It is important to note that MailGate allows one special entry in the "To: User Name field". If the character * is included (there may be multiple * entries as needed), the system will accept netmail addressed to any user at node "To: Node Number", and will forward the netmail as: 1 - another netmail, addressed to the same "To: user" or to UUCP/Fax/Net, if not empty, at node "Send To: Node"; 2 - an Internet email, addressed to UUCP/Fax/Net. 3 - a fax message, addressed to UUCP/Fax/Net. Item number 2 is very powerful, and deserves one example. Suppose you work as a Hub of a large Fidonet compatible system. Through your system pass many netmail messages. You wish to send these messages to the proper destinations using the Internet, instead of relying on a very slow and troublesome Fidonet routing. This is what could be done: System 12:122/0 is on the Internet as luca.ax.apc.org System 12:1231/2 is on the Internet as louca.ax.apc.org System 12:1230/3 is on the Internet as phbbs.ax.apc.org System 12:1270/12 is on the Internet as bahianet.com ... and so on, throughout the nodelist. This way, why not forwarding in transit netmail addressed to one of the above systems directly to their corresponding Internet domains? Assume that there is a netmail in transit From: Paul Pack, 12:1283/1 To : Ann Rice, 12:1270/12 Re : hello And also assume that there is an entry in the ALIAS database as To: User Name * To: Node Number 12:1270/12 UUCP/Fax/Net @bahianet.com Send To: Node Flags UUP 1ST In this case, "Send To: Node" has no effect. Since the first field has an "*", MG will not try to match the user name against the information from the in transit netmail. rather, only the destination node number will be validated with the "To: Node Number". After accepting this alias entry as valid, MG will check the flags, and it says that the destination is a user on the Internet, and the 1ST flag will force MG to add the destination user in front of the UUCP/Fax/Net field, resulting in a valid UUCP destination of ann.rice@bahianet.com. The From: username of the forwarded message will contain enough information about Paul Pack and his node. The system may still be used for nodes that do not have their own domain on the Internet. For example, to forward mail in transit to: 12:122/10, the netmail could be sent via 12:122/0 and consequently via luca.ax.apc.org. Just create an entry for 12:122/10 and in the UUCP/Fax/Net field, write: %f10.n122.z12@luca.ax.apc.org, and set the 1ST flag to ON. .. [453] Send To: Node Destination Node number of all netmail processed by the ALIAS server, if the database entry is of type NET. .. [454] Flags Define the behavior of generated mail for this entry. The first 4 flags determine the status of netmail. OFF - this entry is temporarily disabled. UUP - the destination is an Internet user, as specified in UUCP/Fax/Net NET - another netmail will be created, destined to UUCP/Fax/Net FAX - the message will be forwarded to UUCP/Fax/Net via the Fax server 1ST - if UUP is active, MG will put the To: user name of the netmail, preceding the UUCP/Fax/Net. This allows MG to dinamically forward UUCP mail to different users. LST - The same as 1ST, but the user name will be appended to the UUCP/Fax/Net name. .. [460] Menu Bar 1 Configuration of menu colors. .. [461] Menu Bar 2 Configuration of menu colors. .. [462] Menu Bar 3 Configuration of menu colors. .. [470] Create Ins Create a new message in the current folder. .. [471] Create Fax ALT-U This option has the same effect as INS, but, instead of opening the Alias database, MG will open the Fax database and address the message to the Fax server. .. [472] Kill Del Delete the current message. .. [473] Reply Alt-R Reply to the current message. .. [474] Netmail Reply Alt-N Reply to the current message in the netmail folder. .. [475] Forward Alt-L Forward the current message to another folder. .. [476] Folders Alt-F Select another message area. .. [477] Dos shell Alt-Z Invoke the DOS prompt. .. [478] Quit Alt-Q Quit the message base and return to MGSETUP. .. [480] Help Access to the Help Menu. .. [490] Main Main functions of the message folder. .. [491] Edit Edit the current message in the area. .. [492] Utilities Tools to maintain the message base. .. [493] Purge Remove messages under certain conditions. .. [494] Help Access to the Help Menu. .. [4A0] Keyboard help Ctrl-F1 Help with the function keys while in the message editor. Not available in the current version. .. [4A1] Show notes Alt-X Current status of the active message. .. [4A2] Change encrypt pwd Ctrl-P Change the password needed to encrypt a message while reading it. .. [4B0] From user Ctrl-B Remove messages matching the From: field. .. [4B1] To user Ctrl-T Remove messages matching the To: field. .. [4B2] From net address Ctrl-N Remove messages matching the originating node number. .. [4B3] To net address Ctrl-L Remove messages matching the destination node number. .. [4B4] Received Ctrl-V Remove messages that have been received by the destination user. .. [4B5] Age Ctrl-G Remove messages older than the specified date. .. [4C0] Management Alt-F9 Available tools to manage the current message area. .. [4C1] Move/copy Alt-J Move or copy the current message to another area. .. [4C2] Message to File Alt-V Save the current message in an external text file. .. [4C3] Print message Alt-I Print the current message. The printer must be on. .. [4C4] Renumber Alt-B Works only in the netmail folder. Renumber all netmail messages. .. [4C5] Change username Alt-G Select another user to be active in the message area. .. [4C6] Change address Alt-W Change Fidonet AKA node. .. [4C7] Change origin Alt-O Choose another Origin Line used to write messages in this area. .. [4D0] Status Alt-S Change the status of the current message. .. [4D1] Subject Alt-A Change the subject of the current message. .. [4D2] Text Alt-T Edit the contents of the current message. .. [4D3] Destination Alt-D Change the destination of the current message. .. [4E0] Read level Security level a user need to have to be able to read messages in this area. .. [4E1] Write level Minimum level needed to write messages in the netmail folder. .. [4E2] Sysop level Minimum level needed to have sysop privileges in the netmail folder. .. [500] Waffle UUCICO .. [510] Front-Door .. [511] Binkley/Portal .. [520] Hudson .. [521] JAM .. [522] Squish .. [523] SyncNet