On Wed, 29 Jun 2005, Jeremy Harris wrote:
> Nigel Metheringham wrote:
> >
> > - in many cases the vast majority of messages could be switched
> > through a box without touching the disk at all (you would hold off
> > acknowledging the incoming message until the next hop had acked your
> > onward transmission of it).
>
> I've been wanting to hack this up for ages, to stop my queue getting
> clogged with undeliverable bounces resulting from those of my
> users who forward to AOL (in particular) which does content-based
> refusals after data-phase.
I wrote a proposal about 18 months ago for a feature I called "early
delivery", which essentially would do what you want. It could do some
other interesting things when combined with "unseen", which is why I
though of it. Philip doesn't like it, understandably :-)
http://www.cus.cam.ac.uk/~fanf2/hermes/doc/misc/hr-exim.txt
> I had in mind to use the same connection opened for a verify callout,
> if possible.
The callout connetion goes away too early.
> > That sort of thing needs a hugely different architecture to that used by
> > exim.
>
> Therein lies the rub :-)
For our purposes you wouldn't have to perform too much deep rebuilding, I
think, though it isn't an easy patch because of interactions with the
system filter and suchlike. However this simple implementation wouldn't be
able to improve disk performance because you'd still have to write the
header file and delivery journal. (I think even a high performance
implementation would have to spool the message body to disk, just in
case.)
Tony.
--
<fanf@???> <dot@???>
http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
