Subject: Re: Email messages: How large is too large?

From: Vernon Schryver <[email-masked]>
Date: Mon, 13 Dec 1999 17:44:39 -0700 (MST)

> From: Richard Shockey <[email-masked]>

> ...
> The simple fact is that E-Mail attachments are only going to get bigger and 
> more frequent, for no other reason than RFC2305 and RFC2532 The Internet 
> Fax standards that use SMTP. ...

I don't understand that reasoning.  Don't classic fax machines use a rather
low rate, less than 28 kbit/sec?  9600 bit/sec sounds right, but I'm
probably wrong.  Isn't the Internet fax protocol intended to be used not
only over T3's, but also over SMTP/TCP/IP/PPP/v.34 modems?  If so, and
unless Internet FAX switches to an amazingly bad encoding, most Internet
FAX's will not be much larger than they are now.  How often does your
current old FAX machine spend an hour receiving a single FAX?  One hour
at 28 kbit/sec is less than 13 MByte.  Thus, it seems unlikely that RFC
2305 and RFC 2532 will stress the current de facto limits on SMTP message
sizes.

] From: "Martin Djernaes" <[email-masked]>

] I know that the internet were not build for "general use", but it is the
] life of the net today, at it should be the goal for the people
] implementing it (us?). Let us get away from the idea that it should
] always be used the way we implemented it and change our view to how
] would the user like to use it.

There is no magic.   Users have been demanding the impossible from SMTP
on the grounds that they don't understand why not for decades.  The same
people who wouldn't try to load 10 ton of gravel in the back of their
light duty pickup truck expect email to be 99.9999% reliable, have
end-to-end delays of less than 15 seconds 99.9999% of the time, and to
move arbitrarily large files in at most 15 seconds.  Just because people
want something does not mean that it is possible or even desirable.

It's actually worse than that.  Instead of demanding a way to move large
files, they demand a way to move large email messages, and they cannot
understand the distinction.

] If the user would like to transfer 28 MB we should make it possible
] (there is always somebody who is in front of the big group, so I do not
] say that just because one person wants it we have to make it possible).

There are scaling problems.  Consider how many disk drives an ISP would
need to dedicate to mail directories to support many users moving 28 MByte
messages.  A 32 GByte drive can hold only about 1000 such messages.
Consider an ISP with 1,000,000 customers.   Remember the bad old days
before the ESMTP extension when a second SMTP hop would run out of space
in its spool directory, and the message would try to bounce.

] If the mail service from today isn't the right solution, we should
] invent a better. If all providers would allow a user to place XX MB via
] FTP on a server, ...

Didn't I see mention of something called an "external body"?  That notion
avoids the scaling problems of requiring that all spool directories and
all destination mail directories be large enough when many people decide
to forward a 28 MByte Good Times virus.

Vernon Schryver    [email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Mon, 13 Dec 1999 20:28:00 -0600

At 05:44 PM 12/13/1999 -0700, Vernon Schryver wrote:
>probably wrong.

Well classic analog fax supports a number of bit/sec rates methods up to 
and now including 33.6 as well as higher resolution and jpeg color..if you 
look at the ITU specs.

>Isn't the Internet fax protocol intended to be used not
>only over T3's, but also over SMTP/TCP/IP/PPP/v.34 modems?  I

Pure SMPT see RFC 2305. MIME content types defined by RFC 2301. There is 
work in the ITU to tunnel classic T.30 frame data over H.323 defined as 
T.38 but that is another issue.

>f so, and

Maybe...but how many fax/voice mail messages do you receive in a day? The 
IFAX    machines are either on the market or will be available in a fine 
store near you so it is reasonable to assume that the current common 5M 
limit on many email boxes will be exceeded on a regular basis.

My fax machine ( server ) doesn't spend a hour receiving a fax..but I do 
know lawyers and investment bankers fax machines where 100 -200 page fax 
transmissions are normal and a every day occurrence.

Add color to those transactions and the file size increases by 1 or more 
orders of magnitude.

RE the stress on SMTP ... face it its not just fax that is being delivered 
on email its voice mail too. See the VPIM WG specs. This is Universal 
Messaging. The ISP community simply had better get used to the applications 
that are being delivered here.

Current recommendations from Gartner, Giga and other independent IT 
consulting firms are recommending 75meg plus storage per client mail box.

Deliver the storage or lose the business...my strong recommendation to the 
ISP community...but Keith Moore's points are well taken. Users should have 
choice ... if I am unwilling to accept such large file size transactions 
then I should be able to "advertise" that fact using what ever comes out of 
the RESCAP WG.

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Richard Shockey <[email-masked]>
Date: Mon, 13 Dec 1999 20:28:00 -0600

Richard Shockey
Shockey Consulting LLC

---

From: [email-masked]
Date: Mon, 13 Dec 1999 22:56:54 -0500

> to forward a 28 MByte Good Times virus.

message/external-body dates all the way back to 1992, in RFC 1341 (the MIME
Dark Ages).  At the time, it seemed like a very good way to address the problem
in classic computer science style - instead of passing the data structure,
pass a pointer to it.

Unfortunately, for most of the Internet users of today, the availability
of long-term stable externally-reachable storage is low enough that you
usually end up dereferencing a null pointer.....
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Mon, 13 Dec 1999 22:56:54 -0500

---

From: Henry Clark <[email-masked]>
Date: Tue, 14 Dec 1999 01:53:54 -0500

At 05:44 PM 12/13/99 -0700, Vernon Schryver wrote:
>Instead of demanding a way to move large

People use email to solve a problem.  The problem == document 
distribution.  Make document distribution via something other
than email as easy as doing it via email and your "big" email
problem will just go away.

henry

---

From: Henry Clark <[email-masked]>
Date: Tue, 14 Dec 1999 01:53:54 -0500

henry

---

From: "Martin Djernaes" <[email-masked]>
Date: Tue, 14 Dec 1999 11:11:38 +0100

> want something does not mean that it is possible or even desirable.

As long as the fact is that it takes 15 seconds in average and the
reliability is 99 or more % I will not blame the user for expecting this
functionality from such a service. Our job is to not to tell the user,
that what he do is wrong but to make the service usable (I guess that
were the reason someone invented MIME in the first place). Personally I
would love another solution than encoding you files into a mail (it
actual get a size increase of 33%).

> understand the distinction.
I do not think so - if we could make a transparent way of sending large
files, the user would not care if it is a mail or something else.

There is just one fact which is in the way for any other solution - as
long as the user have a way of sending his/hers files, and it actually
works (I mean he/she have a program which make the way of doing it
transparent to him/her, and the file get to the desired destination
within a reasonably short time) there is not reason seen from the point
of the user to get another service.

> There are scaling problems.  Consider how many disk drives an ISP would
...
The size issue is there what ever (relay-)service we use! We can try to
prevent the usage being to big (why make a BASE64 encoding when we can
store it binary etc.).

> to forward a 28 MByte Good Times virus.
:-) But please tell me which "usable" programs support this function,
and what kind of providers offers this service.

