Re: [exim] Sender verification failing sometimes

W B Hacker wrote:
> Ian Eiloart wrote:
>>
>> On 14 Jun 2011, at 12:50, W B Hacker wrote:
>>
>>>>
>>>>
>>>> Is that true? I've not experienced it, in several years.
>>>
>>> It might not be obvious *why* one's server was rejected - and need
>>> not be an LBL.
>>
>> Right, but it might be obvious *whether* my mail has been rejected.
>>
>
> ..there is that, of course ...
>
> ;-)
>
> But blaming .. or excusing .. a specific trigger FOR such rejection,
> relies all too much on the 'rejector' providing specific and accurate
> rejection message detail.
>
> Hardly assured, that. Even if you are looking.
>
> I am 'cc:' ing you primarily so that I can check my own logs...
>
> Bill

.. having done so, confirmed that a unique-ID-specific
(wbh@???) sender verification callout back to my server is
honoured at once.

Aside from needlessly spawning an extra child process at each end to
handle an extra smtp (partial) session, not a problem for your server OR
tahini (or for me either, of course).

No 'delay =' is imposed so long as the creds of the server making the
callout are clean and the recipient is valid .. and the caller's HELO
verifies ...

While a HELO mismatch is a non-fatal error here, the delay imposed can
send-off those both impatient and careless.

QED.

Or time-out a sender_verify callout..

..which was not its objective.

'..Law of unintended consequences' at work, masking the issue under
discussion.

One does wonder, however, if a similar side-effect could be a
contributing factor to the OP's '...failing sometimes'.

All it would take is a delay closer to his own wait time for a response,
plus the odd link/resource delay. Or NOT.

Policy otherwise not a factor.

Bill

--
韓家標