I agree that the SNR has been dropping, but also agree that it isn't low
enough yet to end all discussion.
First of all, only in the smallest installations would anybody _not_
segregate the list handling onto a separate listserver. Moreover, any
kind of mail hub, including a listserver, would of course be running with
at least (and I would argue at best...) a caching only name server. Obviously
a mail hub will build up a very rich cache, so you won't see a lot of delay
waiting for MX lookups. (And if you're not doing this, just waiting for
sendmail to start will be excrutiating, especially if you are multihomed.)
There is nothing which stops you from running multiple instances of sendmail
as queue runners, you can kick them off out of cron.
If you are doing all of this, I don't see a good reason why you would want
to initiate multiple smtp sessions to a single destination.
I agree, in general, that any packet is merely a request, and the full
onus of dealing with that request lies with the recipient. Having said that,
it may not be so easy for an smtp listener to know not to fork again to answer
a second connection request. This is particularly a problem for those starting
sendmail from inetd. Sendmail, on the other hand, probably could have code
that recognizes that it has a running child already connected to a particular
ip address, and refuse to connect again while it lives. But then a piggish
host can just ifconfig itself as many addresses as it likes, and sendmail
cannot possibly know that they are all from the same machine.
In the end, of course, we have to have hosts identified, not by ip addresses,
but by public keys, so we can prioritize whose attention is welcome. Maybe, in
the end, we'll have to have Metcalfe's e-postage to rationalize costs. Don't
you just hate natural selection?