Principalmente o sendmail.cf e as regras de reescrita são consideradas tão nerds e arcanas que pouquíssimas pessoas mexem com elas; todo o mecanismo sendmail.mc/M4 fornece um front-end mais "amigável" para a configuração do sendmail. A maioria das pessoas deve se ater exclusivamente ao mecanismo sendmail.mc/M4 e nunca modificar diretamente o sendmail.cf - incluindo a produção de regras de reescrita modificadas - de forma alguma.
Se o mecanismo sendmail.mc/M4 não funcionar bem para você e você quiser "ajustar" algumas regras no sendmail.cf, você poderá fazer isso com os recursos LOCAL_NET_CONFIG e LOCAL_RULESETS do sendmail. mecanismo mc / M4. Se você quiser fazer grandes modificações diretamente no sendmail.cf, talvez até dispensando o mecanismo sendmail.mc/M4, você está além do que 99,44% dos administradores precisam fazer, e pode precisar de alguma edição personalizada de Makefiles e / ou scripts de shell para implementar o esquema desejado. (Cuidado que em alguns sistemas service sendmail start invocará o Makefile que executa o mecanismo sendmail.mc/M4, então a sobrescrita do sendmail.cf ocorrerá com mais freqüência do que você pode esperar.)
(Para ser brutalmente honesto, eu também algumas vezes acho que ter esse tipo de interface indireta de dois níveis é um pouco estranho e frustrante: às vezes eu sei o que eu quero, e eu sei como fazer o sendmail.cf fazer isso .. .mas não consigo descobrir a maneira "certa" de dizê-lo com o mecanismo sendmail.mc/M4. E conselhos para diferentes versões do BIND às vezes são mais enganosos do que úteis. O que muitas vezes funciona para mim é usar algumas palavras de o sendmail.cf desejado em um comando grep para ativar o recurso "right" sendmail.mc/M4: grep "desired_sendmail.cf_words" /usr/share/sendmail.cf/*/* .)
De acordo com o README do sendmail (talvez / usr / share / sendmail-cf / README), o mecanismo sendmail.mc- > sendmail.cf da M4 pode inserir regras arbitrárias de reescrita adicionais literalmente especificando LOCAL_NET_CONFIG e / ou LOCAL_RULESET ( e LOCAL_RULE_3, LOCAL_RULE_0, LOCAL_RULE_1 e LOCAL_RULE_2) em sendmail.mc. Por exemplo, para inserir uma regra de reescrita de entrega:
LOCAL_NET_CONFIG
# Add/insert my own additional rewrite-rule(s)
R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3
ou para adicionar um novo conjunto de regras de reescrita:
LOCAL_RULESETS
# Add one or more new rewrite-rulesets (subroutines) [new name]
SLocal_trust_auth
R$* $: $&{auth_authen}
Rsmmsp $# OK
ou para adicionar mais regras de reescrita ao final de um conjunto de regras de reescrita existente:
LOCAL_RULESETS
# Append to one or more existing rewrite-rulesets (subroutines) [existing name]
SParse1
R$* $: $&{auth_authen}
Rsmmsp $# OK
No entanto, , esse mecanismo é para "ajustar" a estrutura de regra de reescrita existente, mas não para fazer mudanças completamente arbitrárias nas regras de reescrita. As regras que usam LOCAL_NET_CONFIG sempre serão inseridas no mesmo local: na metade do conjunto de regras 0. E elas não podem ser muito diferentes daquelas que existiam antes de que a entrega não corresponda mais às suposições feitas pela funcionalidade de "análise" existente. Novos conjuntos de regras (sub-rotinas) de LOCAL_RULESETS serão chamados apenas por suas regras inseridas, ou serão chamados diretamente pelo próprio programa sendmail dependendo de nomes de sub-rotina específicos (e possivelmente obscuros) e especificações de FEATURE do sendmail.mc. E extensões para conjuntos de regras existentes (sub-rotinas) de LOCAL_RULESET podem adicionar novas funcionalidades, mas provavelmente não podem alterar a funcionalidade existente, pois uma correspondência e "retorno" por uma regra anterior existente terminará a execução desse conjunto de regras antes que suas regras adicionais sejam alcançadas. No entanto, isso pode ser adequado para o que você deseja.
Se você fizer isso, use o mecanismo de teste sendmail -bt -Ctrial_sendmail.cf_file -d21.15 para se certificar de que está se comportando da maneira que pretende. Lembre-se de que seu "estilo" deve ser compor suas novas regras de forma que elas se encaixem perfeitamente na estrutura de conjuntos de regras existentes (em vez de fazer alterações arbitrárias com pouca consideração pela estrutura existente); é como adicionar um novo recurso ao código existente que foi estruturado por outra pessoa. As regras de reescrita distribuídas são muito boas para lidar não apenas com o comportamento da linha principal, mas também com os casos de borda (MX para hosts individuais? Exceções de mascaramento? Conectividade UUCP? Aliases? Etc.?); Espero que suas regras adicionadas sejam igualmente abrangentes.