On Wed, Apr 15, 1998 at 12:36:57AM -0000, D. J. Bernstein wrote:
> Georg v.Zezschwitz writes:
> > Therefore, the overhead of 6 Bytes in announcing and about 11-13
> > bytes in the MAIL FROM
>
> I said ``measure,'' not ``speculate.''
Sorry, I though the question was rather a "<" vs. ">".
> How many SMTP connections were there?
342531 transactions, among them 6235 down the same channel, so a
total of 336296 EHLO-connections.
> On average, how much less data do the same servers send when they
> receive HELO instead of EHLO?
In the ideal case: Just the additionally announce features:
Therefore: 250-SIZE\r\n = 10 bytes (Sorry, I forgot the initial 4 bytes).
> How many bytes were used in SIZE?
The average message size would be expressed in 3.8 digits.
Therefore appending :
" SIZE=nnnn"
to every RCPT FROM would result into 10 Bytes. So the precise
sum:
342531 x 10 Bytes = 3 425 310 (MAIL FROM - line)
336296 x 10 Bytes = 3 362 960 (EHLO extension)
------------
6 788 270 Bytes additional traffic vs.
~130 000 000 Bytes saved traffic.
>
> > The total number of bytes of the 28 messages was about 130 MB
>
> Ah. Think of how much bandwidth you could have saved if you had
> explained the facts of life to those users beforehand!
Sorry, but users tend to behave different than experts told them
to do. As least when they are customers, not students.
> To put this all in perspective: What's your total available bandwidth?
> Are you trying to connect an ISP to the Internet through a cheap modem?
Actually I don't understand your point.
You've made several suggestions like QMTP to save some bandwith.
Whats wrong about other attempts?
Moreover, the principal idea is another than QMTP: The SIZE-feature
puts the time of error notification *before* the actual transaction
than *after* the actual transaction. In general, this behaviour is
the one people tend to. Wether they want to reject unknown users
right after the "RCPT To" or want to reject Spam right after the
"RCPT To".
E.g. we have several customers working on a leased serial line.
The lowest MX points to our central mail server. If our customer
and we both support SIZE, there is another good way to stop
mail bombers. Moreover, one of them uses a message limit of 40 k and
has about 300 customers, partly in 3rd world countries. Another
customers runs a satellite link towards a marine research ship
at costs of $3 / minute - and a speed of 10 - 20 kbps.
You might understand that *they* would
really be happy for a single 10 MB message not crossing their
lines.
> > Even if the traffic would be higher, I'd suggest that there is
> > a good point in the SIZE-feature.
>
> For a typical 3K message? No. It's silly.
Why? Your numbers? No speculations, measures?
Btw: Let me quote a really interesting survey you probably know: :-)
> From: "D. J. Bernstein" <djb@???>
> Message-ID: <19970427021607.23356.qmail@???>
> Date: 27 Apr 1997 02:16:07 -0000
> To: drums@???
> Subject: ehlo survey
> Earlier today there were approximately 856000 reachable SMTP servers on
> the Internet, out of the 16 million IP addresses found in the 199701 NW
> DNS walk.
> The following chart shows the percentage of those servers that support
> various ESMTP options:
> 37% 8bitmime
> 0% chunking
> 30% dsn
> 0% enhancedstatuscodes
> 21% etrn
> 60% expn
> 68% help
> 34% onex
> 6% pipelining
> 1% saml
> 1% send
> 66% size
> 1% soml
> 0% turn
> 31% verb
> 2% vrfy
>
> Note that multihomed hosts are weighted by IP address.
It looks like SIZE is probably the mostly beloved feature of ESMTP.
Greetings,
Georg
--
*** Exim information can be found at
http://www.exim.org/ ***
