DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Managing mail with MMDF

Specifying host-based authorization

MMDF provides authorization checks on the next ``hop'' host in the address route. If someone specifies a route through your host, MMDF on your host can authorize the next hop in that route. In other words, MMDF does not perform authorization based on the final destination unless the final destination is the next hop.

Configuring host-based authorization can help control unsolicited email, or ``spam''. In particular, it prevents your system from being used as a third-party mail relay, an intermediate site between a sender and a recipient.

To control authorization on a per-host basis:

  1. Log in as mmdf and declare a table in the file /usr/mmdf/mmdftailor using the MTBL keyword. The table will specify the privileges for all hosts that do not belong to the network. For information on editing mmdftailor, see ``Editing MMDF configuration files manually'' and the mmdftailor(F) manual page.

    This example declares the table world-auth:

       MTBL "world-auth", file="authinfo/world"
    
    The file parameter specifies that world-auth is stored in /usr/mmdf/table/authinfo/world. You will create the actual table later in this procedure.

  2. Define two channels using MCHN definitions in /usr/mmdf/mmdftailor: one channel for the hosts that belong to the network and one for the hosts that do not belong. Use one or more of these parameters to specify how the information in the world-auth table is to be utilized:

    indest
    When mail is sent to a particular host or via a particular channel, the table determines whether the source host is allowed to send mail to the destination host or via that channel. Example format: MCHN indest="world-auth"

    outdest
    When mail is sent to a particular host, the table verifies that the source host or channel is allowed to send mail to the destination host.

    insrc
    When mail arrives from a particular host (the source host), the table verifies that that host is allowed to send mail to the destination host by authorizing either the destination host or the channels used to access the destination host.

    outsrc
    When mail arrives from the source host via a particular channel, the table determines if that source host or channel is allowed to send mail to the destination host.

    For example, define a channel (called localnet in this example) for all hosts on the local network:

       MCHN localnet, auth=free, show="LOCALNET Delivery",
       	ap=822, mod=imm
    
    The ``auth=free'' authorization setting is the default; you do not have to specify it explicitly as in this example. See ``Specifying channel authorization levels''.

    Define a channel (called world in this example) for all the hosts not in the localnet network:

       MCHN world, auth=inblock, indest="world-auth",
       	show="WORLD Delivery", ap=822, mod=imm
    
    In this case, anyone can send mail out on the world channel, but MMDF checks the world-auth table to authorize the destination of mail arriving on this channel.

  3. Create a channel table file in /usr/mmdf/table for each of the channels you just created. In the above example, you would create the files world.chn and localnet.chn. In those files, include descriptions of each host accessed via that channel. See ``Channel tables'' for more information.

  4. Create the world-auth table (the file /usr/mmdf/table/authinfo/world in our example). Include lines like these:
       world:
       local:
       localnet:	moocow.uucp
    
    The entries on the left side of the authorization table specify that if the destination host for a message is on either the world or local channels, MMDF authorizes anyone using the world channel as an input channel to send mail.

    The entry on the right side of the localnet channel entry specifies the hosts and channels that are authorized to send outgoing mail using the localnet channel. In this case, moocow.uucp is the only machine allowed to pass mail into the localnet network.

  5. Rebuild the hashed database using the information in ``Rebuilding the hashed database''.

Next topic: Specifying user-based authorization
Previous topic: Routing-based authorizations

© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 26 May 2005