On Sun, 7 Jan 2018, [email protected] wrote:
https://bugs.exim.org/show_bug.cgi?id=2137
David Woodhouse <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #9 from David Woodhouse <[email protected]> ---
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
[email protected]
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
