Re: [exim] Fwd: Diagnosing autoreply Driver Problem

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Philip Hazel
Date:  
À: John R. Shearer
CC: exim-users
Sujet: Re: [exim] Fwd: Diagnosing autoreply Driver Problem
On Mon, 17 Oct 2005, John R. Shearer wrote:

> 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).

> > 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.

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?


-- 
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book:    http://www.uit.co.uk/exim-book