Author: W B Hacker Date: To: exim users Subject: 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.
