I'm fairly confident that I've discovered a bug in the rewriting rules of
exim 1.62. Because our rewriting rules are rather complicated, the will
take a bit of explaining. But please bare with me.
In my exim config file right now, I have three rewriting rules. I've
attatched the appropriate part of the config file, but because the rules
are so complex (and involve sql calls), I'll describe what they do in
english. (Note that although, in this excerpt, the third rule is
commented out, I have tried it with none of the rules commented out, and
this nothing-commented-out is what gives rise to my problem.)
rule 1 (applied to any From field that matches *@justin.lakeside.sea.wa.us)
Replaces From field with
<full name> + "<" + <original bla@???> + ">"
ie: "chrish@???" becomes
"Chris Harris <chrish@???>"
ie: "colinc@???" becomes
"Colin Campbell <colinc@???>"
ie: "Stupid Fool <colinc@???>" becomes
"Colin Campbell <colinc@???>"
(This rule is necesary to add the correct full name to addresses
generated by an IMAP client in a lab situation.)
rule 2 (applied to all From and envelope sender fields)
If the address in the From field corresponds to the address in
a certain table of our mail database that has an attatched
"nickname", then replace the From address with
<nickname> + "@lakeside.sea.wa.us"
ie: "chrish@???" becomes
"chrish@???"
(The chrish@justin... account here "points", in a sense, to
the chrish "nickname".)
ie: "colinc@???" remains the same.
(The colinc@justin address has no corresponding entry in
the database table, so the "fail" clause of the rule takes
control...and nothing happens as a result.)
rule 3 (applied to all From and envelope sender fields)
If the address in the From field corresponds to an address in
a different table in our mail database, then replace the From address
with <firstname_lastname> + "@lakeside.sea.wa.us"
ie: "chrish@???" becomes
"chris_harris@???"
(Because the chrish@justin address again "points", in a sense, to
a valid table entry.)
ie: "colinc@???" becomes
"colin_campbell@???"
(Because, in the second table, the colinc@justin address DOES
point to a valid table entry.)
Rule 1 has the "w" flag set; the others do not.
Note that all of the rules work correctly on their own; that is, the third
works correctly if I comment out the first two; the first correctly if I
comment out the second two; the second correctly if I comment out the
first and last. (This has been verified quite thoroughly.) However, when
working together, they do NOT work as I would expect. Here are two
examples of this:
1. When I submit the address "chrish@???" for
From-field rewriting, I expect to get back the address
"Chris Harris <chrish@???>"
The thinking here is that rule #1 would replace the initial address with
"Chris Harris <chrish@???>"
that rule #2 would strip of the "justin." immediately following the @ and
that rule #3 would be ignored. However, when I do a test with "exim -brw
chrish@???", the computer gives me
"<chrish@???>",
the same result that I would have if rule #1 were commented out.
2. When I submit the address "colinc@???" for
From-field rewriting, I expect to get back the address
"Colin Campbell <colin_campbell@???>"
The thinking here is that rule #1 would replace the initial address with
"Colin Campbell <colinc@???>"
that rule #2 would have no effect and that rule #3 would change "colinc"
to "colin_campbell" and strip off the "justin." following the @. However,
"exim -brw colinc@???" yields the address
"<colin_campbell@???>",
the same result that I would have if rule #1 were commented out.
Rule #1 is, in effect, being ignored. I haven't yet examined the source
code, but I have a vague theory for what is wrong. Before I describe it,
I will make a definition: in the address
"Chris Harris <chrish@???>",
"Chris Harris" is called the "cheese", and
"<chrish@???>" is called the "beer". (There are
probably better terms for these, but I don't know them.)
* rule #1 is being applied correctly, so the "cheese" is being added
correctly.
* rule #2 or #3 is being applied (by exim) only half-correctly. The
"beer" is rewritten correctly. However, instead of adding the
"cheese" produced by rule #1 to the "beer" produced by rule #2/#3,
exim s adding the original, pre-rewriting "cheese" to the
"beer" produced by rule #2/#3.
According to this theory, whenver a rewriting rule without the "w" flag
comes after a rewriting rule with the "w" flag, the "w" flag of the first
rewriting rule will be ignored. This is the essence of the bug.
The is verified by yet another example:
I would expect the address
"Fooman <chrish@???>"
to be rewritten by my rules to come out as
"Chris Harris <chrish@???>"
However, "exim -brw 'Fooman <chrish@???>'"
yeilds the address
"Fooman <chrish@???>"
The above process would explain why.
You may be able to spot a stupid error of sorts in my config file.
However, after several hours of futzing, I'm ready to pass the blame for
my problem here on to exim. Ideas, Philip? Others? I need this to work
before we can get most people moving on our new IMAP-based email system.
-Chris
######################################################################
# REWRITE CONFIGURATION #
######################################################################
# put in the "correct" human-readable name for justin addresses
# ie: "chrish@???" becomes
# "Chris Harris <chrish@???>
# note: this is broken -- later rewriting lines are overriding this somehow
*@justin.lakeside.sea.wa.us \
"${lookup pgsql {select eusers.capfullname from eusers, accounts where eusers.user_id = accounts.user_id and accounts.address = '$1@???'} \
{$value} fail} <$1@???>" fFw
# try nickname rewriting
# ie: "chrish@???" becomes
# "chrish@???"
*@* \
"${lookup pgsql {select eusers.nickname from eusers, accounts where eusers.user_id = accounts.user_id and accounts.address = '$1@$2' and eusers.nickname is not null} \
{$value@???} fail}" fF
# try first_last rewriting
# ie: "chrish@???" becomes
# "chris_harris@???"
#*@* \
# "${lookup pgsql {select eusers.usfullname from eusers, accounts where eusers.user_id = accounts.user_id and accounts.address = '$1@$2'} \
# {$value@???} fail}" fF
# End of Exim configuration file
