Skip Headers
Oracle® Communications Billing and Revenue Management Email Manager
Release 7.5

E16703-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
PDF · Mobi · ePub

3 Configuring Email Manager and sendmail

This chapter describes how to set up the Oracle Communications Billing and Revenue Management (BRM) Email Manager and sendmail. To set up the Email Manager and sendmail, you might need to configure the following:

For information about editing configuration files, see "Using Configuration Files to Connect and Configure Components" in BRM System Administrator's Guide.

Configuring the PIN Popper

To configure the PIN Popper, you must perform the following tasks:

Note:

PIN Popper is based on QPopper (version 2.53) from Qualcomm. Support information for QPopper is located on the QPopper support Web site. Direct all support questions to this site.

Modifying the PIN Popper Configuration File

The default location for the PIN Popper configuration file is BRM_Home/apps/popper/pin.conf.

Table 3-1 displays the PIN Popper entries:

Table 3-1 PIN Popper Entries

Entry Use Description

domain

Optional

The default mail domain for this system. By default, the BRM system stores email logins as user@domain. Some popper clients only pass in the user part of an email name. For most cases, this entry adds a default domain that the popper appends to the user name.

mailuser

Required

The UNIX login name used by the PIN Popper. The default is pin. This entry is stored in the system password file.

maildir

Required

The directory where users' mail files are stored.

workdir

Optional

The directory where temporary mail files are stored. The default is maildir.


Configuring the PIN Popper Startup

The PIN Popper program should be run as one of the standard Internet services which are controlled by inetd server process on your BRM server. See the inetd(1M) manual page in your UNIX system documentation for details.

  1. To start the popper daemon on your system, add the following line to your /etc/inetd.conf file:

    pop3 stream tcp nowait root BRM_Home/bin/popper 
    

    Note:

    This line differs from the Qualcomm installation procedure. (The PIN Popper is based on the Qualcomm QPopper.)

    By default, PIN Popper is compiled with DEBUG turned on. You can add tracing, but the output log can quickly use a large amount of memory. Add the following switches to your /etc/inetd.conf file for tracing:

    BRM_Home/bin/popper -s
    
    pop3 stream tcp nowait root BRM_Home/bin/popper BRM_Home/bin/popper -s -d -t /var/portal/7.5/popper/popper.log
    

    Note:

    To compile popper with DEBUG turned off, remove the -enable-debugging option from the following line in the popper Makefile in the BRM_Home/source/apps/popperdirectory to remove tracing capabilities:
    sh configure --enable-servermode --enable-debugging
    
  2. Verify that the /etc/services file on your system has a pop3 entry.

    This entry assigns a port on your system (port 110 is standard) to the popper service.

  3. If your services file doesn't contain a pop3 entry, add the following line to the file:

    pop3 110/tcp
    
  4. To force inetd to reread the configuration file, send a SIGHUP signal to the inetd process.

    kill -hup <inetd processID>
    

    All connections to port 110 of your system cause inetd to spawn a popper process to handle each connection.

Verifying Your PIN Popper Setup

When setup is complete, inetd starts the PIN Popper automatically each time a connection is made to the pop3 port on your system.

To verify that the PIN Popper has started, use telnet to connect to the pop3 port on your system and verify that the popper responds. The following line indicates a successful connection:

telnet <host> 110 +OK QUALCOMM Pop server derived from UCB (version 2.1.4-R3)...starting

Configuring the M4 Macro Files in sendmail

The directory structure that sendmail uses for example configuration code are designed to use a post-V7 version M4 macro processor.

Table 3-2 shows the files and subdirectories under the configuration directory of the sendmail configuration file.

Table 3-2 Files and Subdirectories for Sendmail Configuration File

File Description

README

Configuration instruction file.

m4

General support routines that are not normally changed.

cf

Configuration files. The files have .mc suffixes, and must be run through M4 macro processor. The resulting files each have a .cf suffix.

ostype

Definitions describing a particular operating system type. These files should always be referenced using the OSTYPE macro in the .mc file.

domain

Definitions describing a particular domain, referenced using the DOMAIN macro in the .mc file. These definitions are site dependent (see Table 3-4).

mailer

Descriptions of mailers. These descriptions are referenced using the MAILER macro in the .mc file (see Table 3-5).

sh

Shell files used when building the .cf file from the .mc file in the cf subdirectory.

feature

These files hold special orthogonal features. They should be referenced using the FEATURE macro.

hack

Local hacks. These can be referenced using the HACK macro.

siteconfig

Site configuration information, such as tables of locally connected UUCP sites.


Installing M4 Macro Files

