Post.Office version 3.1 is an upgrade to version 3.0 that offers new security features and bug fixes. Highlights of the Post.Office 3.1 release include:
1. MAIL RELAY PREVENTION
Version 3.1 includes new features for restricting the relaying of mail through Post.Office. Mail relaying occurs when a mail server is given a message which is not addressed to one of its local mail domains. This is among the most common activities of a mail server, and occurs whenever you send a piece of E-mail to a user in a remote mail domain. However, relaying mail through remote servers is a common tactic used by distributors of "junk" E-mail, and can cause your mail server's performance to suffer.
INTRODUCTION TO MAIL RELAYING
Mail relaying is made possible by the openness of the SMTP protocol. By definition, SMTP servers accept network connections from mail clients and mail servers from around the network (or the Internet), and receive E-mail messages from the connecting system. If these messages are addressed to local users, the server will deliver them appropriately (for example, to a POP3 mailbox). However, if the messages are addressed to users in domains not controlled by the mail server, it must resend (relay) the messages to the appropriate mail server for delivery.
For example, say your mail client uses as its SMTP (outgoing mail) server the host sparky.software.com, which runs Post.Office. When you send a piece of E-mail to your sister at jane.doe@thishost.someisp.net, your mail client opens an SMTP connection to sparky.software.com, gives Post.Office the message, and then closes the connection. Post.Office then determines that the message should go to thishost.someisp.net, and opens a connection to that host to give it the message. Because the message was not addressed to a user on sparky.software.com, the Post.Office on that host simply relayed the message on to its final destination; if it hadn't, none of your E-mails would ever get to your sister (or anyone else whose E-mail account is not on sparky.software.com).
Although mail relaying is a common -- and, in most cases, essential -- activity for a mail server, it can become problematic if users abuse this functionality. The most common type of abuse occurs when users from outside of a domain use that domain's mail server as their SMTP server and send thousands of messages through it. Because the mail server must process and resend all of these messages, it may be temporarily unavailable to receive and/or deliver messages for the users who depend on this server for their E-mail.
This type of abusive relaying can be easily done by even unsophisticated users, and the source of the messages can often be difficult to trace. Restricting mail relaying is therefore a serious issue for mail administrators.
POST.OFFICE ANTI-RELAY FEATURES
The Post.Office anti-relay facility allows you to restrict mail relaying from specific systems or domains, or to disallow all relaying except for exempted systems and domains. You can also define the conditions under which restricted relay mail should be delivered.
Post.Office can use any of the following rules to determine the handling of relay mail:
You can specify the exceptions to these rules by IP address (to restrict or allow relay from a specific host) as well as by domain (to allow or restrict relay by all users in a specific domain). Because users can easily modify their mail client's return address to include any domain, restricting relay by IP address is the more precise method of the two.
Note that "restricted" does not mean "prevented." When you restrict relay mail with the above rules, that relay mail may still be allowed for processing and delivery. A second set of rules associated with relay prevention allows you to specify the domains that should receive restricted relay mail (for example, in the case that your mail server is used as a backup for another domain).
SMTP RELAY RESTRICTIONS OPTIONS
SMTP Relay Restrictions are divided into two sections. The first lets you define which type of mail relaying you want to restrict; this will include all of the types of relays that you want to prevent. The second part allows you to determine who should receive the mail from transactions covered by the relay restrictions defined in the first part of the form; this allows you to permit selective delivery of otherwise denied relay mail.
Remember that restricting relay mail DOES NOT by itself prevent the system at that address from relaying mail through Post.Office. It simply means such relaying will be allowed or denied according to the rules defined by the delivery options.
External Relay Restrictions
Allows you to specify rules for the restricting of relay mail. The four available selections are:
Don't restrict relay mail. This option allows all users to relay mail through your mail server without restriction.
You can enter a domain name in the delivery fields that includes a * character as a wildcard to specify all hosts in that domain.
When relay restrictions are set using domain names, Post.Office checks the return address on the envelope of every message in the system against the list of allowed or restricted domains. Because a user can easily alter his/her return address to include any domain, using domains to restrict or allow relaying is not as secure as restricting by IP addresses.
Allow Mail Delivery To:
Allows you to define which domains should or should not receive relay mail that you defined as restricted in the External Relay Restrictions section of this form. Note that relaying is not prevented -- even from restricted systems and/or users -- unless you also specify in this section of the form that delivery should not occur.
There are two options for allowing the delivery of relay mail that you choose to restrict:
As in the relay restriction options, you can enter a domain name in the delivery fields that includes a * character as a wildcard to specify all hosts in that domain.
If delivery of a relayed message is prevented, Post.Office returns an error to the sender indicating that the attempt to relay mail to the specified domain was denied. The event is also entered in the Post.Office logs if SMTP RelayDenied logging is enabled. If a relayed message is addressed to multiple users, some of which are located in a denied domain, normal delivery will take place for the users whose domains are not denied.
MAIL BLOCKING
In addition to restricting mail relaying, Post.Office 3.1 provides mail blocking functionality. Unlike anti-relay features, the purpose of mail blocking is to deny the delivery of messages which may be correctly addressed to users in local mail domains, but which are considered undesirable. The typical use of mail blocking is to prevent the delivery of unsolicited "junk" E-mail to users on your system.
The Post.Office mail blocking facility also allows you to disallow all network connections from specific systems, as defined by IP address. In addition to blocking the acceptance of mail from these blacklisted systems, this allows you to prevent "denial of service" attacks, in which systems open many SMTP connections to a server for the purpose of denying access from other systems.
(Note: Because mail blocking prevents the delivery of all messages (including legitimate E-mail) from the blocked systems and/or users, these features are recommended only in extreme cases.)
MAIL BLOCKING OPTIONS
Block Incoming Mail From: No one
This selection disables all mail blocking. This is the default mail blocking option.
Block Incoming Mail as Indicated Below
This selection allows you to use four different criteria for blocking mail: by IP address, by E-mail address, by domain, and by username. Each type of blocking is explained below.
Blocking by IP addresses
This option allows you to block all SMTP network connections to Post.Office from specific computers or networks, as defined by IP addresses. When accepting network connections, Post.Office checks the IP address of the connecting system against the list of IP addresses specified in this field; if the IP address of the connecting system is listed here, Post.Office refuses the connection.
When Post.Office refuses a connection from one of these blacklisted systems, an SMTP-Accept:ConnectionRefused event is entered in the Post.Office log (if you are logging this event).
Blocking by E-mail Address
This option allows you to block incoming mail based on its envelope return address. When accepting messages, Post.Office checks the return address on the envelope of each message against the list of E-mail Addresses specified in this field; if the return address is listed here, Post.Office rejects the message by reporting to the sending system that the destination address(es) of the message do not exist.
Blocking by Domain
This option allows you to block incoming mail based on the domain of its envelope return address. When accepting messages, Post.Office checks the return address' domain on the envelope of each message against the list of domains specified in this field; if the domains of the return address is listed here, Post.Office rejects the message and notifies the sender that he/she is not allowed to send mail to the destination address(es).
When Post.Office refuses a message from one of these blocked domains, an SMTP-Accept:SenderBlocked event is entered in the Post.Office log (if you are logging this event). For example:
Blocking by username
This option allows you to block incoming mail from E-mail addresses that include one or more specific user names (the username is the portion of an E-mail address to the left of the "@" symbol). This feature is useful if you want to block mail from distributors of "junk" E-mail who send messages from multiple domains but with the same user name. When accepting messages, Post.Office checks the return address username on the envelope of each message against the list of usernames specified in this field; if the username of the return address is listed here, Post.Office rejects the message and notifies the sender that he/she is not allowed to send mail to the destination address(es).
Other New Features
Along with relay-prevention and mail blocking, Post.Office 3.1 includes two other new features: more flexible SMTP logging, and configurable sending of mailing list nightly reports.
EXPANDED SMTP LOGGING
Control of SMTP logging has been improved by allowing Postmasters to individually log 13 different SMTP events, including three new events associated with mail blocking and relay prevention.
CONFIGURABLE SENDING OF MAILING LIST REPORTS
In order to keep mailing list owners up-to-date on the activity of their mailing list, Post.Office sends each list owner a nightly statistical report on mailing list usage for the pervious 24 hours. Included in this report are the number and size of messages submitted to the list, the numbers of subscription requests, unsubscription requests, and messages waiting for moderation, and a list of the top contributors to the list. These reports are sent at approximately midnight (according to the server system clock).
Release 3.1 gives more flexibility to this feature by allowing Postmasters and list owners to enable or disable the daily list report on a per-list basis. In the Delivery section of both the Mailing List Data Form (Postmaster interface) and Mailing List Info Form (list owner interface), a new check box field labeled "Daily Statistics" controls the sending this report. Enabling this option will cause the list owner to receive the nightly report, while disabling this field turns off the report feature for this mailing list.
Bug Fixes In 3.1
The following items (referenced by internal ID number) were recognized as bugs in prior versions of the Post.Office software. They have been remedied in version 3.1.
2311 - A mail routing hierarchy error in version 3.0 caused delivery to a local account (including accounts that use wildcard addressing) to be attempted prior to checking the SMTP Channel Alias Table for re-routing instructions. Re-routing mail according to the Channel Alias Table now occurs before all attempts at local delivery.
2406 - In previous versions, if the server system ran out of disk space during the distribution of a message to multiple mail hosts, Post.Office would later attempt to retry the entire transaction. These retries sometimes caused recipients to receive multiple copies of the same message. This behavior has been corrected in version 3.1 (build 205e). In this release, if the system disk space becomes full during the distribution of a message, Post.Office records the recipients who already received the message and internally queues the message for distribution to the remaining recipients.
Home Page | Post.Office | InterMail | Visit Software.com's Web Site