Re: [exim] Problem with Maildir delivery

Stephen Gran wrote:
> On Wed, Dec 29, 2004 at 10:39:17PM +0000, Peter Whysall said:
>
>>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.
>>16991 check verify = recipient
>
>
> It's enough - look at the routing below:
>
>
>>16991 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>16991 Verifying peter@???
>>16991 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>16991 Considering peter@???
>>16991 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>16991 routing peter@???
>>16991 --------> hubbed_hosts router <--------
>>16991 hubbed_hosts router skipped: domains mismatch
>>16991 --------> dnslookup_relay_to_domains router <--------
>>16991 dnslookup_relay_to_domains router skipped: domains mismatch
>>16991 --------> send_to_gateway router <--------
>>16991 send_to_gateway router skipped: domains mismatch
>>16991 --------> real_local router <--------
>>16991 real_local router skipped: prefix mismatch
>>16991 --------> spamcheck_router router <--------
>>16991 spamcheck_router router skipped: verify 2 0 0
>>16991 --------> system_aliases router <--------
>>16991 system_aliases router declined for peter@???
>>16991 --------> mailman_router router <--------
>>16991 local_part=peter domain=guildenstern.dyndns.org
>>16991 mailman_router router skipped: file check
>>16991 --------> userforward router <--------
>>16991 local_part=peter domain=guildenstern.dyndns.org
>>16991 userforward router skipped: verify 2 0 0
>>16991 --------> procmail router <--------
>>16991 local_part=peter domain=guildenstern.dyndns.org
>>16991 procmail router skipped: verify 2 0 0
>>16991 --------> maildrop router <--------
>>16991 local_part=peter domain=guildenstern.dyndns.org
>>16991 maildrop router skipped: verify 2 0 0
>>16991 --------> local_user router <--------
>>16991 local_part=peter domain=guildenstern.dyndns.org
>>16991 domain_data=NULL localpart_data=NULL
>>16991 routed by local_user router
>>16991 envelope to: peter@???
>>16991 transport: maildir_home
>>16991 ----------- end verify ------------
>
>
> As others have pointed out, it's unclear what happens on the other end
> of the spamassassin pipe, but I can guess based on having seen this kind
> of thing around - the message will be reinjected into the exim queue,
> and will pass on to other routers after the spamassassin router.
>
> So, the important information we have from above is that:
> userforward, procmail, and maildrop routers all happen before local_user
> router. Since they have no_verify set, I have no idea whether any of
> them handle the message in it's final routing, but that is where I would
> concentrate your efforts.

Given that procmail is not present on the system, and maildrop is
executed from .forward, is it reasonable, in the interests of removing
unnecessary complexity, to remove the procmail and maildrop routers? Is
this likely to break anything as a side-effect?

Additionally, my (admittedly somewhat uninformed) reading of the above
is that in the final stage, the local_user router does indeed pass the
message to the maildir_home transport. This raises a couple of questions:

* How can I produce diagnostics of what happens in this final phase of
delivery?
* Have I already done so, and am simply too dense to see it in the debug
output?

At this point it behooves me to give thanks to all who have spent time
reading my voluminous postings on this subject.

Viva la resolution!

Regards,

Peter.