Philip:
Thank you for your reply.
>> To simplify the problem I have stripped down my transport and hard-wired
>> several values. Since I can see that the router is behaving properly I'm
>> just going to include my test transport...
>>
>> puremail_autoreply_transport:
>> driver = autoreply
>> text = "This is the autoreply body"
>> to = $sender_address
>> from = noreply@???
>> subject = "Autoreply subject"
>>
>> Can anyone see anything wrong with this setup? If not, then how can I
>> troubleshoot the problem?
> Looks reasonable. I didn't note your router, but if it didn't specify a
> user, this transport will run as the exim user (in case that matters).
I'm running the transport as www-data:www-data because all "local" mailboxes
are virtual; there are no real Unix user accounts. My router looks something
like this (let me know if you want the whole thing along with macros,
etc.)...
autoreply_forward_router:
domains = +puremail_domains
require_files = HOME_DIRECTORY/autoreply.txt
condition = [a very complex condition that queries MySQL]
driver = accept
transport = puremail_autoreply_transport
user = www-data
group = www-data
unseen = yes
verify = no
As I mentioned before a "once" file was created in the mailbox's home
directory (with appropriate permissions/ownership) when I used the "once"
directive in the transport, so we know that the transport was run under the
correct UID.
>>> My router works as expected. In debug mode I can see that the router
>>> correctly determines whether or not the recipient should get autoreply
>>> processing. The "once" DBM file is successfully created in the
recipient's
>>> home directory whenever I send an Email to the test recipient.
>>>
>>> When I send Email from a given sender the first time I get the following
>>> error in the Exim logs (because of the "once" file subsequent messages
from
>>> the same sender do not receive an error as no autoreply is generated)...
>>>
>>> 2005-10-10 18:26:04 1EP8tt-0006XP-D8 <= nosuchuser@???
>>> H=tuna.puremail.com (test) [10.3.11.33] P=smtp S=188
>>> 2005-10-10 18:26:04 1EP8tt-0006XP-D8 == john@???
>>> R=puremail_autoreply_router T=puremail_autoreply_transport defer (0):
Failed
>>> to send message from puremail_autoreply_transport transport (1)
>>>
>>> I can't effectively debug this because the generation of autoreply message
>>> itself is handled under a different process than the initial incoming
>>> message, so no debug output is available.
> Hmm. That sounds odd. Usually if you run Exim in debug mode it will show
> debugging output for the transports as well. Ah, but of course it won't
> show you anything from the new Exim process that is *receiving* the
> autoreply. I don't suppose there's anything in the log that helps there.
The only log data available is what I've included above; not much detail
there. I'm not familiar with the mechanism that generates the reply message.
Could this error be getting returned from the Exim instance that transmits
the reply because it is being run as www-data instead of root?
> However, there's a clue in the "(1)", which is an errno value. 1 is
> usually EPERM, a permission error. But the only file it will be trying
> to access is the exim binary - in order to submit the new message. You
> haven't made that inaccessible, have you?
This being a Debian box the binary is called "exim4"; I soft-linked "exim" to
it for compatibility reasons...
lrwxrwxrwx 1 root root 5 Apr 15 2005 /usr/sbin/exim -> exim4
-rwsr-xr-x 1 root root 784152 May 27 01:10 /usr/sbin/exim4
This shouldn't cause any problems that I can see. I tested sending a message
with "exim -f noreply@??? nosuchuser@???" and it transmitted
just fine, so there aren't any bugs in my config that prohibit delivering
mail to external address as www-data.
I know that the autoreply transport works for plenty of other folks. How can
I troubleshoot this to find out what's killing it in my environment?
I'm at my wits end. - John R. S.
