A lot of thanks to all who replied.
Problem description: need to hide internal lognames and domain names from
the world and assign external addresses shown to Internet.
Solution is:
1. Define major relay mailer is inet (new one)
2. Define external domain name
DDshown.to.world.domain
3. Specify new mailer for outgoing to Internet mail
############################################################
#####
##### Internet Mailer specification
##### Hide lognames and local domain name
#####
Minet, P=[TCP], F=msDFMuCX, S=14, R=24, A=TCP $h
S14
Rlogname1 Showntoworld.Name1
Rlogname2 Showmtoworld.Name2
# (and so on, i have few users on machine, so decided
# to rewrite names inside of sendmail.cf)
R$*<@$+>$* $@$1<@$D>$3 already ok
R$=D $@$1<@$D> tack on my domain
R$+ $@$1<@$D> tack on my mbox hostname
4. Create aliases for incoming mail in /etc/aliases
In message <199506291838.MAA19397@suod.cs.colorado.edu> Todd C. Miller
writes:
>I grabbed the following from comp.mail.sendmail some time ago. It
>works quite well but you need to be running sendmail 8.6.x
> - todd
>------- Forwarded Message
>Newsgroups: comp.mail.mh,comp.mail.sendmail
>Path: csnews!boulder!agate!howland.reston.ans.net!pipex!sunic!EU.net!news.funet.fi!news.lut.fi!grendel.lut.fi!Kimmo.Suominen
>From: Kimmo.Suominen@lut.fi (Kimmo Suominen)
>Subject: Re: mh and sendmail's userdb
>In-Reply-To: eric@CS.Berkeley.EDU's message of 13 Apr 1994 01:43:10 GMT
>Message-ID: <KIMMO.SUOMINEN.94Apr16115353@grendel.lut.fi>
>X-Attribution: Kim
>Sender: kim@tac.nyc.ny.us (Kimmo Suominen)
>Organization: Lappeenranta University of Technology, Finland
>Disclaimer: These are my opinions unless otherwise stated
>References: <1994Mar28.131048.9263@wg.estec.esa.nl> <2ofine$eh2@agate.berkeley.edu>
>Date: Sat, 16 Apr 1994 08:53:52 GMT
>Lines: 43
>Xref: csnews comp.mail.mh:4201 comp.mail.sendmail:10385
>>>>>> "Eric" == Eric Allman <eric@CS.Berkeley.EDU> writes:
>Eric> MH inserts its own From: line in the message before it
>Eric> submits it to sendmail. Sendmail believes an existing
>Eric> From: line unless it is exactly the same as what it would
>Eric> have generated itself, in which case it treats it as a
>Eric> candidate for rewriting. There may be some way to compile
>Eric> MH to avoid putting in the From: line.
>This is actually only a problem when you do masquerading with
>sendmail. I wish it would rewrite all names in class w. But
>here is what I use in my m4-files for sendmail.cf:
>define(`GENERIC_TABLE', nis mail.generics)dnl
>LOCAL_CONFIG
>ifdef(`GENERIC_TABLE',
>`Kgenerics' GENERIC_TABLE
>)dnl
>POPDIVERT
>LOCAL_RULE_1
>ifdef(`GENERIC_TABLE',
>R$- $: $>3 $(generics $1 $)
>R$- < @ $=w . > $: $>3 $(generics $1 $)
>)dnl
>POPDIVERT
>It provides IDA-style outgoing address rewriting, and it will
>also rewrite the envelope address. The database can be any
>supported type, not just 'nis'.
>The database has entries like
>If the right hand side address does not have a domain added,
>then the local domain will get added. The left hand side cannot
>be anything else than a single word with these rules, but all I
>need to do is map usernames anyway.
>- --
> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
>( Kimmo Suominen "That's what I think" )
>( Lappeenranta University of Technology Kimmo.Suominen@lut.fi )
> ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>------- End of Forwarded Message
In message <199506280935.CAA07907@stewpot.mazama.com> Christopher A. S.
writes:
>If you use sendmail V8 it easly using the userdb option..
>--
>----------------------------------------------------------------------
>Christoher A. Stewart | allan@eskimo.com
>Mazama Software Labs. | allan@mazama.com
In message <Pine.SOL.3.91.950628111619.18119A-100000@us8> Damian Murphy
writes:
>Anatoly,
>> I need to hide lognames and hostnames from the world, i.e.
>> create e-mail addresses such as Firstname.Lastname@external.domain.
>>
>> I can create aliases in aliases database on mail relay host, for example
>>
>> Firstname.Lastname@external.domain logname@internal.domain
>>
>> But what ruleset in sendmail.cf to edit to rewrite "From:" field only?
>> Or may be there are some ready to use software for such a things?
>All you ask can be done through sendmail.
>First you wish to divise two mail handlers. One for internal mail and one
>for external mail. e.g.
>Mether, P=[TCP], F=msDFMuCX, S=11, R=21, A=TCP $h
>(for intenal mail) and
>Minet, P=[TCP], F=msDFMuCX, S=14, R=24, A=TCP $h
>(for external/internet mail)
>The first to do internal mail and the other to do external mail.
>You must have your domain defined.
>DDkamaz.kazan.su
>Then the following rule removes by internal domains and places my
>external domains.
>S14
>R$*<@$+>$* $@$1<@$D>$3 already ok
>R$=D $@$1<@$D> tack on my domain
>R$+ $@$1<@$D> tack on my mbox hostname
>Note it is attached to the from rewriting rule of mail headed for the
>internet.
>You could enhance this rule by using database macros similar to the
>following which uses a file called /etc/mailmaps to map user names to
>external names.
>Kmappings dbm /etc/mailmaps
>S14
>R$*<@$+>$* $@$:$(mappings $1 $)<@$D>
>R$=D $@$:$(mappings $1 $)<@$D>
>R$+ $@$:$(mappings $1 $)<@$D>
>The format of the file then might be
>smithg Greg.Smith
>wymanb Bill.Wyman
>This database is best created in a script as this can create the opposite
>database for the reverse translations.
>These database macros can be enhanced but were left simple to allow
>porting to multiple platforms.
>Somewhere I have seen a version of makedbm that creates both the standard
>and the reverse database.
>Hope this helps
>Damian
>+-------------------+-----------------------------------+
>| Damian Murphy | Board of Senior Secondary School |
>| Ph 61-7-864 0341 | Studies |
>| Fax 61-7-832 1329 | email: damian@bssssq.edu.au |
>| |
>| 'Dont put off for tomorrow what you can forget about |
>| entirely' - Borderline's "The wisdom of Confushion" |
>+-------------------+-----------------------------------+
>From: "Christopher A. Stewart" <allan@mazama.com>
>If you use sendmail V8 it easly using the userdb option..
>--
>----------------------------------------------------------------------
>Christoher A. Stewart | allan@eskimo.com
>Mazama Software Labs. | allan@mazama.com
In message <9506281624.AA01857@swede.oaktech.com> Steven Ho writes:
>----------
>X-Sun-Data-Type: text
>X-Sun-Data-Description: text
>X-Sun-Data-Name: text
>X-Sun-Content-Lines: 59
>Anatoly,
>Use the reverse aliases feature in sendmail.cf. You should create aliases
>on the mail gateway like the following:
>Firstname.Lastname: logname@hishost
>(hishost is either a hostname or a subdomain name)
>The second rule in ruleset 22 will do the translation for you.
>The following is an example,
>1. From sendmail.main.cf:
>-----------
># map containing the inverse of mail.aliases
>DZmail.byaddr
>S22
>R$*<@LOCAL>$* $:$1
>R$-<@$-> $:$>3${Z$1@$2$} invert aliases
>R$*<@$+.$*>$* $@$1<@$2.$3>$4 already ok
>R$+<@$+>$* $@$1<@$2.$m>$3 tack on our domain
>R$+ $@$1<@$m> tack on our domain
>----------
>2. Create the alias like the following:
>myhost #[36] ypmatch owner-foo aliases
> uucp@testhost
>myhost #[37] sendmail -C/etc/sendmail.ddn.cf -bt -d21.12
>Version 4.1
>ADDRESS TEST MODE
>Enter <ruleset> <address>
>> 22,4 uucp@testhost
>rewrite: ruleset 3 input: "uucp" "@" "testhost"
>-----trying rule: $* "<" ">" $*
>----- rule fails
>rewrite: ruleset 3 returns: "uucp" "<" "@" "testhost" ">"
>rewrite: ruleset 22 input: "uucp" "<" "@" "testhost" ">"
>...... (lines deleted)
>rewrite: ruleset 22 input: "uucp" "<" "@" "testhost" ">"
>-----trying rule: $* "<" "@" "LOCAL" ">" $*
>----- rule fails
>-----trying rule: $- "<" "@" $- ">"
>-----rule matches: $: $> "3" ${ "Z" $1 "@" $2 ${
>-----callsubr 3
>rewrite: ruleset 3 input: "owner-foo"
>-----trying rule: $* "<" ">" $*
>----- rule fails
>.......(lines deleted)
>rewrite: ruleset 4 returns: "owner-foo" "@" "mydomain" "." "com"
>>
>Hope this helps,
>Steven Ho
>sho@oaktech.com
In message <9506281453.AA06025@kfir.East.Sun.COM> Hal Stern -
Distinguished Systems E. writes:
>----------
>X-Sun-Data-Type: text
>X-Sun-Data-Description: text
>X-Sun-Data-Name: text
>X-Sun-Charset: us-ascii
>X-Sun-Content-Lines: 6
>it's done by ruleset 22 in the standard sun sendmail.cf, but
>you need to make sure your mailer that goes "outside" uses
>that ruleset for sender rewriting. the attached has details.
>--hal
>----------
>X-Sun-Data-Type: default
>X-Sun-Data-Description: default
>X-Sun-Data-Name: smadv.ms
>X-Sun-Charset: us-ascii
>X-Sun-Content-Lines: 503
>''' @(#)smadv.ms 1.2 10/14/93 16:26:29 /tmp_mnt/home/stern/pubs/sunworld/dec93/SCCS/s.smadv.ms
>/sys.admin: Rule, set, and match
>By Hal Stern
>Deck:
>Correct, intuitive, gracious mail delivery carries significant value.
>The cost to you is in learning how to extract this grade of service
>from sendmail.
>Pullquote:
>Sendmail really isn't that horrible. There's a price you pay for
>flexibility: complexity.
>Mail delivery is at least part black art because you're forced
>to surmise what users \fIintended\fR to do from the way their
>mail bounces. There are two ways to make your life as postmaster
>easier: establish and conform to uniform rules for sending
>mail to your users, and try to parse every imaginable address
>that your users attempt to use as a valid destination. If
>the mail path in is clearly marked, and the path out is wide and
>forgiving, you're likely to make most people happy most of the
>time. Reaching this state of near-enlightenment, though,
>will make you wish you had paid more attention in those
>spring semester courses in automata theory and compiler construction.
>.LP
>Last month we talked about what sendmail does and how it behaves
>and misbehaves with other parts of the system. This month,
>we'll descend a bit deeper into the guts of sendmail, and
>decipher its address parsing and rewriting
>rules. Address manipulation is where the real power of sendmail lies.
>A well-written sendmail configuration will
>redirect mail to several mail hubs, route mail to any number
>of delivery agents, enforce standardized user naming for
>outgoing mail, and hide any interior system administration
>atrocities over which you have little control. We'll examine
>a sendmail configuration file in some detail, and then review
>the basics of address parsing and rewriting rules.
>Sample rules that solve common problems of name hiding
>and alias inversion tie theory to practice.
>.SH
>Declaration of independents
>.LP
>Sendmail doesn't read its configuration file from top to bottom,
>unlike many other utilities that do a once-through consumption
>of their start-up data. The configuration file,
>sendmail.cf, is more like a piece of source code that defines
>subroutines and variables. Subroutines are executed in
>a particular order, and variables control the flow of execution
>within the code segments. If you think of the sendmail configuration
>as 90 percent parser and 10 percent magic,
>you'll maintain the proper perspective.
>.LP
>To the uninitiated, sendmail.cf is several hundred lines of data that
>could quite possible be compressed EBCDIC. Don't let the representations
>intimidate you, just because they're written in the language of
>compiler hounds. Every sendmail.cf file contains definitions,
>header declarations, and rewriting rules. Like source code, the
>rules contain logic and subtlety, and form the bulk of
>the file contents.
>.LP
>Every line has a type that uniquely identifies its purpose. The
>first character on a line is the type field, followed by space-separated
>values. Tabs and the pound sign # begin comments. The non-trivial
>types are:
>.IP D
>Define a variable. The second character is an alphabetic variable name,
>yielding only 52 unique variables within sendmail. Variables
>contain a single value, which might be a string containing embedded
>spaces. For example, to define the variable y as "Big Data
>Group" use the line:
>.DS
>DyBig Data Group
>.DE
>.IP C
>Define a class. A class is a multivalued variable, like an
>argument vector in the shell. How to access members of a class is
>discussed below. A class z that contains names
>"thud," "plop," and "splatter" is defined like this:
>.DS
>Dzthud plop splatter
>.DE
>.IP F
>Build a class from a file. This type offers a nice
>separation of control information
>in the sendmail configuration file from the data values. You
>can modify a configuration without editing dozens of sendmail.cf
>files if all sendmail configurations use the same, shared
>class-definition files. To extract the contents of class z
>from a file, use:
>.DS
>Fz/usr/local/share/silly-hosts
>.DE
>.IP H
>Header definition. Don't touch these lines. Most vendors go
>to great pains to make the default headers comply with the Request
>For Comments (RFCs), particularly RFC 822, governing header
>formats and values. Adding new headers or changing existing ones
>may break other mailers.
>.IP P
>Establish message precedence. A concept as clever as it is
>unused.
>.IP M
>Define a mailer. Once sendmail is done rewriting the
>recipient addresses, it chooses a mailer to deliver the
>message. Valid mailers are defined in M type clauses, which
>include flags to be passed to the mailer and the additional
>sendmail rewriting rules that should be used for post-processing
>of sender and recipient addresses.
>> HAL: mayhaps we can include an example here?
>[DAVID: good idea. insert, also, let's insert a rewriting rule
>example below
>A typical mailer definition is:
>.DS
>Muucp, P=/usr/bin/uux, F=msDFMhuU, S=13, R=23, A=uux - -r $h!rmail ($u)
>.DE
>which defines a mailer named "uucp", gives the program (command) to run it,
>a set of flags specifying how the mailer behaves and what kind of
>arguments it handles, sender and recipient rewriting rules, and an argument string.
>The arguments are filled in with the hostname ($h) and username ($u) determined
>by the address parsing described in gory detail below.
>*** end of insert]
>.IP S
>Start a ruleset. A line of the form
>.DS
>S5
>.DE
>marks the beginning of ruleset 5. Rulesets are groupings of
>rewriting rules. The S lines provide the only demarcation between
>rulesets.
>.IP R
>A rewriting rule. As with all other parsing tools, a rewriting
>rule contains a pattern on the left-hand side and a transformation
>rule for the input on the right-hand side.
>.LP
>Solaris 2.2 has two new line types:
>.IP L
>Define a variable, like a D-type line, but take the value
>from a configuration table. The location and mission of these
>tables will be discussed later.
>.IP G
>Create a class, like a C-line, using a configuration table
>instead of a hard-coded value list.
>.LP
>Variables and classes are analogous to global variables and
>initialized data in C programs. They provide state for
>the dynamic execution of the code, which contains the more
>interesting and complex components.
>In the case of sendmail, the
>code is a large and onerous looking set of rewriting rules.
>.SH
>Play by the rules
>.LP
>One of sendmail's primary functions is to digest mail addresses
>and turn them into a triple of (destination machine, destination
>user, mailer). Building a sendmail configuration is an exercise in
>interoperability, down to the level of forgiving poor electronic
>penmanship. Rewriting rules are the engine that produces
>transformations. Rules are organized into sets, with at least one
>rule in each set. Rulesets structure the address parsing in the
>same way that subroutines process data handling, setting off
>commonly used routines and subdividing complex tasks into more
>manageable elements.
>.LP
>There are three basic rulset sequences used in normal mail delivery:
>.IP *
>The delivery triple of (destination, user, machine) is determined
>by first feeding the address into ruleset 3, following by ruleset 0.
>The output of ruleset 0 must be a delivery triple.
>.IP *
>The sender's address is given some extra pampering on the way out.
>It is rewritten by ruleset 3, but it
>then goes to ruleset 1, and any ruleset for sender address
>rewriting specified in the mailer definition. You'll find
>sender address rewriting rulesets specified by clauses like
>S=25 in the mailer definition lines. Sender
>addresses end up at ruleset 4 for final mix-down.
>> HAL: why S=25? must these new rulesets be numbered above a certain
>> value?
>[DAVID: there's no base address for new rulesets, but usually the
>first 20 are "taken". maybe we should change this to xref the Muucp
>example above, which has S=13]
>.IP *
>For mail recipients,
>rulesets 3 and 1 massage the address, followed by the recipient
>address rewriting clause, such as R=24, from the mailer definition, followed by
>ruleset 4.
>.LP
>Why the extra effort given to sender and recipient addresses?
>It's in these extra rulesets that you implement tricks like
>name hiding and alias inversion. Rulesets 3 and 0 make sure
>you can turn an address into a destination, while the sender and
>recipient rules make sure the mail has a nice return
>address and neatly formatted destination.
>.SH
>Language barriers
>.LP
>Rewriting rules are horribly cryptic, but that's primarily due
>to the terse notation used for regular expression pattern matching.
>The left-hand side of a rule is a pattern, and the ride-hand side
>is a replacement string. Regular expressions provide wildcard
>matching, while specific tokens, such as strings or punctuation
>marks, are matched literally. Token boundaries are noted by dollar
>signs. The regular expression syntax is similar to, but
>not exactly like that of egrep:
>.DS
>$* Match zero or more tokens
>$+ Match one or more tokens
>$- Match exactly one token
>$=X Match a member of class X
>$~X Match if not in class X
>$X Match if equal to variable X
>.DE
>The tokens that match each subexpression are passed to the right-hand
>side as a vector of variables: $1, $2, $3 and so on. There are some
>other special-purpose tokens, like $:, which we'll talk later.
>You'll also see angle brackets, < and >, used to place a "focus" on
>the parsing. Focus is usually shifted to the
>destination system part, leaving the
>username before the focus. Many rules will use the focus markers
>to designate a substring that's being converted to a potential destination site
>name.
>.LP
>One more note before some examples of rule syntax.
>When an address is handed to a ruleset, each rule is applied to
>it serially. If an address matches the left-hand side of a rule,
>it is replaced with the right-hand side output and the rule is re-executed.
>Rules may recursively trim down or expand an address as required.
>.LP
>The rule
>.DS
>$+@<$-.east> $1@$2
>.DE
>matches one or more things followed by
>an at sign, followed by one thing suffixed with .east. The obvious
>match is
>stern@sunne.east
>but
>polyglot!tim@sunne.east
>also fits, since any number of tokens, including addressing metacharacters,
>can appear before the at sign. Both addresses are rewritten without the .east
>suffix, which is a simple way to strip off unneeded domain qualifiers.
>.LP
>Rule recursion makes adding tokens a bit more complex. If you
>add a token in the rewriting phase, make sure the rule's output
>won't match its input string, or you'll get stuck in a rewriting
>loop. For example:
>.DS
>$-@<$+.east> $1@$2.ma.east
>.DE
>It looks fairly harmless -- just adding a local name before
>anything with a trailing .east. But if you give this rule
>stern@ma.east, you get stern@ma.ma.east back, and this output
>matches the left hand side again. You can prevent an endless
>stream of tokens by keeping patterns inside the focus as simple
>as possible, rarely using patterns that match more than one token.
>In this example, changing the $+.east to $-.east breaks the infinite
>loop after just one match.
>.SH
>Ex post facto changes
>.LP
>Given the somewhat frail nature of many sendmail configurations,
>you might want to restrict your sendmail configuration hacking to
>new rulesets. Most of the work you'll want to tackle probably
>involves cleaning up sender and recipient addresses, which
>is easily done with new, independent rulesets.
>When adding your own
>own variables and classes, use upper case letters since lowercase
>values are reserved by sendmail.
>.LP
>So how do you integrate your handiwork into the mainstream
>of address processing? Let's say you create a ruleset 11,
>designed to clean up some bizarre UUCP connections that leave
>you with both bad feelings and unworkable return addresses.
>To insert it in the middle of ruleset 0, use the equivalent of
>a sendmail subroutine call:
>.DS
>R+ $:$>11 throw at ruleset 11 once
>.DE
>The left-hand side matches everything. The right-hand side starts
>with the magic $: token, which means "execute this rule only once."
>This is another mechanism to avoid infinite loops. The $>11
>construct says "feed the whole address to ruleset 11, and
>insert its output here." Voila. You've called your own rewriting rules
>with a restricted, one-line change to the main ruleset.
>.SH
>Table the motion
>[DAVID: this is completely sun-specific, and i'm getting long here,
>so cut this whole section if you need to]
>.LP
>Most variables and classes are defined within the sendmail configuration
>file, which is fine if you use the same configuration in all places.
>However, many sites require minor variations of the configuration on each
>mailhub. The domain name is the most likely candidate requiring
>customization on each machine. If you're adopting NIS+ or DNS,
>changing domain names is likely to break mail as you install
>the new naming services. Instead of taking the domain name,
>or some other variable definition, from a line within
>the configuration file, it would be nice to pull it out
>of a local naming service.
>.LP
>Enter the sendmailvars table. New in Solaris 2.2, it contains
>variable and class definitions that are managed by the name service,
>outside of individual sendmail.cf files. Entries in the map are
>in the standard key-value pairs:
>.DS
>variable value
>class value value value
>.DE
>The key is the \fIvalue\fR of a variable or class defined
>in a G- or L-type line in the
>sendmail configuration file. For example, declare variable
>X using the table-driven L-type line:
>.DS
>LXdirect-connects
>.DE
>The value of X in its definition is used as a key into the sendmailvars map.
>When X appears in a rewriting rule, its value from sendmailvars will
>be substituted.
>This adjunct table lives in /etc/mail/sendmailvars, or
>in the NIS/NIS+ map of the same name. The default nsswitch.conf
>setup is to use files first, then NIS+.
>.LP
>So let's say you're the mail hacker for a university. You
>want each department to use the right domain name, but you
>threaten anyone who touches your sacrosanct sendmail.cf
>files with a one-way trip to Jurassic Park. Decouple
>the configuration framework -- the sendmail.cf file --
>from the per-site data, which can be put into sendmailvars.
>Distribute the sendmail.cf file with the $m variable
>defined as:
>.DS
>Lmpublic-domain
>.DE
>Create an entry in sendmailvars that defines public-domain,
>for example:
>.DS
>public-domain .cs.ufred.edu
>.DE
>Since this file is different on each mail hub, you can keep
>a pristine sendmail.cf file and still allow local variations
>for domain names and parsing rules. If you use NIS+
>to disseminate sendmailvars, you can declare an organization-wide
>default table, and then let selected subdomains override its
>values with their own sendmailvars tables.
>.SH
>Stupid sendmail tricks
>.LP
>It's really only possible to gain familiarity with sendmail rulesets
>by writing or modifying some yourself. Here are some common
>problems and some minimal solutions to them.
>.LP
>\fBForwarding UUCP mail\fR. Your mail hub is a large, centrally
>managed machine, but for security reasons you've moved your UUCP connections
>to a smaller machine on the other side of a firewall. How do you
>hide this fact from your users, so they don't have to deal with
>clumsy UUCP addresses? Let's say your UUCP machine is called
>uucpgate. Add a rule to ruleset 0 that catches all traffic
>directed to hosts of the form name.uucp:
>.DS
>R$-@<$-.uucp> $#ether $@uucpgate $:$1@$2.uucp
>.DE
>The left-hand side matches anything going to a .uucp host. The right-hand
>side specifies the ether mailer, denoted by the $# prefix,
>with uucpgate as the destination host. The username to be passed
>through, following the $:, is the same pattern that matched the
>left-hand side. This rule just forwards the mail to another machine
>for UUCP activity. On the UUCP gateway, it will be handled by the UUCP
>mailer. A real sendmail die-hard would then edit the sender and
>recipient rewriting rules for the UUCP mailer on the UUCP gateway
>to remove the name of the gateway machine from outgoing mail.
>.LP
>\fBAlias inversion\fR. Internally, you call him by his login, joebob.
>But to the outside world, he prefers to be known as Joseph.Alpert.
>How can you rewrite outgoing mail so it obeys a first.last name
>convention? This requires close coordination of the sendmail
>configuration and aliases file. The first step is to define the mappings
>between first and last name monikers and usernames. Make sure
>the first.last name aliases point to the mailhost, for example:
>.DS
>Joseph.Alpert: joebob@mailhub
>Ellen.Tishman: ellen@mailhub
>.DE
>If you look at your NIS maps, you'll see one called mail.byaddr.
>This is the reverse of the normal NIS aliases map, which uses the
>left-hand side as a key. In the mail.byaddr map, each alias
>that has only one target on the right-hand side is represented
>with that target as a key, and the alias as its value. The
>problem, then, is to get sendmail to take sender names, look them
>up in mail.byaddr, and rewrite outgoing mail with the public
>names.
>.LP
>Again, define a new ruleset for this excursion. Let's define
>ruleset 25, which will be called by the ether mailer
>for sender address rewriting. The ether mailer definition
>now looks like this:
>.DS
>Mether, P=[TCP], F=msDFMuCX, S=11, R=25, A=TCP $h
>.DE
>Near the top of the sendmail configuration file, along with the
>other variable definitions, we'll add a line pointing to mail.byaddr:
>.DS
>DZmail.byaddr
>.DE
>Define ruleset 25 to cross-reference the map named by the Z variable:
>.DS
>S25
>R$-<@mailhub> $:$>3${Z$1@$2$}
>.DE
>Let's dissect this slowly. The left-hand side matches any user who
>is on the local mailhub. The right-hand side starts with the
>token that suppresses further parsing, and then it has a $>3 to
>feed the results of this rule into ruleset 3 for further cleaning up.
>The stuff in the braces is the sendmail equivalent of an NIS
>lookup, or a ypmatch. $1@$2 is the key, which is used in the map
>defined as variable Z -- mail.byaddr. So mail sent by joebob@mailhub
>matches Joseph.Alpert in the inverted alias file, and the sender's
>name is replaced with its first.last form in the outbound message.
>This feature is Sun-specific, although the IDA sendmail kit has
>a similar function that allows you to do an arbitrary lookup
>in a DBM file. Since NIS maps are stored as DBM file, it gives you
>the same flexibility.
>.LP
>\fBName hiding\fR. You have a group of five machines in a lab that
>all run their own sendmail configurations, but you'd like to
>appear as a single mailhub to the rest of the world. The
>easiest approach is to put the five machine names into a class.
>For example:
>.DS
>CVoxygen helium hydrogen neon argon
>.DE
>Then match members of the class in a rewriting rule that removes
>the host name part of the address:
>.DS
>R$-<@$=V> $1 strip off @host
>.DE
>The $=V syntax matches any host name in the list assigned to class V.
>If the class is likely to grow over time, or vary from machine to
>machine, consider putting it into a file, and define the class using
>a filename:
>.DS
>FV/usr/local/mail/hidden-hosts
>.DE
>Focus on separating configuration data from parsing rules, and you'll
>end up with the most flexible, re-usable sendmail configuration files.
>.SH
>He is Parser Brown
>.LP
>Even the most heart-felt attempts to implement address rewriting rules
>require debugging, and often serious debugging. The best place to start
>is by running sendmail's parser interactively, using the -bt flag to
>specify address test mode, and the -C\fIpathname\fR flag to use
>an alternative configuration file. If you're going to tinker with
>sendmail.cf, copy it to a safe place first, and exercise your
>changes before publishing them. If you break the mailer badly
>enough, users can't even send you mail to tell you there's a problem.
>.LP
>Fire up sendmail in debugging mode using a command line like:
>.DS
>% /usr/lib/sendmail -bt -C/home/stern/sendmail.cf.new
>.DE
>You'll be prompted to enter a ruleset and an address.
>Ruleset 3 is always run, and you dictate what to run after that.
>For the basic "ruleset 3-then rulset 0" work, use
>.DS
>0 decgate::fred@vmshost.west
>.DE
>If you want to see how a recipient
>address is parsed, when your local mailer uses rulset 22 for
>recipient rewriting, try this:
>.DS
>2,22,4 hal@east
>.DE
>If a name expands to an alias, you'll be subjected to a large
>volume of output as each recipient is parsed. To make life
>easier, get Rob Kolstad's address verifier.
>It's a perl script that takes an input address and generates
>the triple (destination, user, mailer) on output. It's
>available via anonymous ftp from
>boulder.co.edu, in pub/sendmail.test.shar
>.LP
>If the inner mechanics of token matching interest you, and
>you don't mind wading through reams of debugging output,
>turn on some of the 21 sendmail debugging flags.
>Each flag can be assigned a level of detail. To get the
>general idea, try running a test address through sendmail
>started with the -d21.99 flag,
>which is the sendmail debugging equivalent of taking a bus to your
>kitchen.
>.LP
>Sendmail really isn't that horrible. There's a price you
>pay for flexibility: complexity.
>Nearly everything you do
>adds cost or value to your organization. Correct,
>intuitive, gracious mail delivery carries significant value. The cost
>to you is in learning how to extract this grade of service from sendmail.
>Hal Stern is an area technology manager with Sun Microsystems and
>is the editor of superuser, SunWorld's newsletter for system managers.
>He can be reached at hal.stern@east.sun.com.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:28 CDT