Sendmail 8.13.1 for MPE/iX

»  Home

» Software
» Papers & Training
» Java

Last updated September 1, 2005


Sendmail is a Mail Transport Agent (MTA) that allows your HP e3000 to send and receive SMTP-based e-mail. It is strictly an MTA that communicates with other remote SMTP-based MTAs and it does not include any Mail User Agent (MUA) tools such as mail readers or composers. Sendmail is highly configurable and extremely flexible.

Sendmail is fully supported by the HP Response Center as part of MPE/iX 6.5, 7.0 and 7.5 FOS. The most recent full-product patches for Sendmail are:
  • MPE/iX 6.5 - SMLHDB9A
  • MPE/iX 7.0 - SMLHDC0A
  • MPE/iX 7.5 - SMLHDC1A
If you are installing Sendmail 8.13.1 A.02.00 to replace Sendmail 8.12.1 A.01.00, the /etc/mail/ and configuration files will be replaced if those files are exact matches for the Sendmail 8.12.1 A.01.00 sample configuration files in the /SENDMAIL/A0100/etc/mail.sample directory.

All of the source code required to build the product is included in each patch. This source code consumes approximately 30,000 sectors of disk space and may be purged with the following command if no builds are going to be performed on the customer machine:


The feature list of sendmail is quite extensive; the following is only a partial list:
  • Send and receive SMTP-based e-mail
  • Deliver local e-mail to mailboxes, files, or programs
  • A vast selection of tunable performance parameters
  • Highly flexible and extremely powerful configuration language
  • Access control for accepting or rejecting incoming e-mail
  • Message header rewriting capabilities
  • Modular feature set allows you to configure exactly the functionality you want; the following optional features have been configured by default in this distribution (see below for details):
    • access_db
    • domaintable
    • genericstable
    • mailertable
    • virtusertable
  • Open-source robustness and reliability


The following prerequisites apply to this distribution of sendmail:
  • Approximately 71000 sectors of available disk space.
  • A syslog daemon must be running on the same machine as sendmail so that debugging and auditing log events can be captured. A syslog daemon is bundled with MPE/iX 6.0 or greater, and is described in the Configuring and Managing MPE/iX Internet Services manual. Note that some third-party spooling packages may contain an embedded syslog daemon of their own.
  • Sendmail uses the POSIX time functions in order to timestamp messages, and these functions depend on the TZ environment variable being set properly. The best place to set TZ is in your system logon UDC, i.e. SETVAR TZ "PST8PDT" (Pacific Time Zone example). For further information about TZ, please see "man timezone" or /SYS/LIB/TZTAB.
Sendmail requires the use of one or more Domain Name Servers in order to resolve host names while sending and receiving e-mail, and a proper DNS configuration requires several things:
  • A single "domain" statement in the file /SYS/NET/RESLVCNF that defines the domain part of your local machine's host name. For example, if your machine's fully-qualified host name is, then /SYS/NET/RESLVCNF must contain a "domain" entry. For more information about the /SYS/NET/RESLVCNF file, please see the Configuring and Managing MPE/iX Internet Services manual.
  • One or more "nameserver" statements in /SYS/NET/RESLVCNF listing the IP address of the DNS servers that your local machine will be using to resolve host names. It is not necessary to run a DNS server on your local machine.
  • Your local machine must be defined within the nameserver databases as having a valid "A" record that maps the local machine's hostname to an IP address.
  • Your local machine must be defined within the nameserver databases as having a valid "PTR" record that maps the local machine's IP address to a hostname.
The number one cause of sendmail problems is DNS configuration issues. This distribution of sendmail comes with an automated DNS checking tool that should be run before you first attempt to use sendmail. Please see "installing the software" below for more details.

Installing the software

If you are currently running the unsupported sendmail 8.9.1 freeware version, you should save your JDAEMON job stream before installing Sendmail 8.13.1:
  3. There should be no other file conflicts between sendmail 8.9.1 and 8.13.1 because the two releases install into completely different file layouts.
The software will be installed into the SENDMAIL account and various configuration files will be created in the /etc/mail directory if they do not already exist.

After the software bits have been installed, check your DNS configuration before trying to run Sendmail for the first time:
  3. shell/iX> /SENDMAIL/CURRENT/bin/dnscheck (to check for DNS problems)
  4. If DNS problems are found, follow the instructions to correct the problem and rerun the dnscheck script until no additional problems are detected.
