On Sun, 7 Jan 2018, admin@??? wrote:
> https://bugs.exim.org/show_bug.cgi?id=2137
>
> David Woodhouse <dwmw2@???> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |dwmw2@???
>
> --- Comment #9 from David Woodhouse <dwmw2@???> ---
> I upgraded Exim, for security reasons, and incoming mail from certain parties
> stopped working. I consider this a fairly serious regression and I've had to
> turn off random callouts for now to work around it.
Random callouts were an optional extension to solve a different problem;
turning them off, at least for these hosts, is a reasonable solution,
as is adding defer_ok.
> The random callouts have a timestamp on them ??? they are different every time.
> They are *never* going to pass the common greylisting implementations because
> they are precisely what greylisting exists to deny: a one-time submission
> that's never going to be retried.
>
> Previously, this was fine. The 'random' check got a tempfail but the actual
> address being tested was fine, so the message was delivered anyway.
>
> Now, though, we seem to defer the message we *know* we can deliver, just
> because we don't have the additional information about random deliverability.
You know that but exim doesn't.
In particular you know that this server accepts valid addresses but
defers random addresses. Exim only knows that the server defers random
addresses; you have asked for random callouts without special handling for
defers, so it seems reasonable that it takes the defer at face value.
I understand that there was a significant undocumented change in 4.89
but it is a change an edge case (defer) in an optional extension (random)
to a feature (sender verify callback) that people have been saying is a bad idea for a decade (eg
http://www.circleid.com/posts/sender_address_verification/
). If random doesn't work for you, you don't have to turn it on,
or you can use defer_ok.
> This is broken. We *might* be able to work around it for the common case by
> omitting the timestamp in the random callout, or making it be based
> deterministically on the message we're trying to deliver (or something else
> that's stable for a decent period of time). But it's still fundamentally wrong
> to delay/abort delivery of a known good message, just for the sake of some
> future optimisation.
>
> Since I've just repeated that 'just an optimisation' claim, I shouldn't ignore
> Jeremy's response to it, in bug #2147:
>
>> Not quite. It's to find out whether the target gives reliable information
>> at RCPT time, or just accepts everything blindly. Certainly it'll have the
>> effect you describe, should blind-acceptance be discovered - but that only
>> tells
>> us that attempting to do callout verification is pointless. It'll result in
>> us
>> later spending resources on an actual message transmission, which is hardly
>> an
>> optimisation.
>
> However, I don't understand it. In the absence of information that a given
> "actual message transmission" would fail, we *should* attempt it. If the random
> callout has been inconclusive, then we know nothing about future addresses at
> the same domain. How does that affect "actual message transmission"?
The idea of random is that if it *succeeds*, then we know that callback
is pointless.
If it defers, you are asking us to default to assuming that changing the
local part may not defer ...
I think you want defer_ok on the callback, either on the true callout
which is possible now, or on the random one, which Jeremy said was an RFE
https://bugs.exim.org/show_bug.cgi?id=2137#c8
Personally, I'd be happy with random callbacks defaulting to defer_ok,
which IIUC was effectively the case before 4.89.
Whilst you argue that this is a regression, I agree with Jeremy that
allowing separate controls on defer, and thus different defer behaviour
for random and the specified address is a request for enhancement.
Since I abandoned sender verify callback many years ago,
I would have to be fairly bored to write a patch for such an enhancement ...
--
Andrew C. Aitchison Cambridge, UK
andrew@???
