Petr Novotny wrote:
>On 21 Jul 00, at 10:30, Mark Mentovai wrote:
>
>> The problem is that there shouldn't be any "domain in
>> question," an MTA should make efficient use of a limited number of
>> SMTP sessions when transferring mail to any other MTA.
>
>This horse has been beaten to death. What do you mean by
>"should"? And why "limited number"?
I use "should" in the same manner that it is used in the documents which
define the very standards and practices over which we are arguing. In order
to be a good 'net neighbor, an MTA (note that I am not singling any MTA out
here) should not open 25 SMTP connections to the same host to transfer the
same message specifying a different destination address each time when it
can just as easily open a single connection and specify 25 destination
addresses.
>My MTA should get the messages out as soon as possible. I have
>seen the benchmarks, and I know that my MTA does exactly that.
Is it as fast as possible? In the situation above, what I suggest should
happen is actually faster and makes better use of network resources than
qmail's current implementation.
>Of course, your MTA might have different priorities. Nobody
>coerced you into using qmail, right?
I use qmail because it meets most of my needs better than anything else I've
seen or used. That doesn't mean I have to accept everything that it does as
the best possible implementation given current standards and practices. If
we all were to do that, very little progress would be made. Never assume
that there is no room for improvement.
Am I really the only one that feels this way? Does nobody else agree with
me or recognize my concerns? Are my suggestions really so far out there
that everyone is willing to write me off as a radical? I didn't think so,
but it may be the case. If I'm the only person reading who is interested in
discussing improvements, then I might as well thank you all for listening to
me as long as you have and give up.
Mark
--
Do not reply directly to this e-mail address
--
Mark Mentovai
UNIX Engineer
Gillette Global Network
