This is a post I made to comp.mail.sendmail about an address rewriting problem.
kaushalshriyan@gmail.com wrote:
> [root@smapworld ~]# mail -v suresh@smapworld.com . . . > suresh@smapworld.com... Connecting to [127.0.0.1] via relay... . . . > >>> RCPT To:<suresh@smapworld.com> > >>> DATA > 554 5.0.0 rewrite: excessive recursion (max 50), ruleset canonify
The problem you are seeing is that there is an infinite loop with the canonify ruleset. It is probably is a problem with the canonify ruleset calling some custom ruleset over and over again. BTW, since the error occurs after the RCPT To: command, this is a problem with the sendmail daemon which uses the sendmail.cf file, not the submit.cf file. You can see this behavior with address test mode. From the SMTP output the RCPT To: command tells us that we want to test the address "suresh@smapworld.com" and the 554 error message tells us we want to test the "canonify" ruleset.
Go into address test mode:
sendmail -bt
and enter the ruleset and the address to test:
canonify suresh@smapworld.com
Be prepared for lots of output. What I expect you will see is a repetitive set of "input:" and "returns:" lines. You will see the first "canonify input:" line. The next input line should be the ruleset that is looping. If you see output of the form:
someruleset input: some < @ address . dom >
someruleset returns: some < @ address . dom >
someruleset input: some < @ address . dom >
someruleset returns: some < @ address . dom >
someruleset input: some < @ address . dom >
someruleset returns: some < @ address . dom >
The ruleset and the address will be different, the address may be the original address with focus (angle brackets "<" ">") and a trailing dot, "suresh < @ smapworld . com . >".
Then this is a looping rule in canonify calling the ruleset "someruleset" over and over again. I suspect this is a custom rule someone added and is easy to fix. First you have to find the rule with address test mode. What you are interested in is the first output, but the test will likely generate *LOTS* of output (5K - 10K lines is not inconceivable) so restart address test mode and pipe it to "tee":
sendmail -bt -d21.12 | tee /tmp/sendmail.out
Once you are in address test mode you need to crank up the address rewriting debug flag to level 12 which will show each rule being called:
-d21.12
(note: no space between the -d and the 12.12)
Now run the test again:
canonify suresh@smapworld.com
You will see *LOTS* of output, exit address test mode with a CNTL-D.
Now look at the start of the tee file, /tmp/sendmail.out. After the initial "canonify input:" line, you will see three types of lines:
-----trying rule: something
----- rule fails
-----rule matches: something
The "-----trying rule:" line shows the left hand side (LHS) pattern match of the address rewriting rule being tested. The "----- rule fails" notes that the address match failed. The "-----rule matches:" indicates that the address match was successful and what the right hand side (RHS) address rewrite pattern is. After a "-----rule matches:" line you will also see a "rewritten as:" line which shows how sendmail rewrote the address. Now ignore the actual rule syntax for now, we are just trying to find the actual rule that is causing the problem.
Now start scrolling down the output and find the first occurrence of the calling of the looping ruleset:
someruleset input: some < @ address . dom >
When you find it, note the "-----trying rule:" and "-----rule matches:" lines right before it. This is probably the rule that is causing the problem. Now look for the ruleset returning:
someruleset returns: some < @ address . dom >
What follows this? Is it the same "-----trying rule:" and "-----rule matches:" lines? If so then this is an infinitely looping rule. What you might also see is that the canonify ruleset calls a second ruleset, and then the second ruleset calls canonify again. In ether case you have probably found the problem rule. To solve this you would modify the custom rule that was added and include a "$:" at the beginning of the RHS.
From the address test mode output you will find what the rule looks like:
-----trying rule: LHS
-----rule matches: RHS
someruleset input: some < @ address . dom >
If "LHS" and "RHS" are the text that followed "-----trying rule:" and "-----rule matches:", then the rule itself will look like this:
R LHS RHS
Now on the RHS of the rule it probably starts with "$> someruleset". To fix this problem you have to "break recursion". This is the behavior that sendmail will apply a rule over and over again as long as the LHS pattern matches. While this is quite helpful in a few specific cases, it is normally a pain in the tookus. You break recursion by using "$:" at the beginning of the RHS. So you would change the rule to look like this:
R LHS $: RHS
Once you have made the change, then go back into address test mode (without -d21.12) and see if the problem is fixed.
Just another "Harker’s Helpful Hints"
RLH