Testing sendmail.cf files

If you don't have a machine to play around with, it is well worth doing some
testing before installing your new sendmail and the associated config file.
You can invoke sendmail in a `test mode'. The idea is to let you see how
it sees addresses, how it transforms them, and to see each step along the
way. That is very useful if you're trying to debug a hand built config file.
But if you ignore the details it gives you, it can also be a very convenient
way to see if it does roughly the right thing. If you want to understand all
of the details it gives, you need to read the sendmail.cf file,
and the Sendmail Operations Guide; reading the Bat book is also very useful.
But for most purposes, you can ignore that stuff, and just see whether the
final result is reasonable. To enter test mode, use a command like:

    .../sendmail -bt -C.../sendmail.cf

(replacing the `...' with whatever it takes to specify the correct versions
of sendmail and the test sendmail.cf file. For example, I might
cd to the file with all of the sendmail source, and run:

    src/sendmail -bt -Ccf/cf/obj/nmr.mgh.harvard.edu_solaris2.cf

I generally use three test addresses to see if I have things right; they will
NOT work right in your environment, but will serve as guides:

    3,0 mike
    3,0 mike@mike
    3,0 mike@nmr

If you don't want to get into the gory internals, just ignore the meaning of
the `3,0 part...but do enter it! The first `mike'
on each line is the user name part; anything should work, because sendmail
itself doesn't care about the user name, that is handled by the local mailer.
The second `mike'
on the second line is the name of my machine; you'd need to use the name of
the machine that you're running on.
The `nmr' is the short form
of an MX address (nmr.mgh.harvard.edu); if you don't have an MX
record locally, pice one somewhere, and make sure that it resolves right.

When you run the first, you should see something like this:

    ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
    Enter  


    > 3,0 mike
    rewrite: ruleset   3   input: mike
    rewrite: ruleset  96   input: mike
    rewrite: ruleset  96 returns: mike
    rewrite: ruleset   3 returns: mike
    rewrite: ruleset   0   input: mike
    rewrite: ruleset 199   input: mike
    rewrite: ruleset 199 returns: mike
    rewrite: ruleset  98   input: mike
    rewrite: ruleset  98 returns: mike
    rewrite: ruleset 198   input: mike
    rewrite: ruleset 198 returns: $# local $: mike
    rewrite: ruleset   0 returns: $# local $: mike
    > 

(I typed the `3,0 mike' part. The key thing is to check to be
sure that it resolves to the local mailer ( the `$# local' on
the last line) and to the right user name (the `$: mike') on the
last line.

When you run the second, you should see something like this:

    ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
    Enter  


    > 3,0 mike@mike
    rewrite: ruleset   3   input: mike @ mike
    rewrite: ruleset  96   input: mike < @ mike >
    rewrite: ruleset  96 returns: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset   3 returns: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset   0   input: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset 199   input: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset 199 returns: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset  98   input: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset  98 returns: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset 198   input: mike < @ mike . nmr . mgh . harvard . edu . >
    rewrite: ruleset 198 returns: $# local $: mike
    rewrite: ruleset   0 returns: $# local $: mike
    > 

Again, I typed the `3,0 mike@mike'. And again, this should end
up figuring out that you're trying to deliver to `mike' with the local mailer.

It may be worth testing other patterns (e.g. `3,0 user@host.bitnet'
would verify that you had properly configured your bitnet relay:

    ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
    Enter  

    > 
    rewrite: ruleset  96   input: user < @ host . bitnet >
    rewrite: ruleset  96 returns: user < @ host . bitnet . >
    rewrite: ruleset   3 returns: user < @ host . bitnet . >
    rewrite: ruleset   0   input: user < @ host . bitnet . >
    rewrite: ruleset 199   input: user < @ host . bitnet . >
    rewrite: ruleset 199 returns: user < @ host . bitnet . >
    rewrite: ruleset  98   input: user < @ host . bitnet . >
    rewrite: ruleset  98 returns: user < @ host . bitnet . >
    rewrite: ruleset 198   input: user < @ host . bitnet . >
    rewrite: ruleset  95   input: < cunyvm . cuny . EDU > user < @ host . BITNET . >
    rewrite: ruleset  95 returns: $# relay $@ cunyvm . cuny . EDU $: user < @ host . BITNET . >
    rewrite: ruleset 198 returns: $# relay $@ cunyvm . cuny . EDU $: user < @ host . BITNET . >
    rewrite: ruleset   0 returns: $# relay $@ cunyvm . cuny . EDU $: user < @ host . BITNET . >

Note that it realizes that it should use the `relay' mailer
to forward the data to the machine configured as the proper bitnet relay.