As I recently posted in another thread, I upgraded to exim 4.94.2 last week under duress. The upgrade was planned but I had some other pseudo-system software that had to be upgraded and that changed some libraries on the system which broke my running exim 4.89. I am having problems on one domain that has its own director that uses a dbm file based aliases file so that the owner can maintain his own local aliases.
I have a director as follows (which has its original root in exim3, but which was running ok with 4.89 without the _data changes for local_part and domain):
permaddressforwarder:
driver = redirect
allow_defer
allow_fail
data = ${lookup{$local_part_data}dbm{/var/spool/exim/${domain_data}/aliases}}
domains = YYY.TLD
file_transport = address_file
forbid_pipe
pipe_transport = address_pipe
retry_use_local_part
# >> Option added by convert4r3
This stopped working after the update to 4.94.2 If I do an "exim -bt -d” I see the following, which should have picked up the alias:
--------> permaddressforwarder router <--------
local_part=chad domain=YYY.TLD
checking domains
YYY.TLD in “YYY.TLD"? yes (matched “YYY.TLD")
calling permaddressforwarder router
rda_interpret (string): '${lookup{$local_part_data}dbm{/var/spool/exim/${domain_data}/aliases}}'
search_open: dbm "/var/spool/exim/YYY.TLD/aliases"
EXIM_DBOPEN: file </var/spool/exim/YYY.TLD/aliases> dir </var/spool/exim/YYY.TLD> flags=O_RDONLY
returned from EXIM_DBOPEN: 685010
search_find: file="/var/spool/exim/YYY.TLD/aliases"
key="" partial=-1 affix=NULL starflags=0 opts=NULL
LRU list:
0/var/spool/exim/YYY.TLD/aliases
End
internal_search_find: file="/var/spool/exim/YYY.TLD/aliases"
type=dbm key="" opts=NULL
expanded: ''
file is not a filter file
parse_forward_list:
permaddressforwarder router declined for chad@YYY.TLD
I am not sure how to interpret this. Is this successully opening the DBM db but finding something other than it was looking for? Is that the “file is not a filter file”?
It is built using “exim_dbmbuild” which was updated last week in building the new exim version.
I did not specify a specific USE* in the local Makefile. The base system is SmartOS (Solaris)
The directory with the aliases file has (iisle is the shell user that “owns” the base aliases text file and generates this — mail is the “mailgroup” exim runs under
# ls -al /var/spool/exim/YYY.TLD/
total 22
drwxrwx--x 2 iisle mail 4 Aug 30 17:54 .
drwxr-x--x 10 mail mail 11 Aug 30 17:59 ..
-rw-r--r-- 1 iisle mail 4096 Aug 30 17:54 aliases.dir
-rw-r--r-- 1 iisle mail 7168 Aug 30 17:54 aliases.pag
#
Which makes it look like Berkeley was used??
Thanks for any insight. I am not sure where to start poking.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
I have a director as follows (which has its original root in exim3, but which was running ok with 4.89 without the _data changes for local_part and domain):
permaddressforwarder:
driver = redirect
allow_defer
allow_fail
data = ${lookup{$local_part_data}dbm{/var/spool/exim/${domain_data}/aliases}}
domains = YYY.TLD
file_transport = address_file
forbid_pipe
pipe_transport = address_pipe
retry_use_local_part
# >> Option added by convert4r3
This stopped working after the update to 4.94.2 If I do an "exim -bt -d” I see the following, which should have picked up the alias:
--------> permaddressforwarder router <--------
local_part=chad domain=YYY.TLD
checking domains
YYY.TLD in “YYY.TLD"? yes (matched “YYY.TLD")
calling permaddressforwarder router
rda_interpret (string): '${lookup{$local_part_data}dbm{/var/spool/exim/${domain_data}/aliases}}'
search_open: dbm "/var/spool/exim/YYY.TLD/aliases"
EXIM_DBOPEN: file </var/spool/exim/YYY.TLD/aliases> dir </var/spool/exim/YYY.TLD> flags=O_RDONLY
returned from EXIM_DBOPEN: 685010
search_find: file="/var/spool/exim/YYY.TLD/aliases"
key="" partial=-1 affix=NULL starflags=0 opts=NULL
LRU list:
0/var/spool/exim/YYY.TLD/aliases
End
internal_search_find: file="/var/spool/exim/YYY.TLD/aliases"
type=dbm key="" opts=NULL
expanded: ''
file is not a filter file
parse_forward_list:
permaddressforwarder router declined for chad@YYY.TLD
I am not sure how to interpret this. Is this successully opening the DBM db but finding something other than it was looking for? Is that the “file is not a filter file”?
It is built using “exim_dbmbuild” which was updated last week in building the new exim version.
I did not specify a specific USE* in the local Makefile. The base system is SmartOS (Solaris)
The directory with the aliases file has (iisle is the shell user that “owns” the base aliases text file and generates this — mail is the “mailgroup” exim runs under
# ls -al /var/spool/exim/YYY.TLD/
total 22
drwxrwx--x 2 iisle mail 4 Aug 30 17:54 .
drwxr-x--x 10 mail mail 11 Aug 30 17:59 ..
-rw-r--r-- 1 iisle mail 4096 Aug 30 17:54 aliases.dir
-rw-r--r-- 1 iisle mail 7168 Aug 30 17:54 aliases.pag
#
Which makes it look like Berkeley was used??
Thanks for any insight. I am not sure where to start poking.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/