🚀 go-pugleaf

In article <DvzuKK.6L9@djwhome.demon.co.uk>
   David Woolley <david@djwhome.demon.co.uk> writes:
> 
> For an individual message, this behaviour is required by, I think,
> RFC 1123, one of the internet STD documents; it allows copies to the same
> host to be coalesced (modern Unix mailers go further, and coalesce for the
> same MX set).  I think it may do the same within batches to allow it
> avoid reconnecting to the same site multiple times.

Fair comment; it's a long time since I looked at smtp in any detail and 
I'd forgotten this. Presumably KA9Q does actually do this? Would there be 
anything to gain by writing the intermediate results to a temporary file 
to save memory?

Alternatively, is there a better way of handling the scenario where 
several messages (say 20) are all going to a mailing list and hence to 
the same set of (say) 100 addresses? There must be a better way than 
holding them all in (base) memory!

> [ History file tailing ]
> 
> (...) The reading of the
> history file would have to be done backwards to allow KA9Q itself to cut
> off early, as it can't undo hash table entries, once created.

Put like that, it's obvious isn't it. I know hash tables only from theory 
and not practise, and hadn't though about the implications of dropping 
things from the table. 

> I think there is limited future in this, as one can run a Unix clone in
> similar hardware (certainly in 4M 386SX) to that needed for a 
> protected mode KA9Q.

True, but I think the reasons stopping most people upgrading to Linux (or 
whatever) run deeper than simply hardware requirements. Familiarity with 
DOS, poor as it may be, is surely more significant. (Are there really 
that many people making serious use of KA9Q on machines with less than a 
386? By serious use I mean likely to need/want any of the enhancements 
being discussed.)

Mark.
-- 
int MeaningOfLife (void) { return 42; }   // mcr@holly.demon.co.uk
function MeaningOfLife :integer; begin MeaningOfLife := 6 * 9 end;