If you will be using the FOS syslog daemon for the first time because of sendmail, please correct the SYSLOG account file ownerships by performing the following steps:

Distribution highlights

All files reside in the SENDMAIL account in a version-specific group named vuuff (i.e. A0200). A symbolic link named CURRENT points to the active version-specific group. If you install a newer version of this distribution on top of an existing installation, a new version-specific group will be created and the CURRENT symbolic link will be adjusted to point to the new group. The old version-specific group will NOT be purged by the INSTALL script, so once you are satisfied the new version is working OK, you will have to manually :PURGEGROUP the old version if you wish to free up its disk space.

Applications that require a specific version of sendmail should reference files and directories using a pathname prefix of /SENDMAIL/vuuff. Applications that don't have any version dependencies should use a pathname prefix of /SENDMAIL/CURRENT.

The main files and directories of this distribution are as follows:
The sample batch job for running the mail daemon.
The main sendmail NMPRG.
Directory containing various sendmail utility programs:
Script for validating your DNS configuration.
Symlink for displaying host status information. See "man sendmail" for details.
Macro processor used to generate sendmail configuration files.
Symlink for displaying the mail queue. Requires SM capability or being logged on to the SENDMAIL account. See "man mailq" for details.
Symlink for rebuilding the aliases database map. Requires being logged on as SERVER.SENDMAIL. See "man newaliases" for details.
Symlink for purging host status information. See "man sendmail" for details.
Autoresponder program for vacations. See "man vacation" for details.
Directory tree for building sendmail configuration files:
Comprehensive instructions for configuring sendmail.  A MUST READ!!!
Sample MPE/iX sendmail configuration output file used by the mail daemon.
Sample MPE/iX sendmail configuration macro file used to create
Sample MPE/iX mail submission configuration output file used when submitting new messages.
Sample MPE/iX mail submission configuration macro file used to create
Postscript copy of the Sendmail Installation and Operation Guide. A MUST READ!!!
POSIX shell profile used when logged onto the SENDMAIL account.
Directory containing many sample configuration files that will be automatically copied to /etc/mail at installation time if files of the same name do not already exist in the target directory.
Directory containing man page documentation, suitable for adding to your MANPATH environment variable, i.e. export MANPATH=/SENDMAIL/CURRENT/man:$MANPATH.
Directory containing various sendmail utility programs:
Program for editing sendmail database maps. See "man editmap" for details.
Program for displaying sendmail traffic statistics. See "man mailstats" for details.
Program for creating sendmail database maps. See "man makemap" for details.
Program for printing the contents of the aliases database map. See "man praliases" for details.
Symlink for /SENDMAIL/CURRENT/SENDMAIL. See "man sendmail" for details.
The sendmail restricted shell, optionally used to control what external programs sendmail is allowed to deliver mail to. See "man smrsh" for details.
The following symbolic links are created at installation time in order to provide compatibility with the HPUX sendmail file layout:
  • /usr/bin/m4
  • /usr/bin/mailq
  • /usr/bin/mailstats
  • /usr/bin/newaliases
  • /usr/bin/praliases
  • /usr/bin/vacation
  • /usr/lib/sendmail
  • /usr/sbin/editmap
  • /usr/sbin/hoststat
  • /usr/sbin/mailstats
  • /usr/sbin/makemap
  • /usr/sbin/newaliases
  • /usr/sbin/purgestat
  • /usr/sbin/sendmail
  • /usr/sbin/smrsh
All sendmail runtime configuration files reside in the /etc/mail directory which is populated at installation time from /SENDMAIL/CURRENT/etc/mail.sample for any files that do not already exist. The /etc/mail directory contains the following files:
The ASCII access database map used to accept or reject mail from selected domains. This map is initially empty, which accepts mail from all domains.
The compiled access database map created by makemap.
The ASCII aliases database map used to create local mailbox names that do not necessarily correspond 1-to-1 with local users. Aliases can be defined to deliver mail to multiple users, to files, or to programs. This map initially defines postmaster as SERVER.SENDMAIL and MAILER-DAEMON as postmaster.
The compiled aliases database map created by newaliases.
The ASCII domaintable database map used to remap domain names in mail headers. Because the headers are rewritten, you should only use this for your own domains. This map is initially empty, which does no header rewriting.
The compiled domaintable database map created by makemap.
The ASCII genericstable database map used to remap the user and hostname portion of outgoing header addresses. This map is initially empty, which does no reader rewriting.
The compiled genericstable database map created by makemap.
The documentation returned by the SMTP protocol HELP command.
The ASCII file containing hostname aliases (one per line) for the local machine. This file is initially empty, and so incoming e-mail will only be accepted if it is addressed using the true host name of the local machine.
The ASCII mailertable database map used to override mail routing for selected domains. This map is initially empty, and so all mail routing is controlled by
The compiled mailertable database map created by makemap.
The m4-created configuration file for the mail daemon.
The POSIX PID of the currently running mail daemon.
The binary file used to collect sendmail traffic statistics.
The m4-created configuration file for mail submission.
The ASCII virtusertable database map used to perform domain-specfic aliasing and and hosting of multiple virtual domains on one machine. This map is initially empty, and so no virtual domain aliases will be recognized.
The compiled virtusertable database map created by makemap.
The user SERVER.SENDMAIL should always be used when running and administering sendmail.