You can enforce that your site-specific customizations to sendmail always use M4 files. If you've always used M4 files or you are configuring the sendmail configuration file for the first time, do the following:

  1. Copy your M4 files to the appropriate cf subdirectories in the sendmail build directory hierarchy.

  2. Run the M4 macro processor in the cf subdirectory as described in the README file.

    A new.cf file is created.

  3. Save a copy of your sendmail configuration file as a backup file. Copy the new.cf file as your sendmail configuration file.

If you have sendmail installed and site-specific changes have been made directly to the sendmail configuration file, you have two options:

To run M4:

  1. Make a copy of the cf subdirectory tree at the same location as the cf directory, for example, mycf.

  2. Remove all files from the cf, domain, feature, hack, mailer, ostype, and siteconfig subdirectories in mycf that are not referenced by your M4 files.

  3. Copy your M4 files into the appropriate subdirectories in mycf.

  4. Run the M4 macro processor in the cf subdirectory.

    If the M4 processor can't find a file it needs, it reports an error. Copy the required file from the /cf directory. Once all files are available, M4 creates a newcf file.

  5. Save a copy of your sendmail configuration file as a backup file. Copy the specific segments from the generated .cf file into your customized sendmail configuration file.

Testing sendmail

First, test the operation of sendmail without Email Manager. If there are no problems during the test, proceed to test the integration of Email Manager with sendmail.

Configuration Instructions and Example Files

The README file shipped with the sendmail source files includes instructions for configuring the M4 macro files.

The Email Manager includes three example configuration files located in the BRM_Home/apps/pinapps/examples/m4 directory:

  • cf/portal-example.m4

  • mailer/portal-example.m4

  • domain/portal-example.m4

Note:

These files can't be used without modification.

Table 3-3 describes the cf/portal-example.mc file.

Table 3-3 cf/portal-example.mc

Entry Description

