The ROUTE.TDB file and its options

Although you can set a wide range of options in the configuration program, there is always need for more fields and more options which are difficult to put in a configuration program.

The ROUTE.TDB file is not only used to configure your system's routing, but has some additional functions. You can use it to:

All this and more can be configured in the plain ASCII text file called ROUTE.TDB, that you can edit with MS-DOS's EDIT, for example.

In this ROUTE.TDB file, you can use the following commands:

ROUTE-FIDO
This command is used to route Fido netmail messages through certain systems.

ROUTE-UUCP
This is nearly the same, but for routing UUCP mail messages through different UUCP up- and downlinks.

MAP-FIDO
When a netmail message is received for a certain user, you can map it to another user, possibly at another Fido system.

MAP-UUCP
Besides mapping UUCP mail messages to other systems, this command is also used to assign different sender addresses to Fido users.

FORBID-FIDO
You can forbid a certain Fido user, a group of users, or everybody to use the gateway.

ALLOW-FIDO
After forbidding a group of people to use the gateway you can make an exception for one or more users or systems.

SIGNATURE
Most UUCP messages have a small signature part with some general (brag) information about the person writing the message or the service provider. Use this command to automatically add signature files to all messages created by a user or a system.

NEWSFILTER
Name of the file that contains the newsgroup names that you want to create automatically or not.

SENDFILE
You can use this statement to let WtrGate reply with the contents of a file, when somebody send a message to specific address. It is a simple file robot.

SAVE
If you want to store messages that were sent to a specific address to a directory, then use this statement. You can use it to make some automatic mechanism where a program processes the messages that were saved.

SAVEFROM
If you want to store messages that were sent from a specific address to a directory, then use this statement. You can use it to make some automatic mechanism where a program processes the messages that were saved.

BOUNCE
If a system closes down or you don't want people to send mail somewhere, you can use this statement to block their path. The messages will be sent back with a specified reason.

BOUNCEFROM
If somebody keeps on sending you crap mail, then you can use this statement to bounce messages from that user automatically. The messages will be sent back with a specified reason.

GZIPBATCH
This can be used to set the first letter of the header that is added to news batches that compressed with GZip.

FORCEPACK
This is only used when running in FrontDoor mode and tells WaterGate to put netmail for a certain user or system into .PKT files, instead of storing them in the netmail area and letting FrontDoor handle the delivery.
The following pages contain an long explanation of each of the statements. There are two other statement to do with the Mail Tunnel functionality. See the separate chapter for more information.

ROUTE-FIDO: Route Fido messages

WaterGate currently implements only a very simple form of Fido routing:
ROUTE-FIDO <System_We_Route_Through> [<addresses> [...]]

