Jerry wrote:
> Hi, Marc,
>
> Thanks for the response. Now I am REALLY confused.
>
> In trying to find this problem, I turned on -d+all and sent a test
> message. The last relevant entries in the log are (deleted some
> irrelevant lines)
>
> 08:28:29 21650 spamcheck transport yielded 0
> 08:28:29 21650 search_tidyup called
> 08:28:29 21648 journalling itnews@???
> 08:28:29 21648 spamcheck transport returned OK for itnews@???
> 08:28:29 21648 post-process itnews@??? (0)
> 08:28:29 21648 itnews@??? delivered
> 08:28:29 21648 LOG: MAIN
> 08:28:29 21648 => itnews@??? R=spamcheck_router
> T=spamcheck H=localhost
> 08:28:29 21648 >>>>>>>>>>>>>>>> deliveries are done >>>>>>>>>>>>>>>>
The initial process has done its job at this time. It's matched the
conditions for the spamcheck_router, this router specifies it should be
delivered using the spamcheck transport and that transport has run to
completion. At this point the message has been run through spamc (the
transport_filter) and the output piped into a new Exim process.
>
> This particular id is an alias, to be routed to another mailbox. Instead
> it ends up in the catchall mailbox. There aren't any other entries in
> the trace, and I can see the message in the catchall box.
>
> I can believe this is turning the message around and sending it back
> into exim, but in that case, why wouldn't I see more trace entries for
> that processing?
Because it's a different Exim process, run with different arguments - the
ones in the spamcheck transport.
>
> Another thing I just noticed which makes me think this router is doing
> the delivery - the owner of the spool file has changed. Before, the
> file owner was the box user. Now it's the exim id. My local delivery
> router/transport changes the userid to the recipient. The SpamAssassin
> doesn't - it just uses the exim id.
What you need to determine is what happens to the mail when it gets
re-injected into the queue by the secondary Exim process. It must be being
accepted by some router or it would be rejected (and it can't be the
spamcheck_router or you'd have a loop).
What's in the log files for the second delivery (with protocol
spam-scanned)? You should see an entry looking like:
<date> <time> <queue-id> <= <sender> P=spam-scanned S=9404 id=<msg-id>
<date> <time> <queue-id> => <recipient> R=<router> T=<transport>
where <router> and <transport> are the router and transport which determined
the delivery conditions.
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@???
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