Configuring Sendmail

The syslog daemon must be configured to log mail events before you attempt to run sendmail. The FOS syslog daemon configuration file is /SYSLOG/PUB/syslog.conf.

Sendmail uses two configuration files -- /etc/mail/ when a user on the local machine is submitting a new e-mail message, and /etc/mail/ for all other functions including the mail daemon. These *.cf configuration files are generated from several *.mc macro files which are expanded by the m4 macro processor program.

If you only need to make simple configuration changes such as uncommenting a statement or changing an existing statement parameter, you can edit the *.cf files directly. But if you are adding major new functionality, you will need to regenerate the *.cf files from the *.mc files. It is good sendmail practice to ALWAYS make configuration changes by editing the *.mc files and then expanding them into their *.cf form.

To regenerate /etc/mail/
  3. shell/iX> cd /SENDMAIL/CURRENT/cf/cf
  4. shell/iX> cp
  5. edit with the bytestream file editor of your choice to make your changes
  6. shell/iX> m4 ../m4/cf.m4 >
  7. shell/iX> cp /etc/mail/
  8. shell/iX> chmod 644 /etc/mail/
To regenerate /etc/mail/
  3. shell/iX> cd /SENDMAIL/CURRENT/cf/cf
  4. shell/iX> cp
  5. edit with the bytestream file editor of your choice to make your changes
  6. shell/iX> m4 ../m4/cf.m4 >
  7. shell/iX> cp /etc/mail/
  8. shell/iX> chmod 644 /etc/mail/
The default copy of /etc/mail/ assumes that your local machine will be delivering e-mail directly to the recipient's mail server. If you instead need to relay all of your outbound e-mail through a central relay server, you can simply edit /etc/mail/ to specify the relay host name, i.e.:

# "Smart" relay host (may be null)

Alternatively you can modify the *.mc file as shown below and then rebuild the *.cf file as explained previously:

