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.
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.
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"?
--
You are receiving this mail because:
You are on the CC list for the bug.
