What's expected of a Postmaster?

The Myth

The Postmaster role is summarized as "look after the mail system", which for many is viewed as passive role wherein the postmaster is reactive to both mail addressed to postmaster and system disasters.

The Reality

The role of Postmaster is complex and requires an active approach to ensure that the mail system operates most effectively.

The following attempts to describe some of what is expected of the Postmaster role from a Duty Statement perspective.

The Duty Statement

The Postmaster is required to:

Behind the Duty Statement

Actively Monitor the Mail System

The Postmaster must actively monitor and manage the mail system, including the following areas:

  • message flow
    • periodic or perpetual reviewing of pmdf_log:mail.log_current (requires the deployment of the channel keyword logging) preferably in addition to the usage of the PMDF option LOG_MESSAGE_ID to highlight the flow of individual messages
    • Monitoring via trends reflected in  channel counters  observed over significant periods of time
    • PMDF Monitoring for a more dynamic perspective of the system
    • .HELD messages indicating potential looping of mail messages, usually through a configuration error, will require investigation, and potentially, mail system reconfiguration
  • usage of processing resources
    for example:
    • incoming mail
      • SMTP processes deployed via Dispatcher or
      • (OpenVMS) TCP/IP SMTP service configuration
    • intermediate processing
      • directory channel
      • document and character set conversions
      • virus scanning
    • mail reading
      • interactive users
      • remote users using POP, IMAP processes deployed via Dispatcher
    • outgoing mail
      • (OpenVMS) batch queue and/or process symbiont usage,
      • (Unix) job_controller
       
  • console messages -- either (OpenVMS) OPCOM messages or (Unix) syslog messages
 
  • tuning the system and PMDF configuration, as required by the changing demands
 
  • enhance security of the messaging environment to limit "spam" or relaying attacks
  • MIME  content-type  mappings used in PMDF-MR and PMDF-LAN may require augmentation for new content types
  • check the contents of log files such as mail.log_current and channel log files (see also mail.log monitoring ).
  • The collection of statistics from the above will permit the preparation and deployment of a growth plan to cope with the probable increase in:
    • the number of messaging system users
    • the number of messages sent by the users
    • the increasing message sizes
    • the increasing dependancy of the organisation on e-mail

Maintain User Information

  • used addresses such as Fred.Bloggs@domain.com and the internal mail delivery address  e.g. fbloggs@server9.west.domain.com.

Respond to Postmaster Mail

The Postmaster will receive a variety of mail falling into the following broad categories, requiring a timely response:

  • queries or requests for assistance towards
    • resolving inter-domain mail (delivery) issues
    • identifying the correct address for a person believed to be in the postmaster's realm, although this function may be reduced by usage of the directory channel and/or a centralised naming scheme
  • errors on mail delivery
    • user errors addressed either by user education/training or additional aliases or directory entries
    • rectify configuration and/or environmental issues causing such errors
  • warnings
    • (OpenVMS) take appropriate action on log file version limit warning messages

Personal Development

As the Internet is a rapidly changing environment, the knowledge and skills of the Postmaster need to adapt to those changes. The following are just a  few sources of information and development the Postmaster may need to remain "current":

  • develop knowledge of the Internet RFCs that apply to running a mail system. Have a look at the RFCs typically installed into (Unix) /pmdf/doc/rfc or (OpenVMS) pmdf_root:[doc.rfc] if you answered yes to:

  • Do you wish to install the mail RFC files?

    during the installation or upgrade process.  The following RFC's provide a starting point:

    • RFC821 Simple Mail Transfer Protocol
    • RFC822 Standard for the format of ARPA Internet text messages
    • RFC974 Mail routing and the domain system
    • RFC1122 Requirements for Internet hosts - communication layers
    • RFC1123 - Requirements for Internet hosts - application and support
    • RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
    • RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
  • use info-pmdf as an avenue of learning as well as means of sharing with others

The Postmaster in Action

A duty Statement needs to be put into effect to achieve the desired end-result. The following perspective of a Postmaster in the Info-PMDF forum. Note that while this is an OpenVMS-centric perspective, the principles are also relevant to a Postmaster for Unix-based mail systems.

In a corporate environment, mail is usually mission critical (and even universities and ISPs want to provide good service to their  students and customers!).  For these environments, Process Software recommends:

  • Have a trained postmaster charged with watching the system every business day.
  • Make sure the postmaster has about 1-2 hours a day to take care of the mail systems.
  • Get the postmaster an X-terminal, AlphaStation, or VAXstation with a 21-inch monitor.  He or she will need the desktop real estate! Install Netscape Navigator for OpenVMS on the station (or host serving the X-terminal).
Process Software recommends that the postmaster monitor the MTA this way:
  • Start an instance of Netscape Navigator and run the PMDF CGI monitoring routing script. Maximize the monitor window and push it to the back of your desktop, like wallpaper. Throughout the working day, watch for the edges of the display to turn red. If they do, track down the error condition and fix it. (You may need to modify the alarm thresholds for your environment.)
  • Open a DECterm, (if the MTA is not the current system) SET BROADCAST=NONE and telnet or set host to the current postmaster's account on the MTA, and REPLY/ENABLE=NET/TEMP. Use this window to monitor OPCOM messages for network problems and watch for mail to the Postmaster. Read the Postmaster's mail with PMDF MAIL every few hours or if you get a flurry of it all at once.
  • Open a DECterm, SET TERM/PAGE=132, (if the MTA is not the current system) SET BROADCAST=NONE and telnet or set host to the MTA, and TYPE/TAIL/CONTINUOUS/INTERVAL=3 PMDF_LOG:MAIL.LOG_CURRENT. This requires VMS V6.0 or later.

The first two items above provide warnings if things are going badly. The third item provides constant reassurance that things are going OK. You need both kinds of monitoring, but folks often forget about the need for constant positive feedback. It's especially important if your regular worksystem is not the MTA.

If you have a backbone situation, with more than one MTA, you'll need to scale this up to watch them all.

It's hard to do this stuff from a PC because they don't multitask that well and the keyboard mapping is always a compromise.

Note that you need to log into the MTA to monitor it. In so doing, you are also monitoring the TCP/IP or DECnet network. Resist the temptation to forward postmaster mail to your PC. If mail breaks, you won't know!

These suggestions assume a PMDF MTA running on an OpenVMS system or cluster. You can easily modify them for a Tru64 UNIX or Solaris system (e.g., tail syslog rather than monitor OPCOM). They might be useful as a starting point for your own monitoring procedures.

Search: