Peter Whysall wrote:
> Peter Bowyer wrote:
>
>> Are the user(s) in question being caught by your procmail or maildrop
>> routers?
>>
>> Please post the output of a debug delivery.
>
>
> I hope this is what you want; it's rather long.
>
Butting in... maybe a dumb observation, (and accidentally sent to the
wrong place - sorry Peter W.)
but:
- below (rest snipped)
The last time Exim had it hands on the message it reports
itself done with work on this message after delivering to the 'spamcheck'
Router & Transport (line asterisked below).
If there is a sign of re-injection and some other delivery - I have
missed it.
So - unless a non-Exim process (procmail?) is handed the output of whatever
and where-ever the 'spamcheck' transport delivers......
- from your earlier post, that transport is a 'pipe' transport, not an
'appendfile'
So ... what next?
Is it *supposed* to be returned by SA and hit the procmail transport for
final delivery?
Or maildrop?
- or did I miss it being re-injected to Exim with modified headers?
Or ???
Bill Hacker
> 16993 post-process peter@??? (0)
> 16993 peter@??? delivered
> 16993 LOG: MAIN
**> 16993 => peter <peter@???> R=spamcheck_router
T=spamcheck
> 16993 >>>>>>>>>>>>>>>> deliveries are done >>>>>>>>>>>>>>>>
> 16993 changed uid/gid: post-delivery tidying
> 16993 uid=112 gid=112 pid=16993
> 16993 auxiliary group list: <none>
> 16993 set_process_info: 16993 tidying up after delivering 1CjmR1-0004Q3-JV
> 16993 Processing retry items
> 16993 Succeeded addresses:
> 16993 peter@???: no retry items
> 16993 Failed addresses:
> 16993 Deferred addresses:
> 16993 end of retry processing
> 16993 LOG: MAIN
> 16993 Completed
> 16993 end delivery of 1CjmR1-0004Q3-JV
> 16993 search_tidyup called
> 16993 search_tidyup called
> 16993 >>>>>>>>>>>>>>>> Exim pid=16993 terminating with rc=0
> >>>>>>>>>>>>>>>>
>
>
>