I have to say that I consider the problem seen from the "dummy" users
point of view - he/she have to see the same function from his/hers work
place as well as from his/hers home computer (PC? mac?). I guess
everybody here would be able to open a ftp server in case of "an extreme
big file", but I am not sure that mr. Normal User will be able to do
this, and more he will not wait for the receiver to go online to pick it
up.

-- 
Regards,
  Martin Djernæs

--------------------------------------------------------------
Martin Djernæs                    [email-masked]
Dipl.-Ing.                             
Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741
Postfach 3246                          Fax:+49 (0511) 6747 777
30032 Hannover, Germany                http://www.ke-online.de
--------------------------------------------------------------

---

From: "Martin Djernaes" <[email-masked]>
Date: Tue, 14 Dec 1999 11:11:38 +0100

...

-- 
Regards,
  Martin Djernæs

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 14 Dec 1999 09:02:30 -0500

g'day,

Vernon Schryver wrote:
.  .  .

> on the grounds that they don't understand why not for decades.

With all due respect, we're not the law-givers, come down from on high
with the tablets. We're the hired help. Telling the users they can't
drive that screw with the hammer we sold them isn't going to cut it.

If the users who pay the bills want to email documents, and that breaks
the system, than the problem is with the system, or the interface to it,
not the users. People want to share info, and they like using the 
stored messaging paradigm to do so. It's not that they *can't*
understand why the frazzle pin can't fit into the grapple gromit, it's
just that they (quite rightly) don't care. They figure that they pay
people to worry about such things, so woe betide you if you drop the
ball at this point. Increased demand on email message sizes is something
we all agree is quite foreseable.

If the "problem" that the engineers are seeing is larger message sizes
leading to overloaded spools, then our task is to find ways to limit the
overloaded spools. Now, one way to do that is to stop people mailing
large files but to our credit, the system has apparently already been
working on better suggestions than that. Darwinian selection should do
the rest.

To me, the interesting question now is thus "have we reached a point
where the difference in degree has become a difference in kind, or can
we continue as is for a while?" Simply telling users they're misusing
the tools just creates market opportunities for your competitors.

				- peterd

------------------------------------------------------------------

  "I have discovered a way to supply the world's energy needs,
   using nothing more than gerbils on trendmills, powered by 
   raisins! It is a brilliant, original breakthrough!"

  "Yes, all well and good, but unfortunately, gerbils are allergic
   to raisins. Failure, Mr. Jones, is hardly original..."

				- paraphrasing Bloom County...

-----------------------------------------------------------------

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 14 Dec 1999 09:02:30 -0500

g'day,

Vernon Schryver wrote:
.  .  .

				- peterd

---

From: "Dick St.Peters" <[email-masked]>
Date: Tue, 14 Dec 1999 10:25:27 -0500 (EST)

> usually end up dereferencing a null pointer.....

It doesn't have to be that way.  We'll set up an anonymous FTP site
for any user who requests one, at no additional charge.  These sites
have upload capability and are protected from being used as warez
sites.

In other words, that user I wouldn't let receive a 28 MB message had
an appropriate alternative available.

The problem, at least from my perspective, is not large transfers.  It
is mixing large transfers into a service (email) that most people
expect to deliver small messages rapidly.

The problem is compounded by most users not having any idea what a MB
is.  Telling them their mailbox is clogged by a 2MB message conveys
nothing to them, but tell them it is clogged by a 25,000-line message
and they understand.

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: "Dick St.Peters" <[email-masked]>
Date: Tue, 14 Dec 1999 10:25:27 -0500 (EST)

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Dec 1999 10:56:58 -0500

Vernon Schryver wrote:

> move arbitrarily large files in at most 15 seconds.

The difference is that they can *see* the truck.  They can't see the mail
servers.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Do not suspect that I am not human.          |
[email-masked]|                                             |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 14 Dec 1999 10:56:58 -0500