ok. after a lot more further exploration, i can safely quote ethan hunt,
mission impossible I, when he says,
"relax, luther, it's _much_ worse than you think"
ohh _maan_ where do i begin.
what i'm seeing, and what i initially thought was the problem, is only
symptoms - and it's still entirely possible that where i have got to
is also part of that chain.
what i have observed, so far, is that when data is sent via the lmtp
transport, then even when there is a message with only one recipient,
and that one recipient is unknown, the message is still queued.
that means that exim4 is accepting mail in its queue prematurely,
ignoring the error messages like 550 immediately, and taking appropriate
action.
the upshot of this all is that graeme may _well_ be correct in
concluding that the required action (for any system that has an lmtp
server or, god forbid, for the cyrus lmtp server due to a bug in its
error responses or somewhere) for solving this problem is, as he
describes, to do a separate off-line check somehow of whether the
recipient exists.
however, it's an interim 'hack' that, apart from anything, shouldn't
be necessary because you should be using recipient/callout to do an
LMTP delivery and then interpreting the 550 responses of the RCPT TO
and using _that_ to delete and validate recipients.
the thing is: i just tried this. i set up a recipient/callout and
specified a hosts = 127.0.0.1 as a workaround for the bug outlined here:
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20030421/msg00016.html
and it still doesn't work. the transport says 'accept', despite the
mailbox not existing.
what is going on?
l.
