Although I have solved this problem, I still have no understanding of
why the problem occurred.
As a quick summary, while testing candidate configuration files with -d
-v -C -bv, I noticed that expansion of a string used in the routers
(that tests for the existence of aliases files) was returning false,
when in point of fact the indicated file did exist. (Which was noted in
messages in the thread for this topic) However, this existence failure
only occurred when verifying, not when routing.
I decided, instead of using "exists" in a string expansion, to change
the router to use:
require_files = VIRTUALS
...where in the main configuration, the macro was defined as
VIRTUALS = /etc/virtuals/$domain/aliases
When this change was tested, the require_files statement produced a
permissions failure when the router was run in verify mode! (I presume
this permissions failure is also what caused exists{file} to return
false, although the debug output does not reveal this.)
I don't understand the reason for the permissions failure.
/etc/virtuals, and all descendants, are owned by user "mail". User exim
is a member of the "mail" group. All of the folders, and all of the
aliases files have 644 permissions, which means they are both group
readable and world readable by user exim. If not, then I know even less
about *nix than I ever thought I did.
Next, I copied the entire virtuals folder with all of its contents to
etc/exiim. I then changed the macro to:
VIRTUALS = /etc/exim/virtuals/$domain/aliases
The copy was done with Filezilla, logged in as root, so
/etc/exim/virtuals and all of its contents were assigned root ownership,
as well as 644 permissions.
Just for kicks, I tried the -d -v -C -bv execution again, with root
owning the files as copied. To my astonishment, the routers did not fail!
Just to summarize:
exim (the mailer), while running as user exim, is quite happy to use
read-only root-owned files, but raises a permissions error if the files
are instead owned by user mail, despite user exim being a member of the
mail group!
Of course, this was all tested under root using BASH. I decided not to
push my luck, and used chown to change the ownership to exim:exim before
going live.
Now running live with this, and everything works as desired now, but I
am not sure what I have learned, other than exim is certainly an even
weirder animal that I ever dreamed.
On 10/27/2014 12:41 PM, Phillip Carroll wrote:
> Using exim 4.80 on Centos 5.5.
>
> My exim configuration uses virtual domain routers similar to shown in
> chapter 49.7 of the current doc. This has been working perfectly for
> about 10 years on several different servers I have migrated to over
> the years. I have never used recipient verification, but instead have
> simply bounced the email back to sender in the delivery phase.
>
> Because of a recent spate of spam emails with forged senders, most of
> which are also addressed to nonexistent local_parts, I would now
> prefer to reject the emails at RCPT time. However, try as I may, I
> cannot get "verify = recipient" to work. If I put this into the
> acl_check_rcpt ACL, all email is rejected with "550 Unknown user xxx".
>
> Somewhere in the manual I read that verify in an ACL uses the same
> router sequence as used in delivery. Clearly it does not! Tearing my
> hair out with this. Basically everything I thought I understood about
> exim seems to be under suspicion. As usual, it seems there is what the
> manual says...and then there is what the code actually does. I am
> hoping that someone with deeper understanding of the inner mysteries
> of exim can explain why unverified recipients are routed perfectly,
> but any attempt to verify them rejects every recipient. And, can tell
> me a workaround.
>
> None of the redirect routers have "no_more", because all emails are
> ultimately routed by the local_user router, using the final data from
> the redirect routers.
>
> Running exim from command line with -bh gives me no clues, as it
> routes to all addresses perfectly, cascading down through all routers
> as expected, finally routing to the actual local user. (By the way, no
> local user id is ever used as an actual external email address,
> although is used internally) I presume this -bh doesn't pay any
> attention to ACLs.
>
> It would also be nice if someone can tell me how to test this kind of
> issue without using the live system. Users tend to get cranky if
> their mail is returned to sender.
>
>
>
