Subject: RE: Optimising mail to many recipients

From: Dan Kohn <[email-masked]>
Date: Wed, 24 Mar 1999 01:16:27 -0800

On Mon, 22 Mar 1999, Jacob Palme wrote:

> Suppose you need to send a large e-mail message, maybe with
> a one megabyte attachment, to ten recipients on another
> continent. It might then be much more efficient usage of
> the long-distance cables, if you connected to one SMTP
> server on the other continent, and sent one copy of the
> message, asking this server to forward it to the ten
> recipients.

Without continuing this thread indefinitely, I just want to point out
how unlikely an optimization in the Internet mail system is to improve
Jacob's hypothetical scenario.

The real issue for these ten people is much more likely to their last
mile dial-up bandwidth and the problem of inadvertently downloading the
attachment over a slow dial-up line because they're using POP3.  Even
worse, it is quite unlikely that all 10 really want to read the
attachment.  A good solution is to include a URL to the attachment
stored on a web server (note that there are numerous free web services)
rather than including it as a MIME body.

If you are really worried about trans-continental bandwidth wastage,
then upload the attachment to a server on the other side of the pond.

		- dan
--
Daniel Kohn <mailto:[email-masked]>
Teledesic LLC
+1-425-602-6222 (voice)   602-0002 (fax)
http://www.teledesic.com

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 1999 10:02:17 +0100

>mile dial-up bandwidth and the problem of inadvertently downloading the

Two different problems.  For the last-hop optimization you cite, you need 
IMAP, used properly.  (And 'properly' is still a matter of vendor learning 
curve.)

Jacob is raising the long-deferred topic of application-level routing, so 
that an application can move mail efficiently, according to network 
topology.  Directly related to this is choosing among alternate servers 
according to topology, such as fetching an RFC from the 'closest' archive.

Jacob's particular example also suggests a need for global, shared email 
"backbone" relays, to keep addressees aggregated for a common long-haul 
sequence.  That strikes me as rather an interesting idea.  I think it has 
technical, operations, and business aspects to it.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                         Tel: +1 408 246 8253
Brandenburg Consulting                               Fax: +1 408 273 6464
675 Spruce Drive                             <http://www.brandenburg.com>
Sunnyvale, CA 94086 USA                 <mailto:[email-masked]>

---

From: Brad Knowles <[email-masked]>
Date: Fri, 26 Mar 1999 09:38:17 +0100

On Thu, Mar 25, 1999, Bart Schaefer <[email-masked]> wrote:

>(Meta-comment: should we continue this discussion on some other mailing
>list?)

    Yeah, probably.  Got any suggestions?

>By a remarkable coincidence, a colleague of mine (Bob Glickstein) was
>doing some research on exactly this topic last week.  His results:

    I was working on writing an RFC about ten years ago that would have
implemented per-domain mail routing.  Mail to [email-masked],
[email-masked], and [email-masked] would have sent one
copy to the MXes for .com, which would have sent one copy to the MXes for
domain1.com and one to the MXes for domain2.com, and the MXes for
domain1.com would have then forwarded on a copy to the MXes for
subdomain2.domain1.com.

    I came to realize later that this X.400-style core/border gateway
routing thing probably wouldn't work too well, since you'd have more and
more mail being dumped on the MXes for .com, and no real way for them to
recover any money to pay for that hardware.

    This would appear to be a slightly different problem, where you're
optimizing instead on sending the absolute minimum number of copies of
mail messages, regardless of where the recipients are located, what
efficient routes between you and them (and their backup MXes) may/may not
exist, etc....

    For example, if mail.uu.net (somewhere in Northern Virginia) is a
backup mail server for two hosts in two separate domains in inner outer
upper lower slobovia (which has a single 300 baud modem to Uunet serving
the entire country), then if one person on one of those hosts were to
send mail to someone on the other host and another person somewhere else
in the world, then one single copy might be sent to mail.uu.net, which
might then turn right around and send a copy down that slow line to the
recipient on the other host in the same country, as well as forwarding on
a copy to the other recipient.

    I think the lesson here is that backup MXes do not necessarily have
anything to do with packet routing efficiency, and attempting to optimize
one of these things through the other is probably a mistake.

>|                         So 1532 SMTP connections could suffice to
>|deliver those 2944 messages, a savings of 49% over the naive approach
>|of one connection per message, and a savings of 11% over the slightly
>|less naive approach of one connection per domain.

    If I'm not mistaken, this is precisely the approach taken by sendmail
and at least some other semi-intelligent MTAs.

>|                                            From my test data, it
>|looks like this extra optimization means those 2944 messages could be
>|delivered with 1384 SMTP connections---53% fewer than the naive way,
>|19% fewer than the less naive way, and 10% fewer than my first clever
>|way above.

    Since this method would only save 10% message transmissions over the
way I understand sendmail works today, I don't see how this is all that
big of a savings.

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
   Usenet is not the web.  Just because the web handles some things
 poorly is not a good reason to apply those same solutions to Usenet.