ROUTE-FIDO 2:285/1        2:285/*
ROUTE-FIDO 2:280/802      2:* 140:*
ROUTE-FIDO 60:100/1       60:*
The destination system must be defined in the userbase. WaterGate will report an error if the system is unknown.

When a netmail message is encountered, WaterGate will check whether it is capable of transporting a message to its destination address. In the above example, a message for 2:255/1000 would be sent via 2:280/802, as would a message for 140:1000/100. However a message for 2:285/500 would be routed via 2:285/1

If WaterGate is incapable of routing a message, to 133:100/1 for example, an attempt is made to bounce the message to its sender.

If more than one routing statement can be used for a certain address, the routing statement with the highest address match will be used. For example 2:285/1000 will be routed to 2:285/1 (two matches) and not via 2:280/802 (one match only).

If the system is in FrontDoor compatible mode, the routing statements are not used. Instead, everything is put in the netmail directory, where FrontDoor/InterMail will take care of the routing.


ROUTE-UUCP: Route UUCP messages

The routing of UUCP mail can be implemented in two different ways. One is by configuring routings in WtrConf; the other is by using statements in the ROUTE.TDB file.

Usually, this is a proper way of setting up the system:

First, define your UUCP neighbors in the userbase. This is mandatory; if your neighbors are not defined there, you cannot route messages to or through them.

In these user records, you can also define their domain addresses, if any. There is a limit of 6 domain addresses for each neighbor.

Note that logically it does not matter if your neighbor is physically a FidoNet style node. This only affects the format of output created for your nodes, but is not of any importance for the names and routing of mail.

Next, define the systems that are more than one 'hop' away, i.e., not your neighbors, in your ROUTE.TDB file. The format of a UUCP-routing line in the ROUTE.TDB is:

ROUTE-UUCP <UUCP-name> <System-address>

where <UUCP-name> must be the UUCPname of one of your neighbors as defined in your userbase.

<System-address> can be:

If nodes under you have a world-registered UUCPname, you can use this UUCPname in bangpath addressing. If the name of the system through which a message should be routed is missing from the bangpath, a UUCPname routing statement can enable the mail to arrive anyway.

By using a complete domain address, you specifically route mail for that domain to one of your neighbors. The domain address must match 100% for it to work. This is the most widely used form of UUCP routing.

Note that this method can be used to add more domain names to one of your neighbors that is defined in the userbase, where you have space for only six domain addresses. On the other hand, you can also use those six lines as ROUTE-UUCP statements. Although it does work, we don't recommend using it, as you loose the complete view and control rather quickly.

Wildcards in the <System-address> allow you to route a complete hierarchy of domain-addresses to a certain neighbor without having to define each sub-node of that system separately. This allows your nodes to have sub-nodes of their own and they can create as many as they want. This is very useful when you or one of your nodes uses Fido-style addresses like "user@z2.n280.f802.p10.hisnode.wlink.nl".

You can then 'wildcard' the Fido segment of the complete domain address, so you won't have to define each Fido-style address he wants to use.

There are currently two types of wildcards:

  1. .yournode.wlink.nl
  2. *.yournode.wlink.nl
There is a very slight difference: Type 1 will route ALL addresses that end in 'yournode.wlink.nl', including sub-domains and the address "@yournode.wlink.nl" itself. Type 2 will ONLY route sub-domains, and will NOT route addresses like "user@yournode.wlink.nl".

Here are some example ROUTE-UUCP statements:

ROUTE-UUCP picard enterprize.space.nasa.gov

This ROUTE-UUCP line will route all mail for domain "enterprize.space.nasa.gov" to the system with the UUCPname "picard". This system must be defined in your userbase.

E.g., addresses like "Mr.Spock@enterprize.space.nasa.gov" or "enterprize.space.nasa.gov!Mr.Spock" will be sent to the system named "picard". Subdomains are not allowed here and the domain-address will have to match 100%.

ROUTE-UUCP nixon *.WaterGate.wlink.nl
This line will route all mail destined for all sub-domains (and sub-domains only!) of "WaterGate.wlink.nl" to the system with UUCPname "nixon". Once again, "nixon" must be defined in the userbase.

For example:

"operator@phonetaps.WaterGate.wlink.nl"
or

"oval.office.WaterGate.wlink.nl!president"

will be routed to that system. It will NOT route addresses like "first.lady@WaterGate.wlink.nl" or "WaterGate.wlink.nl!authors".

ROUTE-UUCP rspca .rodent.net

This line will route all mail to users with domain addresses ending in "rodent.net" to the system with the UUCPname "rspca". For example, "mickey.mouse@rodent.net" as well as "rabbits.rodent.net!bugs.bunny" or "sylvester@cats.rodent.net" are routed to the "rspca" system, which has to be defined in your userbase.

ROUTE-UUCP picard xs4all

This last example routes all mail sent to "annie.user@xs4all" or "xs4all!xs4no1!mary.helen" to the system with UUCPname "picard". Because "xs4all" does not appear to be a domain style address, it makes us suspect this routing line is used to alias another UUCPname or to be able to route a UUCPname of a system that is not our neighbor.

About bangpaths

Any system that is defined on UUCP has a bangpath, but not all systems have domain addresses. Therefore, bangpath addressing is always possible. Bangpaths are usually built up from UUCPnames (to keep them short), but a bangpath can also contain a domain addresses.

Internally, WaterGate converts all addresses to bangpaths. Then, for routing, it only looks at the part of the address that is in front of the first bang (bang = !). If that part of the address turns out to be its own UUCPname, and the address contains more than one bang, it looks at the part between the first and the second bang. This algorithm allows a very powerful and flexible way of UUCP mail routing and, knowing this, you may find some ingenious and creative ways to perform all the routing you want.

Don't use bangpaths in MAP-UUCP statements where you use a username as well, because there is no way for WaterGate to find out if the last part of the bang-path is a username or the name of a system. Use domain addresses instead.

Routing things you cannot do in ROUTE.TDB

You cannot put more than one <System-address> on a ROUTE-UUCP line. If you do this anyway, the line will be ignored. If you want more routings to the same UUCPname, then simply use as many lines as you need to route all system addresses and have them start with the same UUCPname.

You cannot chain the routing of UUCP-names. E.g.:

ROUTE-UUCP picard nixon
ROUTE-UUCP nixon *.watergate.wlink.nl

This will NOT cause mail for *.WaterGate.wlink.nl to be routed to system "picard". WaterGate will try to route it directly to "nixon", even though "nixon" is routed to "picard". Instead, use something like this:

ROUTE-UUCP picard nixon
ROUTE-UUCP picard *.watergate.wlink.nl

The reason is obvious: to prevent routing loops.

You cannot 'wildcard' bits and pieces of domain addresses. E.g.:

ROUTE-UUCP picard *gate.wlink.nl

This will NOT cause mail for "WaterGate.wlink.nl" or "water.gate.wlink.nl" to be routed to "picard". In fact, this may cause funny routing behavior.

A few last remarks about UUCP routing

If mail addresses contain capitalization, it will be kept intact, but will be ignored for routing. Capitalization in your routing statements (make them wolverine if you wish) will also be ignored. In other words: the routing in WaterGate is case-insensitive.

All routing techniques discussed here about the ROUTE.TDB file also apply to the domain addresses defined in the userbase. Whatever you fill in there will have the same effect as defining just as many ROUTE-UUCP lines that all start with the <UUCP-name> of that user. However, it is wise to stick to the structure as proposed above.

If the format of your ROUTE-UUCP statements are incorrect, then this may (and often will) cause unpredictable routing behavior. So make sure that all your routing statements are correct. Keeping the definition structure as proposed above will help to keep things clear and obvious, so you can almost immediately locate the problem if any problem occurs.


MAP-FIDO: Mapping Fido netmail messages

The MAP-FIDO command is used to map received Fido netmail messages to a different destination. For example, you can use this option to map messages for users that also have a point address to their point, or you can map messages for a Fido user to a different system, or even a UUCP system. Note: It only works on the To: address of netmail messages.

There are two forms of this command:

MAP-FIDO "username"%fidoaddr "username"%fidoaddr
and
MAP-FIDO "username"%fidoaddr user@domain

Examples and an explanation of all the options follow:

1.      MAP-FIDO "username" "username"
        MAP-FIDO "jaap aap" "SysOp"
Map netmail messages for a user on your system to a different user on your own system. All your system AKAs are accepted.
2.      MAP-FIDO "username"           "username"%2:280/803
        MAP-FIDO "username"%2:280/802 "username"
        MAP-FIDO "username"%2:280/802 "username"%2:280/803
This is the same as for the first example, except that in the first line the message is now mapped to 2:280/803 instead of to your own system. The second line shows how a message passing through your system can be mapped to a local user, and the third sho
3.      MAP-FIDO "username"           user@domain
        MAP-FIDO "username"%2:280/802 user@domain
        MAP-FIDO "jaap aap"           jaap.aap@network.nl
Received netmail can also be mapped to an Internet domain address; this is a one way conversion. Messages for jaap.aap@network.nl are not mapped back to the "jaap aap" fido user! Neither can you specify a domain address for the first parameter!

Order of precedence for MAP-FIDO

When more than one MAP-FIDO statement could be applied to a netmail message, the mapping statement that will be used is selected as follows:

When only the address matches, the last mapping statement will be used. If a mapping statement exists that both matches the address and the user name, then that mapping is used and the search is stopped.


MAP-UUCP: Mapping UUCP mail messages

Mapping received UUCP mail messages is a little more complicated, as there are quite a lot of possible options. It is possible to map a message for a user to another user, or map all messages for a system to another system, or even to one user. Besides that, you can use the information BACKWARDS to allow mapping of Fido addresses into domain addresses.

If you want these commands only to work from FidoNet to UUCP, you can use the prefix -FU. If you only want them to work from UUCP to FidoNet, you can use the prefix -UF. If you want them to work in both directions, then don't use a prefix at all. The prefix has to be put on the line right after the command.

Note: unregistered users can only have five (5) MAP-UUCP statements in their route.tdb file. Extra MAP-UUCP statements are ignored and an error message will be logged.

The two basic formats of this command are:

MAP-UUCP user@domain user@domain
MAP-UUCP user@domain "username"%fidoaddr
Examples and an explanation of each of the options follow below:
1.      MAP-UUCP user@domain user@domain

        MAP-UUCP jaap.aap@network.nl sysop@network.nl
        MAP-UUCP jaap.aap@network.nl aapwork.nl
        MAP-UUCP jaap.aap@network.nl jaap.aap@aapwork.nl
The simplest map is to send all message from one user to another. Use this, for example, if you use multiple user names, but like to have all replies to 'SysOp'.

The last two options are equivalent, and will both deliver all messages for jaap.aap@network.nl to jaap.aap@aapwork.nl

2.      MAP-UUCP domain user@domain

        MAP-UUCP oldserver.network.nl sysop@newserver.network.nl
Use this combination to send all messages for a complete domain to a single user at another system. This may come in handy when one of your downlinks changes its name or is temporarily off-line.
3.      MAP-UUCP domain domain

        MAP-UUCP oldserver.network.nl newserver.network.nl
This will map all messages for all users of a domain to the same users at another domain address.
4.      MAP-UUCP user@domain "username"
        MAP-UUCP user@domain "username"%fidoaddr
        MAP-UUCP user@domain fidoaddr

        MAP-UUCP jaap@aapwork.nl "jaap aap"
        MAP-UUCP jaap@aapwork.nl "jaap aap"%2:280/802
        MAP-UUCP jaap@aapwork.nl 2:280/802
To map all messages for "user@domain" to a Fido system, simply specify the username at your own system, or the name of a user at another Fido system.
5.      MAP-UUCP domain fidoaddr
        MAP-UUCP domain "username"%fidoaddr

        MAP-UUCP aapwork.nl 2:280/802
        MAP-UUCP aapwork.nl "sysop"%2:280/802
This combination will send all messages for an entire domain to a Fido system. The user names will be correctly translated into an acceptable Fido form. (Jaap_Aap -> Jaap Aap)

Order of precedence for MAP-UUCP

When more than one mapping statement can be applied to a particular message, then only the first mapping statement is used.

FORBID-FIDO/ALLOW-FIDO: Restricting the gateway

Acting as a public gateway may be a really rewarding thing for your soul, and a great thing for mankind; but it's not going to pay your monthly phone bills. By default, WaterGate will allow everyone to gate messages between a Fido and a UUCP network.

Add the following command to your ROUTE.TDB file:

FORBID-FIDO *
Now nobody, including yourself, is allowed to use the gateway; probably not exactly what you intended. Now relax this a little by giving some people access rights:
ALLOW-FIDO	2:280/*
ALLOW-FIDO	2:281/*
ALLOW-FIDO	2:280/802   Maarten User
ALLOW-FIDO	2:280/802   SysOp
ALLOW-FIDO	2:280/18.*
FORBID-FIDO	2:280/18    Jaap User
This allows everyone within the nets 280 & 281--except a special case, "Jaap User" at 2:280/18--to use the gateway. Plus 2:280/18 and its points, and "Maarten User" and "SysOp" at the system 2:280/802, are allowed to use the gateway.

MAP-AREA: Receive a mailing list in an area

Quite some users on your BBS might subscribe to a mailing list and receive this as netmail on the BBS. There is quite some flow in some of these mailing lists, so that means a lot of messages in your netmail area.

Also, if more users on your BBS want to receive the same mailing list, you receive more than one copy of these messages and they will all have to be stored in the netmail area until the users have read and deleted them.

It is not possible to set up a local mailing list and feed all incoming messages into that list, because the sender of the message must be connected to the local mailing list. And in most cases, the sending will be the original sender of the message that was distributed by the mailing list server. It is impossible to have all these names in your local mailing list setup.

If you don't like all these messages in your netmail area, or want to provide a mailing list for all your users, so you only have one copy of them, you have to take a look at the MAP-AREA statement.

Basically, what the MAP-AREA statement does is convert incoming e-mail into news. The news is then distributed, gated to echomail and stored in your message base.

When you receive e-mail from a mailing list, you always receive that to the same name. Because the MAP-AREA statements takes all incoming mail to a certain address, you have to subscribe to the mailing list with a special "receiver" address, or else all your personal e-mail will be mapped as well.

For example, you are connected to the mailing list WaterGate, which is watergate@wsd.wline.se. You receive the mailing list messages as wg-receiver@bravo.com and you want this to be put in the area you created with the name WG-LIST. You then use the following statement in your ROUTE.TDB file:

MAP-AREA wg-receiver@bravo.com WG-LIST
Where WG-LIST can be either the Fido or Usenet name of the area.

Notice that this statement looks at the e-mail address that can be found in the .X file in your spool directory. Only MAP-UUCP statements are processed before the MAP-AREA is checked against that address.


SIGNATURE: Adding signatures to a message

Most messages found on UUCP have some kind of signature at the end, usually containing some information about the writer, the fact that whatever he or she wrote wasn't done with all senses intact, and that his employer would be most surprised if someone took it seriously. Of course, this can be done in a million unique ways, and as long as the message isn't irritating (try to keep it at four lines or less), nobody will bother.

Since most Fido style BBS programs are unable to add signatures to a message by default, or aren't capable of using different ones for different users, you can have WaterGate do it automatically. All you need for each signature is a small text file containing the signature, and a definition in the ROUTE.TDB.

SIGNATURE filepath fidoaddr {username}

SIGNATURE D:\BBS\SIG\DEFAULT.SIG 2:280/802
SIGNATURE D:\BBS\SIG\SYSOP.SIG   2:280/802 Jaap Aap
SIGNATURE D:\BBS\SIG\NEOLINK.SIG 2:280/801
This will add DEFAULT.SIG to all messages gated from Fido to UUCP originating from 2:280/802, except that user "Jaap Aap" will get the SYSOP.SIG signature instead.

An example signature file:

,----------------------------.------------------------------.
| Martijn Dijksterhuis       | Kids! Bringing about         |
| martijnd@dijkline.wlink.nl | Armageddon can be dangerous. |
| martijnd@htsa.aha.nl       | Do not attempt it at home    |
`----------------------------.------------------------------'
For automatic processing, the signature will be preceded by a tear-line, just as in fido messages. This tearline consists of two dashes followed by a space ("-- "). WaterGate automatically adds this tearline, so there is no need to put it in the signature file.

When a netmail message is distributed by a mailing list and gated to e-mail then the signature of the sending user is not used, but the signature for the mailing list. This is the name of the mailing list the mailing list AKA. This allows you to put a special signature under these distributed netmails with - for example - information on how to disconnect.

If you don't like the above behaviour then you can send a netmail to through the gateway to the e-mail side of the mailing list. Your signature will be added to the gateway e-mail and is then distributed by the mailing list. This requires that you are subscribed to the mailing list with your e-mail address. Following is an excerpt about signatures from a classic article, which is regularly posted to news.announce.newusers by Gene Spafford.

Q: Dear Miss Postnews: How long should my signature be? -- verbose@noisy

A: Dear Verbose: Please try and make your signature as long as you can. It's much more important than your article, of course, so try to have more lines of signature than actual text.

Try to include a large graphic made of ASCII characters, plus lots of cute quotes and slogans. People will never tire of reading these pearls of wisdom again and again, and you will soon become personally associated with the joy each reader feels at seeing yet another delightful repeat of your signature.

Be sure as well to include a complete map of UUCP with each signature, to show how anybody can get mail to you from any site in the world. Be sure to include Internet gateways as well. Also tell people on your own site how to mail to you. Give independent addresses for Internet, UUCP, and BITNET, even if they're all the same.

Aside from your reply address, include your full name, company and organization. It's just common courtesy -- after all, in some newsreaders people have to type an *entire* keystroke to go back to the top of your article to see this information in the header.

By all means include your phone number and street address in every single article. People are always responding to UUCP articles with phone calls and letters. It would be silly to go to the extra trouble of including this information only in articles that need a response by conventional channels!


NEWSFILTER: Auto-created newsgroups filter

The NEWSFILTER statement points to a file that WaterGate uses to decide whether an area should be created automatically when a unknown newsgroup name is detected.

If you have "New area create" enabled in the user record of your UUCP uplink, then you might have noticed that WaterGate creates a lot of new areas with funny names. Most of these areas you don't want to have at all.

The new newsgroups filter file allows you to tell WaterGate which newsgroups you want to have auto-created and which you do not. By default, WaterGate doesn't auto-create a newsgroup at all, until you install the NEWSFILTER file.

In this file, you can enter the complete or partial names of the newsgroups. There are special characters and wildcards that save you a lot of typing. People that are familiar with the Waffle FEEDS file will find some resemblance.

ALT.*
COMP.*
!COMP.OS.*
This file tells WaterGate that you don't want any newsgroups unless they start with ALT and COMP. But, you don't want the newsgroups that start with COMP.OS.

The exclamation sign (!) is a "NOT" operator.

The extension dot plus asterisk (.*) means that you want all the newsgroups that start with that text, but not the newsgroup that starts with that name itself (for example "ALT").

Here is a somewhat more complicated example:

ALT.*
!ALT.BBS.*
ALT.BBS.WATERGATE
!ALT.BBS.WATERGATE.D.
This file basically tells WaterGate that you want all the newsgroups that start with ALT, but not the newsgroups that start with ALT.BBS, except newsgroups that start with ALT.BBS.WATERGATE, which you do want, but not that one special ALT.BBS.WATERGATE.D newsgroup.

The extension dot (.) means that you want the newsgroup with that name and only that newsgroup, not the newsgroup with names that start with this. If the exclamation sign (!) is in front, it means that you don't want that specific newsgroup.

You can also put comments in the filter file on any line you want by putting in a semi-colon (;) before the comment.

A special case is when the NEWSFILTER statement is not present in the ROUTE.TDB file, or the news filter file could not be opened, or it is empty, or the ROUTE.TDB file is not present. In that case, no new newsgroup names filter statements are present. WaterGate then allows all new newsgroup names. That way, you don't have to setup the filter file at once. This is reported in the log file at startup of WtrGate with the line "Allowing all new newsgroup names".

Logging information

When your filter file gets big, it might become troublesome to find why a certain newsgroup name is rejected by WaterGate, while you want it, or why a certain newsgroup name is allowed, while you don't want it.

If you enable the "New newsgroup names check" log file option, WaterGate will tell you when it accepted or rejected a certain newsgroup and which line in the log file caused the decision.

For example,

ALT.*
!ALT.BBS.*
ALT.BBS.WATERGATE
!ALT.BBS.WATERGATE.D.
The newsgroup ALT.BBS.WATERGATE is accepted, because of line three. If line three was not there, then line two would have caused WaterGate to reject it. When WaterGate processes the filter file, it looks at every single line; if that line applies to the newsgroup name, the decision to accept or reject the newsgroup can be changed.

SENDFILE: a simple file robot

You can let WaterGate reply to a message automatically. You prepare the reply in a file that is put in the body of the reply message. If you want to send a file, you have to UU-encode it yourself first.

The sendfile statement works from both the UUCP side as the Fido side.

The format of this statement is:

SENDFILE <user name> <path to file>
For example:
SENDFILE watergate-info c:\wsd\wginfo.txt
SENDFILE wtrkit-req c:\wsd\wtrkit.txt
The e-mail address where people have to send their message to is the <user name> at any of your system domain addresses, for example watergate-info@wsd.wline.se.

For FidoNet, people have to send a netmail message to <user name> at one of your system AKAs, for example watergate-info at 2:200/111.


BOUNCE: Send mail back with a reason

You can use the BOUNCE option for more than one purpose, but it is mostly used to inform people that certain e-mail addresses or even a whole system cannot be used anymore.

The e-mail address you have to put in the statement has to match only partially. Or in other words: the search string you put in the statement must appear in the e-mail address that is checked.

BOUNCEFROM is used to bounce messages sent from a certain address, whereas BOUNCE checks who the message is sent to. The Sender:, Reply-To: and From: headers are checked for the search string and only a partial match is enough.

Not only is the message returned to the sender, but you can supply a reason as well. To support multiple languages, you have to put "Reason: " in front as well, if you wish.

The format for this statement is:

BOUNCE <partial e-mail address> "Reason"
BOUNCEFROM <partial e-mail address> "Reason"
For example:
BOUNCE wsd.wlink.nl "Reason: moved to Sweden"
BOUNCE ftpmail "Reason: ftpmail option is blocked!"
BOUNCE erik@wsd.wlink.nl "Reason: Account is closed!"
BOUNCEFROM sales "Reason: Not interested"

SAVE: Write messages to disk

With the SAVE and SAVEFROM statement you can save messages that were at your system to a file on disk. SAVE checks the address in the .X file and SAVEFROM the From:, Reply-To: and Sender: headers. The contents of the messages are completely saved in the file.

You can use it to let an external program process the message and send a reply, although there are no posting options in WaterGate yet.

For SAVE, the e-mail address that is checked has to match exactly. So, it is not possible to save all messages for a complete domain in a directory. This is to protect systems. On the other hand, SAVEFROM works on a partial address.

After the message has been saved, it is destroyed and not sent along.

The format of the SAVE and SAVEFROM statements are:

SAVE <e-mail address> <directory>
SAVEFROM <partial e-mail address> <directory>
For example:
SAVE ftpmail_receiver@wsd.wlink.nl c:\saved\
SAVEFROM mailer-daemon c:\saved

MAP-UUCP and BOUNCE, SAVE, SENDFILE

The MAP-UUCP statement is processed before the BOUNCE, SAVE and SENDFILE options are checked. This way, you can "route" messages that are sent to different addresses all to one address and then use one bounce, save or sendfile statement.

Of course, it is perfectly possible to use more that one bounce, save or sendfile statement that have the save reason, use the same directory or point to the same file.


GZIPBATCH

This option can be used to set the first letter of the header that can be added to news batches that have been compressed with GZip. The header is used on UNIX systems to find out that the batch is compressed. Actually, it is a command that executes a script.

This script is called "cunbatch" when the batch is compressed with normal compress. The names of the script for gzip compressed batches is differing though. Normally, it is gunbatch, but it can also be zunbatch.

To overcome this difference, you can set this letter system-wide (for all your UUCP users that you compress with gzip for and have the "Add batch header" option set to YES).

The format of this line is:

GZIPBATCH <letter>
for example:
GZIPBATCH z
You normally don't need this statement.

FORCEPACK

This is only used when running in FrontDoor mode.

WaterGate normally writes netmails for users to the netmail area when configured to work together with FrontDoor. The actual delivery of the netmail is then handled by FrontDoor.

When configured for Binkley or d'Bridge compatibility, WaterGate packs up the netmails into .PKT files and doesn't write them to the netmail area.

You can use FORCEPACK to tell WaterGate to put netmails into a .PKT file, even when running in FrontDoor mode.

This is especially useful when using Mail Tunnel in combination with FrontDoor mode and basically then only way to get netmails delivered because the user in question would never dial in.

The format of this statement is:

FORCEPACK <node number>
for example:
FORCEPACK 2:200/111.15

Back to Table of Contents or continue to the next section.

Comments or questions? Send an e-mail to editor@wsd.wline.se.

Last updated 13 October 1996