https://bugs.exim.org/show_bug.cgi?id=2151
--- Comment #4 from Jeremy Harris <jgh146exb@???> ---
The above fix is sufficient for the original problem, but could be regarded as
less than optimal. It retains sending SIZE for recipient callouts that are not
cacheable (as that is the cutthrough-deliver case, when we'd still like the
possibility of an early size-based reject from the target).
I did think about trying to include size info in the cache but it seems that
any reject when size was sent is basically unreliable for cache purposes (it'd
still be usable for the verify of the trigger mail). That only leave
acceptances
with size info. We could make the assumption that size is always a
trigger-level
(if looked at at all by the target), and add "<= cached size" to the
is-cache-hit
determination. But we've lost the cachability of rejects totally, which is a
big penalty. We could complexify the verify sequence to do both with- and
without-SIZE to try to determine accurately a size-based reject (more code =>
bugs, more roundtrips); this would deal with the "unreliable" point above.
I'm not sure the complexity is worth it. If anyone thinks it'd be useful
please raise it as a separate bug, classed as "wishlist", and referencing this
one.
Until/unless that is done, a good recipient callout cache entry does not
preclude
an actual-delivery reject on size grounds (and resultant bounce generation). Of
course it never did, and the same applies to content-based actual delivery
rejects.
--
You are receiving this mail because:
You are on the CC list for the bug.
