Is there any way to move Rewrite Roules out of sendmail.cf file? On one side sendmail documentation recommends doing changes only in sendmail.mc file, but all Rewrite Rules are in .cf file. I suppose that all changes to Rewrite Rules in .cf file will be lost during next .cf file generation from .mc.
2 Answers
Mostly sendmail.cf and rewriting rules are considered so geeky and arcane that very few people fiddle with them; the whole sendmail.mc/M4 mechanism provides a more "user-friendly" front end to sendmail configuration. Most folks should stick exclusively to the sendmail.mc/M4 mechanism and never directly modify sendmail.cf -including producing modified rewrite rules- at all.
If the sendmail.mc/M4 mechanism won't quite work for you and you want to "tweak" a few rules in sendmail.cf, you may be able to do it with the LOCAL_NET_CONFIG and LOCAL_RULESETS capabilities of the sendmail.mc/M4 mechanism. If you want to make major mods directly to sendmail.cf, maybe even dispensing with the sendmail.mc/M4 mechanism altogether, you're beyond what 99.44% of admins need to do, and may need some custom editing of Makefiles and/or shell scripts to implement your desired scheme. (Beware that on some systems service sendmail start will invoke the Makefile which executes the sendmail.mc/M4 mechanism, so overwriting of sendmail.cf will occur more often than you may expect.)
(To be brutally honest, I too sometimes find having this two-level indirect sort of front end interface a little awkward and frustrating: sometimes I know what I want, and I know how to make sendmail.cf do it ...but I can't figure out the "right" way to say it with the sendmail.mc/M4 mechanism. And advice for different versions of BIND is sometimes more misleading than helpful. What often works for me is using a few words from the desired sendmail.cf in a grep command to turn up the "right" sendmail.mc/M4 feature: grep "desired_sendmail.cf_words" /usr/share/sendmail.cf/*/*.)
Per the sendmail README (perhaps /usr/share/sendmail-cf/README) you can cause the M4 sendmail.mc->sendmail.cf mechanism to insert arbitrary additional rewrite rules literally by specifying LOCAL_NET_CONFIG and/or LOCAL_RULESET (and LOCAL_RULE_3, LOCAL_RULE_0, LOCAL_RULE_1, and LOCAL_RULE_2) in sendmail.mc. For example, to insert a delivery rewrite rule:
LOCAL_NET_CONFIG
# Add/insert my own additional rewrite-rule(s)
R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3
or to add a new rewrite-ruleset:
LOCAL_RULESETS
# Add one or more new rewrite-rulesets (subroutines) [new name]
SLocal_trust_auth
R$* $: $&{auth_authen}
Rsmmsp $# OK
or to append more rewrite-rules to the end of an existing rewrite-ruleset:
LOCAL_RULESETS
# Append to one or more existing rewrite-rulesets (subroutines) [existing name]
SParse1
R$* $: $&{auth_authen}
Rsmmsp $# OK
However, this mechanism is for "tweaking" the existing rewrite-rule framework but not for making completely arbitrary changes to rewrite-rules. Rules using LOCAL_NET_CONFIG will always be inserted at the same place: halfway through ruleset 0. And they can't be wildly different from what was there before such that delivery no longer approximately matches the assumptions made by the existing "parse" functionality. New rulesets (subroutines) from LOCAL_RULESETS will either be called only by your inserted rules, or be called directly by the sendmail program itself depending on specific (and possibly obscure) subroutine names and sendmail.mc FEATURE specifications. And extensions to existing rulesets (subroutines) from LOCAL_RULESET can add new functionality, but probably cannot change existing functionality, as a match and "return" by an existing earlier rule will terminate execution of that ruleset before your additional rules are even reached. Nevertheless, this may be adequate for what you want.
If you do this, use the sendmail -bt -Ctrial_sendmail.cf_file -d21.15 test mechanism to make sure it's behaving the way you intend. Remember, your "style" should be to compose your new rules in such a way that they fit seamlessly into the existing ruleset framework (rather than making arbitrary changes with little consideration for the existing framework); it's rather like adding a new feature to existing code that was structured by somebody else. The distributed rewrite rules are very good at handling not only mainline behavior but also edge cases (MX for individual hosts? Masquerade exceptions? UUCP connectivity? aliases? etc.?); hopefully your added rules will be similarly comprehensive.
sendmail when run reads sendmail.cf. So sendmail.cf must exist and contain the full set of rules and variables that need to be set to match your requirements for a working setup. The most common way to build sendmail.cf is by maintaining the simpler sendmail.mc file and then using m4 to "compile" sendmail.mc into sendmail.cf. So yes, it is possible to break the sendmail.mc file into parts and then by carefully executing m4 to produce the (single) sendmail.cf
I highly recommend the bat book if you want to tinker with sendmail.mc and .cf. For an approach that bypasses m4 and sendmail.mc you can look at Sendmail Theory and Practice but it may be overkill for most people.