define(`SMART_HOST', `')

In addition to the *.cf configuration files, some sendmail features require the use of additional configuration files known as database maps. Database maps consist of ASCII key/value pairs that have been compiled into a binary database format. Maps are created by the makemap command, and can be modified by the editmap command. For example:
  3. shell/iX> /bin/cat - >/etc/mail/access

  5. shell/iX> makemap hash /etc/mail/access </etc/mail/access
An ASCII file called /etc/mail/access is created with an entry that tells sendmail to reject all e-mail sent from the domain. The makemap command is then used to read this ASCII file from stdin via I/O redirection. The first parameter of makemap describes the database format to be used (Berkeley DB hash or btree), and the second parameter is the name of the binary output file that will be created after ".db" is appended to the name.

It is important to note that while /etc/mail/ will refer to the ASCII database file name (i.e. /etc/mail/access), sendmail will actually be reading the data from the binary database filename (i.e. /etc/mail/access.db). So whenever you make a change to ASCII database map file data, you must run makemap to create the binary database *.db file, and then restart sendmail for the changes to be visible.

For more details about database maps, please see "man makemap" and "man editmap".

Starting the mail daemon

Make sure that a syslog daemon is running before you start the mail daemon. To start the FOS syslog daemon, :STREAM JSYSLOGD.PUB.SYSLOG.

Simply :STREAM JDAEMON.PUB.SENDMAIL to start the mail daemon.

Stopping the mail daemon

The following command performed in the POSIX shell while logged on to SERVER.SENDMAIL or any SM user will stop the mail daemon job:

kill $(head -l 1 /etc/mail/

Sending e-mail

The POSIX mailx command can be used to send simple e-mail messages via sendmail. Mailx reads the file /etc/mailx.rc to determine which mail delivery program to use, and the sendmail installation script modifies this file to specify that sendmail shall be used. For more information about mailx, please see "man mailx" or the MPE/iX Shell & Utilities Reference Manual Vol. 1.

To send a message interactively:
  2. shell/iX> mailx

  3. Subject: hello world

    How are you doing?
To send a message from a pipe:
  2. shell/iX> echo "Hi,\n\nHow are you doing?" | mailx -s "hello world"
To send a message from a disk file:
  2. shell/iX> /bin/cat - >/diskfile/containing/message/body

  3. Hi,

    How are you doing?
  4. shell/iX> mailx -s "hello world" </diskfile/containing/message/body
Mailx only gives you limited control over message headers and does not allow you to send attachments. For total control over message formatting and content, you will need to invoke sendmail directly. Sendmail expects you to pass it a fully formatted message via stdin that includes both headers and body text.

To send a message interactively (note that there must be a blank line between the last header and the start of the body text):
  2. shell/iX> /bin/cat - | /SENDMAIL/CURRENT/SENDMAIL

  3. Subject: hello world


    How are you doing?
To send a message with sendmail reading the headers to determine the recipient addresses:
  2. shell/iX> /bin/cat - >message.txt

  3. To:

    Subject: hello world


    How is everybody doing?

  4. shell/iX> /SENDMAIL/CURRENT/SENDMAIL -t <message.txt
Note that sendmail is merely a passive Mail Transport Agent and doesn't give you any message composition functionality to create things such as attachments. If you want to create attachments, you must manually create all of the necessary message headers yourself. These Multipurpose Internet Mail Extensions (MIME) headers are described in RFCs 2045-2049. RFCs are available from many places on the Internet; the official central repository is Some scripting languages contain tools to make MIME content generation easier -- for a Perl example, please see

If the mail daemon isn't running when a local user submits a new e-mail message, the message will be queued in the /var/spool/clientmqueue directory which will be processed the next time the mail daemon job is started. Otherwise, the new message is sent to the mail daemon via TCP port 25, and the daemon queues the message in the /var/spool/mqueue directory and then attempts immediate delivery.

Receiving e-mail

By default, sendmail delivers to local mailboxes by appending new messages to the file /usr/mail/USER.ACCOUNT. Mailbox files will automatically be created if they do not already exist. Each user has direct filesystem read/write access to their own mailbox file. MPE usernames *must* be specified in uppercase when addressing e-mail.

When the mailx program is run without any parameters, it checks to see if there is any new mail in your local mailbox file. A summary of the mailbox contents will be presented, and then you can interact with your messages using a simplistic user interface:
  2. shell/iX> mailx

  3. mailx version MPE/iX Shell and Utilities (A.01.01) May 9 1997 05:04:05 Type ?
    for help.
    "/usr/mail/USER.ACCOUNT": 1 message 1 new
    >N 1 Mon Oct 29 16:48 22/908 test message

  4. ? help
  5.                mailx commands
    type [msglist]                 print messages
    next                           goto and type next message
    edit [message]                 edit message
    from [msglist]                 print header summary of messages
    delete [msglist]               delete messages
    save [msglist] file            save messages by appending to "file"
    undelete [msglist]             remove deletion mark from messages
    reply [msglist]                reply to messages
    preserve [msglist]             prevent messages from going into MBOX
    unread [msglist]               mark messages as unread
    mail [user ...]                mail to specified users
    quit                           quit, updating MAILBOX and MBOX
    xit                            quit, no updates
    headers                        print page of headers summary
    !command                       escape to shell with "command"
    cd [directory]                 change current directory
    list                           complete set of command names     
    The shortest non-ambiguous abbreviation is allowed for commands
    [msglist] or [message] are optional specifiers for message by subject,
    author, number, or type. When unspecified, the current message is assumed.
  6. ? type 1

  7. Message 1:
    From Mon Oct 29 16:48:18 2001
    Received: from ( [])
    by (8.12.1/8.12.1) with ESMTP id f9U0mGPr46792874
    for <>; Mon, 29 Oct 2001 16:48:17 -0800
    Received: from ( [])
    by (8.11.6/8.11.6) with ESMTP id f9U0m8O06413
    for <>; Mon, 29 Oct 2001 16:48:08 -0800
    Message-ID: <>
    Date: Mon, 29 Oct 2001 16:48:08 -0800
    From: John Doe <>
    X-Mailer: Mozilla 4.77 [en] (Win98; U)
    X-Accept-Language: en,pdf
    MIME-Version: 1.0
    To: Jane Doe <>
    Subject: test message
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit

    Hi there!

  8. ? delete 1
  9. ? quit

The aliases database map and .forward files

The aliases database map /etc/mail/aliases describes user ID aliases used by sendmail and is formatted as a series of lines of the form
name: addr_1, addr_2, addr_3, . . .
The name is the name to alias, and the addr_n are the aliases for that name. addr_n can be another alias, a local username, a local filename, a command, an include file, or an external e-mail address.
Local Username

username The username must be available via getpwnam(3). Note that names specified here will be subject to recursive alias lookups; to suppress further alias lookups against this name, prefix the name with a backslash (\) character.

Local Filename

/path/name Messages are appended to the file specified by the full pathname (starting with a slash (/))



A command starts with a pipe symbol (|), it receives messages via standard input. To execute a command with parameters, enclose the entire expression in quotes, i.e. "|command parm1 parm2 parm3".

Include File

:include: /path/name

The aliases in pathname are added to the aliases for name.

External E-Mail Address


An e-mail address in RFC 822 format.
Lines beginning with white space are continuation lines. Another way to continue lines is by placing a backslash directly before a newline. Lines beginning with # are comments.

Aliasing occurs only on local names. Loops can not occur, since no message will be sent to any person more than once.

After aliasing has been done, local and valid recipients who have a ''.forward'' file in their home directory have messages forwarded to the list of users defined in that file.

This is only the raw data file; the actual aliasing information is placed into a binary format in the file /etc/mail/aliases.db using the program newaliases(1). A newaliases command must be executed each time the aliases file is changed for the change to take effect:
  3. shell/iX> newaliases
Each local user can create a .forward file to alter the delivery of their own mail. When delivering mail, sendmail looks for a file called /ACCOUNT/GROUP/.forward where ACCOUNT is the user's MPE account and GROUP is the user's MPE home group. If this file is found, the contents are parsed as if they were the right-hand side of an aliases file entry. Consider the following example .forward file:


This will cause sendmail to deliver one copy of an email message to the user's normal mailbox (\USER.ACCOUNT), and another copy of an email message will be piped to the vacation autoresponder program.

Access_db feature

The access database map allows you to accept or reject e-mail based on the message envelope and connecting mail server host name. For example:
  3. shell/iX> /bin/cat - >/etc/mail/access

  5. shell/iX> makemap hash /etc/mail/access </etc/mail/access
This will reject all e-mail originating from the domain

For more information about the access_db feature, please see /SENDMAIL/CURRENT/cf/README.

Domaintable feature

The domaintable database map is used to rewrite domain names in e-mail headers. You might find this useful if your company was acquired by a different company and you were forced to change your email domain names. For example:
  3. shell/iX> /bin/cat - >/etc/mail/domaintable

  5. shell/iX> makemap hash /etc/mail/domaintable </etc/mail/domaintable
All occurrences of in e-mail headers would be rewritten to

For more information about the domaintable feature, please see /SENDMAIL/CURRENT/cf/README.

Genericstable feature

The genericstable database map is used to rewrite both the user and domain portions of e-mail addresses in outgoing e-mail headers. For example:
  3. shell/iX> /bin/cat - >/etc/mail/genericstable

  5. shell/iX> makemap hash /etc/mail/genericstable </etc/mail/genericstable
All e-mail sent by USER.ACCOUNT on the local host would have the sender address(es) rewritten as Note that domains being modified by genericstable must be added to /etc/mail/ class {G}.

For more information about the genericstable feature, please see /SENDMAIL/CURRENT/cf/README.

Mailertable feature

The mailertable database map is used to override the default mail routing behavior in /etc/mail/ You might find this useful if you needed to route e-mail for certain domains through specific e-mail relays. For example:
  3. shell/iX> /bin/cat - >/etc/mail/mailertable

  4. .bitnet
  5. shell/iX> makemap hash /etc/mail/mailertable </etc/mail/mailertable
All mail addressed to hostnames ending in ".bitnet" would be relayed via the host

For more information about the mailertable feature, please see /SENDMAIL/CURRENT/cf/README.

Virtusertable feature

The virtusertable database map is used to remap incoming e-mail addresses in order to facilitate multiple virtual e-mail domains on the same machine. This is very similar to how aliasing works, except that you can also specify domain names in addition to user names. For example:
  3. shell/iX> /bin/cat - >/etc/mail/virtusertable

  5. shell/iX> makemap hash /etc/mail/virtusertable </etc/mail/virtusertable
All e-mail addressed to will be delivered to user INFO.BAR, and all e-mail addressed to will be delivered to user INFO.FOO. Note that all domains used in the map keys must also be present in /etc/mail/local-host-names and that your DNS server(s) have been configured with MX entries that route e-mail for those domains to your local machine.

For more information about the virtusertable feature, please see /SENDMAIL/CURRENT/cf/README.

MPE/iX implementation issues

The following sendmail features have not been implemented on MPE/iX:
  • LDAP support
  • TLS/SSL encrypted e-mail transport
  • SASL secure authentication
  • Mail filtering
  • Optional chroot()-based security features
  • Optional nice()-based dispatching priority adjustments
The following sendmail features work a bit differently on MPE/iX than they do on other operating systems:
  • Sendmail programs that read terminal input by using stdin will echo one character per line and not recognize CR characters or :EOD properly. The workaround is to redirect stdin to either a pipe or a disk file, i.e.:

    shell/iX> /bin/cat - | makemap hash mymap
    shell/iX> makemap hash mymap <diskfile
  • Sendmail's "background" DeliveryMode on MPE/iX is actually a hybrid between "background" and "interactive". A background process will be started to deliver the mail, but if it has not finished by the time the parent process is ready to terminate, the parent process will wait for the background process to finish.
  • Symlinks such as /SENDMAIL/CURRENT/bin/mailq that point to the main sendmail NMPRG must be invoked from the POSIX shell in order to work properly because invoking them from the CI doesn't initialize ARGV[0] with the name of the symlink. If you need to invoke this symlinked functionality from the CI, you will have to specify the sendmail parameters that invoked the desired functionality, i.e. :XEQ /SENDMAIL/CURRENT/SENDMAIL -bp.


  • Always check syslog when you have problems with sendmail!
  • If you don't see any syslog events being logged:
    • Verify that the syslog daemon is running.
    • Verify that all files used by the syslog daemon have the correct file ownership and permissions.
    • Verify that syslog has been configured to log mail events.
  • If syslog or e-mail message headers show strange timestamps, verify that the TZ environment variable is set correctly.
  • If syslog shows DNS lookup failures:
    • Run the /SENDMAIL/CURRENT/bin/dnscheck script to verify that DNS is configured properly on your local machine.
    • Check with your firewall administrator to make sure your local machine is allowed to talk to your DNS server(s).
  • If syslog shows connection failures for remote mail servers, check with your firewall administrator to make sure your local machine is allowed to talk to those remote mail servers. If you are not allowed to talk directly to remote mail servers, you will need to configure a smart host mail relay in /etc/mail/
  • Very long delays when a local user is submitting a new e-mail message are indicative of DNS problems. Check syslog for any errors, and run the /SENDMAIL/CURRENT/bin/dnscheck DNS configuration validation script.
  • If local users are submitting new messages that aren't being delivered:
    • Verify that the mail daemon job is running. If the mail daemon is not running, newly submitted messages are queued in the /var/spool/clientmqueue directory. The mail daemon will process these queued messages the next time it is started.
    • The mail daemon's delivery queue is the /var/spool/mqueue directory. Users with proper security can examine the queue files directly, or run /SENDMAIL/CURRENT/bin/mailq to get a formatted queue listing.
  • If remote users are sending messages to the local machine that aren't being delivered:
    • Check syslog to see if the remote mail server is able to connect to the local machine. If you do not see any connection attempts:
      • Talk to your firewall administrator to determine if remote machines are allowed to send e-mail to your local machine.
      • Talk to your network administrator to verify that your local machine's DNS entries should be visible to the remote mail server.
    • Verify that the remote users are using valid user addresses (aliases or uppercase USER.ACCOUNT) and hostnames for your local machine.
  • If you make a sendmail configuration change but the new configuration doesn't appear to take effect:
    • You must always stop and restart the mail daemon when making *.cf configuration changes.
    • If you changed an ASCII database map file, you must run makemap or editmap to create the corresponding *.db binary database file.
    • If you changed the ASCII /etc/mail/aliases file, you must run newaliases to create the binary /etc/mail/aliases.db database file.

For further information

Top    JazzInfo    Hosted by    email 3kRanger    Updated