- The Messages Form
- The Security Form
- The System Form
- The SMTP Channel Form
- The Queue Form
- Error messages
- The QSND command
- UNIX commands
Configuration forms and other operation instructions
|
This chapter discusses post.office configuration
and error messages:
|
|
Configuration forms and other operation instructions
|
The configuration forms are used to configure all aspects of the post.office system outside of account and auto-reply configuration (which are covered in the previous and following chapter). In this sense this chapter is a bit of a catch-all, more so since we've appended our discussion of error messages to the discussion on configuration forms.
The configuration forms are:
The error messages discussed are:
Note: You may want to quickly take a look at chapter 4 if you haven't already. It provides a detailed description of what forms are and how to use them, as well as discussing the role of the postmaster, what accounts are, and the various types of aliases.
This section discusses the post.office configuration forms: the messages form, the security form, the system form, the SMTP form and the queue form.
While all mandatory configuration decisions are taken care of during installation, you will find if you peruse the configuration forms discussed in this section that there are some options which are new to you. Many of these options are refinements which are often not, strictly speaking, necessary, but they may enhance your E-mail system by optimizing post.office for your specific situation.
This chapter discusses each form in turn. First you get to see what the form looks like, followed by a description of what the individual fields on the form mean.
Turn to chapter four for a detailed discussion of how to obtain post.office forms.
Briefly: You can obtain E-mail forms by sending a form request to the address "configuration@your.host" with the name of the form you want in the body of the message.
To obtain a web form, point your web browser at your host, complete the authentication and select the configuration form you want.
Chapter four has a detailed discussion of these instructions if the above doesn't make sense to you.
The messages form provides various default finger and auto-reply messages for post.office to use in a pinch
The messages form provides the information used to answer finger queries which do not include a user name (i.e. queries addressed only to a host such as if someone queries the address: "@software.com") and to set up default auto-reply messages in case an account activates the auto-reply feature without specifying a message.
The form looks like this:
Postmaster-Password: [] (REQUIRED FOR THE FORM TO BE ACCEPTED)
Reply to this form, placing the desired information between square brackets.
For help with individual fields, see the descriptions following the form.
===== HOST FINGER INFORMATION =============================================
Host-Finger-Info: [Software.com, Inc.]
[Developer of post.office]
[827 State Street]
[Santa Barbara, CA 93101]
[(805) 882-2470]
===== AUTO-REPLY DEFAULT MESSAGES (Used When No Message is Specified) -----
Default-Vacation-Message: [Thanks for your E-mail. I'm unavailable for]
[the next several days, but I'll receive your]
[message when I return. You will not receive]
[additional notices that I am away if you send]
[me more messages during this temporary absence.]
Default-Echo-Reply-Message: [The person you sent the enclosed message to]
[is no longer with the organization, and did]
[not provide forwarding information. We are]
[sorry we were unable to deliver this message.]
Default-Info-Reply-Message: [The address you sent mail to was an AutoReply]
[account which was misconfigured (as it did not]
[contain the intended reply message). Please]
[notify postmaster@this.host which address]
[you were trying to mail to.]
Note: When submitting this form via E-mail, MIME Attachments can be used
to specify the information for these fields.
See "Using Attachments to Submit Information" below for details.
|
Figure 6.1.1a - The messages form allows you to set default finger and auto-reply messages.
Figure 6.1.1b- The messages form as it appears on the web.
|
Host-Finger-Info: This is information provided to queries that do not include a user name and are therefore addressed more generally to your company or organization.
This is a good place to put miscellaneous information about your company and maybe a couple of contact names and E-mail addresses. If you have a uniform policy for E-mail addresses (e.g. FirstName.LastName@your-domain) this is a good place to state it. However, this information probably won't get all that much play.
For example, if you finger "software.com" without specifying a host-name or someone's address you'll get a couple E-mail addresses you can use to contact us as well as our postal address and phone number.
Default-Vacation-Message: Hopefully people will remember to make their own messages before they take off for Las Vegas or to visit Graceland. This is a good place to leave a fairly generalized message saying something along the lines of "The person you tried to contact is on vacation..."
If this field is left blank, the Account-Manager will not accept an account or information form if the vacation feature is selected unless a vacation message is included when the form is submitted.
Default-Echo-Reply-Message: A common use of the echo feature is to return mail addressed to people who have moved on and left no forwarding address. So you could say something about that.
If this field is left blank, the Account-Manager will require that an echo message be included when the echo feature is selected on an account form.
Default-Info-Reply-Message: The purpose in having a default Info-reply message is somewhat elusive, even to the programmers at software.com who created this field, since the whole point of the Info feature is to make a custom information message available to the general public on demand. However, you could put in a message advising the sender that this automatic reply account is not working properly and request that they please contact the Postmaster or some such thing.
If this field is left blank, the Account-Manager will require that the postmaster includes a reply message when the reply feature is selected on an account form. Perhaps it may be best to leave this field blank.
The security form gives you the option of configuring certain system-wide security options:
Figure 6.1.2a: The web version of the security form. The E-mail version is not shown.
|
Each of the fields is discussed in turn below.
Security options for configuration via the web
Security options for configuration via E-mail
This form is a catch-all form to give you the option to configure certain things that you may need to configure once in a blue moon.
Postmaster-Password: [] (REQUIRED FOR THE FORM TO BE ACCEPTED)
MAIL DOMAINS HANDLED BY THIS HOST -- (See Descriptions Below for help)
Address-Completion-Domain: [oslo.software.com]
Local-Mail-Domains: [oslo.software.com]
[]
SYSTEM PERFORMANCE PARAMETERS
Lookup-Client-Machine-Names: [no]
Default-Max-Concurrent-Network-Servers: [15]
Default-Max-Concurrent-Local-Processes: [5]
MESSAGE QUEUING
Queue-Processing-Interval-(Seconds): [900]
Maximum-Queue-Time-(Days): [4]
LOGGING PREFERENCES
Log-Directory: [post.office]
LOG MODULE ACTIVITIES FOR THE FOLLOWING MODULES
DISPATCHER (Daemon on UNIX, Service on Windows NT)
Log-post.office: [no]
NETWORK MODULES
Log-Finger-Server: [no]
Log-POP3-Server: [no]
Log-SMTP-Accept: [yes]
Log-WWW-Server: [yes]
LOCAL MODULES
Log-Account-Handler: [no]
Log-Account-Manager: [yes]
Log-AutoReply-Handler: [yes]
Log-Configuration-Manager: [yes]
Log-Error-Handler: [yes]
Log-Mailbox-Deliver: [yes]
Log-Program-Deliver: [yes]
Log-SMTP-Deliver: [yes]
Log-UNIX-Deliver [yes]
Log-SMTP-Router: [yes]
|
Figure 6.1.3a - The system form allows you to set various configuration options. (E-mail version)
|
Figure 6.1.3b- The system form as it appears on the web. Only the first part of the form is shown.
Address-Completion-Domain: When mail arrives for a recipient whose address doesn't contain a domain, the domain specified here will be added to their address. If no domain is specified here, then the hostname of the machine running post.office will be assumed.
For example, if this is set to your domain name, then mail addressed "To: <user>" will be sent to "<user@your.domain>". In some cases there is an advantage to configuring the address completion domain to add your domain rather than host address. When your system uses host name hiding, a name@domain format will often fare better than a name@host.domain address completion
Please note that some mail client programs will not send mail which does not have a complete address; if you use one of these clients, you won't be able to send mail "To: <user>" and must type the whole address for each message you send, even when its local.
Local-Mail-Domains: This is a list of all the mail domains that are handled exclusively by this machine. If a domain is listed here and mail comes in with an address within that domain, the message is delivered locally to an account, referred to the postmaster, or is returned to the sender (if no account is found for the recipient).
If a domain is not listed here, this machine is not the primary mail handler for that domain (however, it can still receive mail for addresses in the unlisted domain if an account is set up with an appropriate alias).
Lookup-Client-Machine-Names: Enable this option (by choosing "yes") if you would like to have post.office perform a name lookup (via the DNS) on all connecting client machines. If enabled, machines will be referred to by their domain names; otherwise they will be referred to by their IP addresses. Places where these names show up include the process table, the log file, and "Received" lines in message headers.
If you handle a large volume of messages, be aware that selecting this option will slow down the program slightly.
Default-Max-Concurrent-Network-Servers: This default covers the number of SMTP, POP3, and Finger processes which can run at any one time. Specific processes are counted, not the total of all three. Since it is a default, it is used only if the defaults for those modules are not specified. The recommended default is 20, which is enough for most systems. Obviously if you're servicing 1000 users with POP3 you'll want to set the maximum run count for the POP3 module higher.
Default-Max-Concurrent-Local-Processes: This is the default for non-network processes such as Account-Handler which is applied only if a limit is not specified in the configuration of a specific module. The recommended default is 5. If you need to assess the local processes and what they do, you can go clobber yourself with the nitty gritty in the architecture appendix.
Queue-Processing-Interval-(Seconds): Messages that can not be delivered immediately are placed in a message queue. The system attempts to deliver queued messages at regular intervals as specified here. Typical intervals are between 30 minutes (1800 seconds) and 2 hours (7200) seconds.
Maximum-Queue-Time-(Days): Messages that can not be delivered in a timely manner are eventually returned to the sender with an error message. Use this parameter to set the maximum amount of time that a message is allowed to sit in the queue before it is returned. Internet standards recommend at least 4 or 5 days for this.
Log-Directory: The default value for the log directory field is "post.office" This stores the log file in the "log" sub-directory of the "post.office" directory (post.office/log). You do not need to specify the full path name to use this default - simply type "post.office". If you want the log file stored in a different place, specify the full path to the directory here. Be sure that the permissions of that directory allow post.office access to the log file. Also, since post.office runs as a non-privileged user for enhanced system security, it may be unable to create the log file if it does not already exist. In this case, simply move the existing log file to the new directory, or create a new log file with proper permissions.
Note: Many sites opt to set the logging option to "no" for the post.office dispatcher (Log-post.office) the POP3 server (Log-POP3-Server), and the WWW Server (Log-WWW-Server) since these modules tend to produce a high volume of log entries.
The SMTP channel form covers the configuration of the SMTP mail channel. It is used to configure a variety of options specific to the SMTP channel but is not used to set channel aliases.
This form includes configuration for the most common post.office error, Unknown Local Account..
The SMTP mail routing table is on this form.
Postmaster-Password: [] (REQUIRED FOR THE FORM TO BE ACCEPTED)
Reply to this form, placing the desired information between square brackets.
For help with individual fields, see the descriptions following the form.
===== SMTP CHANNEL GENERAL CONFIGURATION ==================================
Maximum-MTA-Hops: [30]
Always-Defer-Delivery: [no]
SMTP-Mail-Routing-Table: [*.software.com:*]
[*:firewall.software.com]
[]
[]
----- SMTP CHANNEL POSTMASTER CONTROLLABLE ERROR ACTIONS ------------------
Unknown-Local-Account: [return]
[notify]
[log]
Max-Hops-Exceeded: [return]
[notify]
[log]
|
Figure 6.1.4a - The SMTP form: E-mail version
Maximum-MTA-Hops: This parameter is used to prevent infinite mail loops. Usually a mail loop is caused by having two E-mail accounts on different machines that each forward mail to the other account. Any mail sent to either of these accounts will bounce back and forth between the machines forever. Fortunately these loops can be detected and stopped since each MTA "stamps" all incoming messages as "Received." By counting the number of "Received" lines in the message header, the MTA knows how many "hops" the message took to get here. If the number of hops exceeds the maximum specified in this parameter, an error report will be sent to the postmaster (This error action can be customized with the Handler-Unknown-Accts field below.) The recommended range for this parameter is 30 or more.
If you don't set a maximum MTA hop count, your messages may get dizzy.
Always-Defer-Delivery: Normally when a message needs to be delivered to another machine over the Internet, post.office attempts to deliver it immediately and queues it only if there is a problem. Setting this option to "yes" will cause post.office to instead queue all outgoing mail, and only attempt delivery when it processes the queue. (you can specify how often the queue is processed below.)
This feature is useful if you have only intermittent access to the Internet. By only sending out messages intermittently, you reduce the number of times you activate your connection, which may save you money.
SMTP-Mail-Routing-Table: Optional -- Mail can be routed to a machine other than the destination in the address. This is done with a routing table. Normally this is used only in a situation where a firewall prevents direct access to the destination mail server, or when mail needs to be sent through a gateway to another network (such as a UUCP network). The format for entries in the table is:
[*.domain:gateway.other_domain]
A "*" is used as a wildcard which will match any string of characters. The above entry would cause all mail addressed to any machine or sub-domain (because of the "*") within the domain to be routed to "gateway.other_domain" instead. The gateway would then send the mail on to the machine indicated by the address.
For example, to configure post.office to route mail to a UUCP gateway, you might use the following entry:
[*.uucp:uucp.gateway.host]
You should of course substitute the actual address for your UUCPgateway in the place of "uucp.gateway.host".
Similarly, in order to fidonet route mail to a FIDONET gateway, you would use an entry similar to this:
[*.fidonet:fidonet.gateway.host]
A default route can be set up so that all mail goes to a single machine by using a single "*" (the wildcard character) as in this example:
[*:mail.hub.machine]
A default route should only be used if it is absolutely necessary (as in a firewall situation) since it puts additional burden on the mail hub machine and can slow it down.
The fields described below allow you to customize what is done with a message that cannot be delivered. Each of these "error actions" can assume appropriate combinations of the following values (One entry per line, enclosed in brackets. Add additional lines and brackets as needed):
Usual entries are:
Inappropriate combinations, such as "log" by itself (which would log the error but delete the mail), should be avoided. You will probably always want to include a "return" entry or a "hold" & "notify" combination as part of your choices.
Unknown-Local-Account: (see options above) This "error" means that a message was addressed to a local domain but didn't correspond to an account or channel alias in the account database. The bad address could be a typo, or it could be a sign that you should set up an alias for a local user at the "bad" address (since people seem to think it is a reasonable address.)
Unless you get a prohibitive volume of unknown local account errors, you should set this on "notify", and "hold" especially if you're upgrading from a different mail system. This setting lets you, the postmaster, know of each error and allows you to intervene: resubmit the message, create a new alias, or return the message to its sender, or throw it away. Many administrators don't like to hassle with bad addresses due to the large volume they receive, so the default is "return" (which is what most message transport agents do).
Max-Hops-Exceeded: (see options above) This error usually occurs because of a mail loop (see Maximum-MTA-Hops description above). Mail loops are fairly serious problems and need to be resolved ASAP. Hence, the STRONGLY RECOMMENDED setting for this error is "notify" and "hold" so that the postmaster can reconfigure the responsible account, and resubmit the message to verify the problem has been corrected.
The queue form is used to check the mail queue and, if you want, to tell it to attempt delivery.
Once a message is queued because it couldn't be delivered, all subsequent messages to that address will be held until the next scheduled queue processing interval (usually every hour or two).
The following is a list of Queued Mail on oslo.Software.com (Note: It may take several minutes for the queue to process or expire for each host due to the time-out period for attempted contact with unreachable hosts. Please be patient when using this form. Additional information follows the Queued Mail list): Destination Host - Queued Messages 198.17.234.18: [] (process or expire) - 2 Message(s) queued. 198.17.234.2: [] (process or expire) - 1 Message(s) queued. INFORMATION ABOUT THE QUEUE FORM (Do not delete anything below this line). ================================ You can manually process or expire the queued mail in post.office on a host-by-host basis. Simply put "process" or "expire" (without the quotes) in the field next to any host you wish to act upon, and send in the form. Process will attempt to send the queued mail for that host immediately rather than waiting for the next regular queue period. Expire will attempt to send queued mail for that host one last time (immediately) and, if unable to connect, will return the mail to the sender. If you leave the queue action field blank for a host no action will be taken, so mail will continue to be processed for that host as though you had not submitted this form. Note: You can also process the queue using the QSND command during an SMTP session. See the manual for further information. Important Note: You do not need to delete anything from this form. If you do not wish to act on queued mail for a particular host, simply leave the field for that host blank. All post.office form submissions must be at least 10 lines long, so don't delete portions when replying to the form. This 10 line minimum stems from the algorithm to accommodate arbitrary message reply stings inserted by E-mail clients when sending message replies. ----------- Don't Modify Anything Below ________ Form: [Queue] Form-Identifier: [66275cb53ba0d2aaed7be93caddd9b30]
|
Figure 6.1.5a: The queue form: This example of the E-mail form shows that there are three messages queued for two different hosts. post.office gives you the option of trying to deliver the queued messages (process) or try one last time and then give up and return the message (expire).
You have three options when presented with the queue form:
Post.office will generate an error message to the postmaster on any occasion that it cannot carry out a task. Most error messages will have to do with addresses that post.office is unable to process, either because they are not entered correctly or because they do not exist.
Users also receive error messages when they try to send a message to an address that post.office cannot recognize. Postmasters can receive copies of these messages if they like.
There are two kinds of error messages, notification messages and action messages.
Many messages don't require any action on your part, and are sent simply to advise you that something happened. Usually they warn you of an error condition, but occasionally are for your information only.
For example, post.office will let you know that someone tried to send a message to your domain to an address that didn't exist. Most of the time that this happens, you'd probably think "so what?". Sometimes it's worth paying attention to such messages, for instance if you get a deluge of stuff for something like help@your.domain. If you're in the software business, it would be a good bet that people trying to get messages through to this address are customers or potential customers, and this would be a hint for you to set up an account for the address "help."
Another notification message might tell you that somebody tried to exploit a sendmail vulnerability to try to break into your system. While such a message is sent to you as a notification only, it is not a good idea to ignore it. Someone is probably trying to break into your network. This would at least require you to perk up your ears and check for any other signs of a breach of security.
Action messages are error messages that require you to make a decision as to how you want to deal with an error.
For example, you can set post.office to consult with you every time you receive a piece a mail addressed to your domain but which does not contain a valid address. In this case, the error message will show you the faulty address and ask you whether you want to delete, re-direct, or return the message. Such a message would look like this:
To: Postmaster@Software.com
From: Error-Handler@[198.17.234.2]
Reply-To: Error-Handler@[198.17.234.2]
Subject: MTA Error
Date: Mon., 12 Sep 1652 10:41:01 -0700
MIME-Version: 1.0
The mail system on rome.software.com encountered the following error:
The following destination addresses were unknown:
SMTP<sailes@software.com>
Options for this mail message are:
Action: [] (Delete,Return,Submit)
Postmaster-Password: [] (Required for any action)
The original mail envelope addresses are:
User-From: SMTP<poor.typist@want.mailserver.com>
Recipient: [<sailes@software.com>]
|
Figure 6.2.2a - A sample error message: "Destination address unknown" indicates that post.office was unable to recognize the message address and wants to know what to do with it.
Do not ignore or throw away these messages, or your memory will start to fill up with unresolved errors (Although, if you do ignore or throw them away, you will get another notice in a couple of days. If you continue to ignore them, they will be automatically returned to the sender, if possible, when the "Maximum-Queue-Time-(Days) has passed). Also the option to "Delete" a message should not be used carelessly since neither the sender nor the recipient(s) have gotten notification.
To properly handle the error, simply use the reply feature on your user agent, enter "delete", "return", or "submit" in the action field, enter the Postmaster password in the password field, and send the message back to the Error Handler. (When using the submit option, you can edit the Recipient field if you want to redirect the message or fix an incorrect address.) The Error Handler will process the form and either delete, return, or re-direct the message.
If you select submit, you must enter a valid address in the "Recipient" field (see illustration below, where the change is highlighted).
For example, in order to re-direct (submit) an error you would do this:
To: Postmaster@Software.com
From: Error-Handler@[198.17.234.2]
Reply-To: Error-Handler@[198.17.234.2]
Subject: MTA Error
Date: Mon., 12 Sep 1652 10:41:01 -0700
MIME-Version: 1.0
The mail system on rome.software.com encountered the following error:
The following destination addresses were unknown:
SMTP<sailes@software.com>
Options for this mail message are:
Action: [Submit] (Delete,Return,Submit)
Postmaster-Password: [Le/Me\See] (Required for any action)
The original mail envelope addresses are:
User-From: SMTP<poor.typist@want.mailserver.com>
Recipient: [<sales@software.com>]
|
Figure 6.2.2b - Resubmitting a message which had a bad address involves three steps: telling post.office to submit the message, entering the postmaster password, and correcting the typo in the recipient address.
In order to delete an error after notifying the sender and/or possible recipient(s), do this:
To: Postmaster@Software.com
From: Error-Handler@[198.17.234.2]
Reply-To: Error-Handler@[198.17.234.2]
Subject: MTA Error
Date: Mon., 12 Sep 1652 10:41:01 -0700
MIME-Version: 1.0
The mail system on rome.software.com encountered the following error:
The following destination addresses were unknown:
SMTP<sailes@software.com>
Options for this mail message are:
Action: [Delete] (Delete,Return,Submit)
Postmaster-Password: [Le/Me\See] (Required for any action)
The original mail envelope addresses are:
User-From: SMTP<poor.typist@want.mailserver.com>
Recipient: [<sailes@software.com>]
|
Figure 6.2.2c - Deleting a message involves only two steps: entering the word delete and the postmaster password.
The action taken by post.office for certain types of errors is configurable by the postmaster. These are explained in the forms for which the errors are relevant
For example, the Unknown-Local-Account field on the SMTP form can be set to automatically reject unknown addresses or refer them to the postmaster.
This section discusses those operations that are carried out without using post.office forms. these are:
On a UNIX host, you must
use the command line in order to start up or shut down the post.office
program. You can also check the status of and deliver the mail
queue.
The QSND command is used to instruct a remote post.office host to deliver its mail queue. The most common use of this command is to download messages from a host which is connected to the Internet to a host which is only intermittently connected.
To use the QSND command, simply telnet to the SMTP port (#25), and enter the command:
qsnd xxx
Where xxx can be "all" in order to prompt post.office to deliver the entire queue, or a specific host name (or domain), in order to request delivery of messages queued for that host only (or all hosts in that domain). For example:
qsnd chicago.software.com
Note: When you log on to the post.office host, you must use the qsnd command every time you log on and there are any messages for you in the queue, since subsequent messages to you will be automatically queued. If the queue is empty you do not have to do this, since post.office will attempt delivery on the first occasion a message for you arrives (unless the host is configured to defer delivery -- see the SMTP channel form).
The UNIX version of post.office
includes certain operations which are carried out at the command
line: starting up and shutting down the system, as well as checking
and delivering the mail queue. 
(On
NT systems, starting and stopping the service are done GUI style
with the Server manager which is pretty straight forward).
HOW TO START THE SYSTEM (UNIX PLATFORM) Once installed (see Chapter 3 for Installation) post.office normally starts up when the computer is turned on and runs continuously until the computer is shut down. If for some reason you need to manually start the system, just type the following command:
path_to_executables/post.office
The "path_to_executables" depends on where the post.office system is installed. To find out where the post.office program is installed on your machine, look in /etc/post.office.conf under ProgramDir.
How to Shut Down the System (UNIX PLATFORM) post.office is usually shut down automatically with boot scripts. If it is necessary to manually shut down the program, use the following command:
path_to_executables/post.office shutdown
The "path_to_executables" depends on where the system is installed. To find out where the post.office program is installed on your machine, look in /etc/post.office.conf under ProgramDir.
CHECKING THE MAIL QUEUE (UNIX PLATFORM) To check the mail queue, simply type mailq at a command prompt. If there are no queued messages, that fact will be reported:
% mailq Mail queue is empty. %
Otherwise each host that has queued messages waiting to be delivered will be listed, along with a count of the number of pending deliveries. For example, output might look like this:
% mailq Queued Messages Destination Host --------------- ---------------- 2 math.ucsb.edu 3 expertelligence.com %
In this example, a total of five messages are awaiting delivery. Delivery of all messages should require two connections to other machines since post.office attempts to deliver all queued mail for a host before disconnecting.
DELIVERING MAIL IN THE QUEUE (UNIX PLATFORM) The queue is automatically processed at regular intervals so normally you never need to manually deliver the queue. Also, you can use the E-mail or Web Queue forms to process the queue; however if you want to manually process the entire queue via the command line, use the "processq" command:
/usr/lib/processq
To attempt to deliver all queued mail for a specific host, the following command will do the trick:
/usr/lib/processq hostname
The hostname can be the full name of the host as reported by mailq, or any pattern contained in the name. If the pattern matches more than one hostname, each match will have its queue processed. As an example, "processq cs" would cause post.office to attempt delivery of all queued mail for math.ucsb.edu.
