[please cc me -- I'm not currently on exim-users]
Hi all --
I'm having problems creating a slightly souped-up userforward router
that recognizes ".forward-foo" files, inspired by qmail's ".qmail-foo"
files. (qmail handles mail for user-foo with .qmail-foo, and I want
Exim to do similarly.) Unfortunately, the router I have created doesn't
work well with SMTP. Here's what I've got:
userforward:
driver = redirect
check_local_user
check_ancestor
allow_filter
allow_freeze
local_part_suffix = -*
local_part_suffix_optional
#file = $home/.forward$local_part_suffix
file = $home/.forward
modemask = 002
no_expn
file_transport = local_mbox
directory_transport = local_maildir
pipe_transport = address_pipe
reply_transport = address_reply
Note that currently I only handle .forward -- I've commented out the
.forward-foo stuff for now. So right now, user and user-foo will both
be handled by ~user/.forward. This works fine if I test the addresses
with "exim -bt":
$ cat .forward
/home/crew/gward/Maildir/
$ exim -bt gward
gward@??? -> /home/crew/gward/Maildir/
transport = local_maildir
$ exim -bt gward-adsfsa
gward-adsfsa@??? -> /home/crew/gward/Maildir/
transport = local_maildir
Also note that no_verify is *not* there, ie. this router participtates
in address verification as well as routing/delivery. This matters --
keep reading.
Anyways, here's what I get with a fake SMTP session (the IP used is the
one my ISP handed me this morning; it has no connection whatsoever to
the server being tested):
$ exim -bh 24.202.9.164
[...skip host-checking stuff...]
220 starship.python.net ESMTP Exim 4.05 Mon, 05 Aug 2002 10:19:15 -0400
mail from:<greg@???>
250 OK
rcpt to:<gward@???>
>>> using ACL "acl_check_rcpt"
>>> processing "accept"
>>> check hosts = :
>>> host in ":"? no (end of list)
>>> accept: condition test failed
>>> processing "deny"
>>> check local_parts = ^.*[@%!/|] : ^\\.
>>> gward in "^.*[@%!/|] : ^\."? no (end of list)
>>> deny: condition test failed
>>> processing "accept"
>>> check local_parts = postmaster
>>> gward in "postmaster"? no (end of list)
>>> accept: condition test failed
>>> processing "require"
>>> check verify = sender
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> routing greg@???
>>> gerg.ca in "@ : python.net : www.python.net : mail.python.net : hostlist relay_from_hosts = 127.0.0.1"? no (end of list)
>>> gerg.ca in "! +local_domains"? yes (end of list)
>>> calling dnslookup router
>>> 24.202.9.164 in "0.0.0.0 : 127.0.0.0/8"? no (end of list)
>>> routed by dnslookup router
>>> ----------- end verify ------------
>>> require: condition test succeeded
>>> processing "accept"
>>> check domains = +local_domains
>>> python.net in "@ : python.net : www.python.net : mail.python.net : hostlist relay_from_hosts = 127.0.0.1"? yes (matched "python.net")
>>> python.net in "+local_domains"? yes (matched "+local_domains")
>>> check verify = recipient
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> routing gward@???
>>> python.net in "! +local_domains"? no (matched "! +local_domains" - cached)
>>> calling system_aliases router
>>> system_aliases router declined for gward@???
>>> calling userforward router
LOG: unable to set gid=1185 or uid=1185 (euid=8): userforward router
LOG: internal problem in userforward router: failure to transfer data from subprocess
>>> userforward router: defer for gward@???
>>> message: internal problem in userforward router: failure to transfer data from subprocess
>>> ----------- end verify ------------
>>> accept: condition test deferred
451 Temporary local problem - please try later
LOG: H=modemcable164.9-202-24.mtl.mc.videotron.ca [24.202.9.164] F=<greg@???> temporarily rejected RCPT <gward@???>: internal problem in userforward router: failure to transfer data from subprocess
I'm pretty sure that it's the last verify chunk that's relevant, where
userforward tries to verify the address but fails with "internal problem
in userforward router: failure to transfer data from subprocess". The
bit about "unable to set gid" is an obvious red flag, but 1) my Exim is
setuid root, 2) this happens whether I run a real SMTP daemon or an
"exim -bh" session, and 3) it happens whether I run Exim as root or as a
regular user.
The same thing happens with either Exim 4.05 or 4.10.
However, if I add no_verify to the userforward router, it works -- the
"rcpt:<gward@???>" command is accepted. But then, of course,
gward-foo does not work, since Exim falls through to the next router
(localuser, which doesn't accept suffixes) and the verify fails.
I can think of a couple of workarounds; in fact, adding an optional
local_part_suffix to the localuser router seems to help. But the fact
that Exim is barfing with a mysterious "internal problem" error message
makes me wonder. Anyone see this before? Is it perchance a bug?
Greg
--
Greg Ward - Unix nerd gward@???
http://starship.python.net/~gward/
Never put off till tomorrow what you can avoid all together.