VERSIONID(`@(#)portal-example.mc 1.0 (Portal Software, Inc.) 06/08/1999')

Signature written to the sendmail configuration file.

OSTYPE(solaris2)dnl

Referring to ../ostype/solaris2.m4. Change to match your implementation.

DOMAIN(portal-example)dnl

Referring to ../domain/portal-example.m4. Change to match your implementation.

MAILER(portal-example)dnl

Referring to ../mailer/portal-example.m4. Change to match your implementation.

LOCAL_RULE_0

Add the following lines to the end of ruleset 0 to invoke pinmail as the local mailer when the address is resolved to user@domain.

R$*<@>$* $#pinmail $: $1<@>$2

### local mailer. The three parts are separated by tab characters.


Table 3-4 describes the mailer/portal-example.m4 file.

Table 3-4 mailer/portal-example.m4

Entry Description

VERSIONID(`@(#)portal-example.m4 1.0 (Portal Software, Inc.) 06/08/1999')

Signature written to the sendmail configuration file.

ifdef(`PIN_MAILER_PATH',, `define(`PIN_MAILER_PATH', BRM_Home/bin/pin_mailer)')

Set the value from the environment. If no value is found, set the value to the default location of the pin_mailer executable.

ifdef(`PIN_MAILER_FLAGS',, `define(`PIN_MAILER_FLAGS', DEFblS)')

ifdef(`PIN_MAILER_ARGS',, `define(`PIN_MAILER_ARGS', pin_mailer $u)')

If these values aren't set in the environment, set them to reasonable values. See "Configuring the PIN Mailer" for details.

define(`_LOCAL_', ifdef(`confLOCAL_MAILER', confLOCAL_MAILER, `pinmail'))

Defines the mailer.

Mpinmail, P=PIN_MAILER_PATH, F=PIN_MAILER_FLAGS, A=PIN_MAILER_ARGS

Set up Pin Mail as the local mailer using the values of these variables.


Table 3-5 describes the domain/portal-example.m4 file.

Table 3-5 domain/portal-example.m4

Entry Comments

VERSIONID(`@(#)portal-example.mc 1.0 (Portal Software, Inc.) 06/08/1999')

Signature written to the sendmail configuration file.

define(`confFORWARD_PATH', `$z/.forward.$w:$z/.forward')dnl

define(`confCW_FILE', `-o /etc/sendmail.cw')dnl

define(`confDONT_INIT_GROUPS', True)dnl

Redefine M4 variables for use in your feature files.

FEATURE(redirect)dnl

FEATURE(use_cw_file)dnl

FEATURE(stickyhost)dnl

Refer to your M4 feature files located in ../feature.


Configuring the PIN Mailer

For PIN Mailer configuration, you'll have to find and edit a configuration file.

Using the PIN Mailer with sendmail

You must edit the sendmail configuration file on your system (typically /etc/mail/sendmail.cf) by doing the following:

Note:

Before editing the sendmail configuration file, read "Configuring the M4 Macro Files in sendmail".
  • Add a mailer definition line to the Mailer Definitions section of your sendmail configuration file. For example:

    Mpinmail, P=BRM_Home/bin/pin_mailer,F=DEFblS,A=BRM_Home/bin/pin_mailer $u
    Mpinmail, P=BRM_Home/bin/pin_mailer, F=DEFblSA/|, S=10/30, R=20/40, A=BRM_Home/bin/pin_mailer $u
    
  • Add a line to define the behavior for parsing an email address before sending it to the PIN Mailer. For example:

    R$*<@>$*   $#pinmail  $:  $1<@>$2 
    

    Note:

    There is a tab between R$*<@>$* and $#pinmail.

Table 3-6 describes the flags in the mailer definition line (F=DEFblS):

Table 3-6 Flags in Mailer Definition

Flag Description

D

PIN Mailer requires a Date: header (usually not required).

E

Change the extra From to >From.

F

PIN Mailer requires a From: header.

b

Add a blank line at the end of a message if needed.

l

PIN Mailer is local.

S

Do not reset userid.


This replaces any other mail delivery agent entries, and requires that all addresses are converted to user@domain format before being sent to the mail delivery agent. sendmail then forks a pin_mailer each time a sendmail connection is made and mail to user@domain is processed.

For information on starting and stopping BRM daemons, see "Starting and Stopping the BRM System" in BRM System Administrator's Guide.

PIN Mailer Configuration File

The default location for the PIN Mailer configuration file is BRM_Home/apps/pin _mailer/pin.conf.

Sample PIN Mailer pin.conf File

# @(#)pin_conf 6 Sun Sep 12 21:07:55 1999 # Sample pin.conf file for PIN's Mailer (Version 7.5) 
# (see pin_conf() manpage for format discussion)
- napcm_ptrip<hostname>11960
- userid0.0.0.1 /service/pcm_client 1 
- nap   login_type      1# type 1 is with password 
- nap   login_name      <name>.<db_no> # e.g.: loginname.0.0.0.1 
- nap   login_pw        <password> 
- pin_mail domain <mail_domain_name>
- pin_mail mailuser pin
- pin_mail maildir /var/mail
- pin_mail workdir BRM_Home/apps/pin_mailer
- pin_mail logfile /var/portal/7.5/pin_mailer/pin_mailer.pinlog
- pin_mail loglevel 2

Common Connection Entries

Table 3-7 describes the common connection entries used in the pin.conf file. For more information, see "Using Configuration Files to Connect and Configure Components" in BRM System Administrator's Guide.

Table 3-7 Common Connection Entries

Entry Use Description

cm_ptr

Required

Pointer to the CM/CMMP

userid

Required

Database number

login_type

Required

Login type, with or without a password

login_name

Required

Login name

login_pw

Required

Login password


Table 3-8 describes the PIN Mailer entries used in the pin.conf file.

Table 3-8 Pin Mailer Entries

Entry Use Description

mailuser

Required

The UNIX login name used by the PIN Mailer. The default is pin. This entry is stored in the system password file.

maildir

Required

The directory where users' mail files are stored.

workdir

Optional

The working directory for the mail system, that is, the PIN Mailer portion of the mail system.

logfile

Required

The full path name for the logfile. The default is /var/portal/7.5/pin_mailer/pin_mailer.pinlog.

loglevel

Optional

The error reporting level. The default value logs all errors regardless of type.


Starting PIN Mailer

When configuration is complete, PIN Mailer is started automatically as needed by your system's sendmail daemon.

Customizing Email Manager

The Email Manager opcodes perform two functions:

Customizing Email Login Authorization

To authorize logins, Email Manager uses the PCM_OP_MAIL_LOGIN_VERIFY opcode. This opcode calls the PCM_OP_ACT_FIND_VERIFY opcode, and specifies that the authorization request is for an email service login.

The PCM_OP_ACT_FIND_VERIFY opcode calls the PCM_OP_ACT_POL_SPEC_VERIFY opcode, which authorizes the login. You can use the PCM_OP_ACT_POL_SPEC_VERIFY opcode to customize how the login is authorized.

By default, the authentication checks the following:

  • Login name.

  • Password.

  • Credit balance is equal to or greater than 0.

Customizing Email Delivery Authorization

To authorize email delivery, Email Manager uses the PCM_OP_MAIL_DELIV_VERIFY opcode. This opcode calls the PCM_OP_ACT_FIND_VERIFY opcode, and specifies that the authorization request is for an email delivery.

The PCM_OP_ACT_FIND_VERIFY opcode calls the PCM_OP_ACT_POL_SPEC_VERIFY opcode, which authorizes the mail delivery. You can use the PCM_OP_ACT_POL_SPEC_VERIFY opcode to customize how the mail delivery is authorized.

By default, the authentication checks if the email service is active.