Luke Kenneth Casson Leighton wrote:
> 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.
You are 'hip shooting' on slim/no facts instead of listening, reading,
investigating.
That is what is going on.
Step back and dig into the docs. You need the become at least *familiar* with
the 'big picture' before citing (in error) some minutia-in-isolation as a 'bug'.
All it takes is ONE 'leaky' router to cause verify = recipient to accept rahter
than deny.
That router may have ZERO to do with the specific route you are concentrating on.
Exim has the best debug tools in the industry to show you that. It can be made
to log in excruciating detail. Have you used any of these instead of your keyboard?
Or is this whole excercise a troll?
Bill
JFWIW, I venture that Graeme who 'may _well_ be correct' in your view, has
forgotten more about troubleshooting Exim than you have had hot meals. And
remembered even more.
