Subject: Email messages: How large is too large?

From: Ross Finlayson <[email-masked]>
Date: Fri, 10 Dec 1999 17:39:49 -0800

As someone who has used the Internet since before it was even *called* the
Internet, I can remember when noone would have dreamed of sending email
messages that were even 50 kBytes in size.  Times have changed, of course,
and now it's commonplace for people to send email messages that are
significantly larger than this.

But how large is too large?  I recently chastized someone for sending me an
email message that was 3.7 MBytes in size.  (I currently get my email
delivered through a POP mailbox run by my ISP, and the 3.7 MByte message
came close to exceeding my quota.)  "That's ridiculous," I argued.  "Email
was not intended for messages even remotely as large as this."

However, I can't help but wonder if I'm being a bit old-fashioned.  Indeed,
times have changed, and message sizes that once seemed absurdly large are
now quite reasonable.

So I wonder, what do people think is a reasonable suggested maximum email
message size these days (for messages sent over the public Internet, not
just within a private intranet)?  Is there a RFC anywhere that lists a
recommended maximum size?  And should email programs issue a warning if a
user tries to send a message that's 'too large'?

	Ross.

---

From: "John W. Noerenberg" <[email-masked]>
Date: Sat, 11 Dec 1999 00:01:11 -0800

At 5:39 PM -0800 12/10/99, Ross Finlayson wrote:
>just within a private intranet)?

I'm not sure you can express this in absolute terms.  If a message is 
so large delivery of it impedes the ability of you neighbors to use 
the net, it's too large.  But I have no idea how to apply a criteria 
like that in a realistic way.  Once a message has been handed to the 
first smtp-receiver, determining if the path it transits obstructs 
other traffic at any point along its path is well beyond the ken of 
the original sender.

I suppose an smtp sender could apply a size-of-message policy to sort 
it's queue.  That at least would keep a large message from 
obstructing a gaggle of shorter ones, especially for a slow link.

>   Is there a RFC anywhere that lists a

Defining "too large" is tricky.  "Too large for whom?  The sender, 
the receiver or any hop in between?  Eudora will warn a user if he 
queues a message larger than a certain value.  The threshold can be 
set by the user.  The motivation is to warn senders using a dial-up 
connection they are about to spend a long time on the phone.  It 
might encourage senders to have some consideration for receivers of 
their message, although I wouldn't claim much chance of that.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   There is no sorrow like the memory of love
   and the knowledge it is gone forever.
   -- Marion Zimmer Bradley, "The Mists of Avalon", 1982
   ----------------------------------------------------------------------

---

From: "John W. Noerenberg" <[email-masked]>
Date: Sat, 11 Dec 1999 00:01:11 -0800

best,
-- 

john noerenberg
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Dec 1999 09:41:35 -0500

--On Saturday, 11 December, 1999 00:01 -0800 "John  W.
Noerenberg" <[email-masked]> wrote:

> >So I wonder, what do people think is a reasonable suggested
> maximum email >message size these days (for messages sent over
> the public Internet, not >just within a private intranet)?
> 
> I'm not sure you can express this in absolute terms.  If a
> message is  so large delivery of it impedes the ability of you
> neighbors to use  the net, it's too large.  But I have no idea
> how to apply a criteria  like that in a realistic way.  Once a
> message has been handed to the  first smtp-receiver,
>...

Ross,

The only thing that might need to be added to John's answer is
that you should be aware, if you are not, that a protocol
extension was added some years ago that permits a receiving SMTP
to specify the maximum size message it is willing to receive,
thereby eliminating the historically-nasty problem of having to
wait for transmission of a very long message before rejecting it
(see RFC1653).    As John's note implies, this, like everything
else, works more efficiently in the "no relay" case, or the case
where the only relay is a gateway or firewall that, itself,
enforces the size limitations, than it does with long relay
chains.

Especially at this time of year, many sites try to equip their
receiving MTAs, and, sometimes as a matter of courtesy to
others, their sending ones, with content-specific filters to
prevent large mailings of messages that contain large image,
audio, or video attachments with holiday greetings.   I
personally would not encourage the practice --having automated
intermediate systems scan messages for content to heurstically
determine what should be rejected has always impressed me as
dangerous-- but it is certainly understandable in some
circumstances and does have the advantage of trying to focus on
one of the real issues for many sites, which is not transmission
size per se.

      john

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Dec 1999 09:41:35 -0500

Ross,

      john

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 12 Dec 1999 00:45:26 -0500 (EST)

Ross Finlayson writes:
> messages that were even 50 kBytes in size.

I wouldn't bet on that.  Sometime in the mid 80's I wrote a pair of
scripts to automate breaking a file into roughly 50 KB pieces, sending
them by UUCP mail, and reassembling them.  GE Medical Systems used it
to ship around MRI images.

However, I'm now of the opinion that email is first-class mail, not
parcel post.

> But how large is too large?

I imposed a 5 MB limit here after someone sent a single message of more
than 100 MB to one of our dialup users.  This past week I had a user
get upset that we wouldn't accept a 28 MB message he wanted someone to
send him.

--
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: Sun, 12 Dec 1999 00:45:26 -0500 (EST)

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Dec 1999 11:49:56 +0100

>But how large is too large?

It is of course context dependent.

One particular case may have wider interest:
When I run open mailing lists, I've set the default size limit (above which 
one has to get moderator approval, NOT out-of-hand rejection) to 400 
Kbytes, up from the product default of 40K, which effectively blocked most 
Word documents. (Some would consider that a feature)

That's something that may be of interest as a general recommendation to 
IETF working group mailing list. But the value is a guess.

                                Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Dec 1999 11:49:56 +0100

Harald

---

From: Peter Deutsch <[email-masked]>
Date: Sun, 12 Dec 1999 11:14:38 -0500

> However, I'm now of the opinion that email is first-class mail, not

Seems like a question to be decided by users, not engineers.

Most of the mail I receive is simple text or Word docs, and thus well
under 1M, but last night I received two pieces of email from my brother
full of scanned slide images, one at 1M and one at 2M. Should I write
back and chastize my brother for inappropriate behaviour, or should I
reply with slides of my own? emember, scanners are down to $Cdn75. Oh,
and new videocards permit video capture.

Heck, seems to me that it's time to retire the buggy whips and realize
that users have a legitimate requirement for larger files sizes. This
doesn't necessarily mean every user needs it, but it points to the kind
of support the system will require in the near future.

> get upset that we wouldn't accept a 28 MB message he wanted someone to

Not every user requires this kind of bandwidth today, but the
applications to generate sch data are here (sound, multiple still
images, video, sharing executables, etc). You can't unring the bell, so
it's probably worthwhile to study what can be done to mitigate the
impact.

					- 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: Sun, 12 Dec 1999 11:14:38 -0500

- peterd

---

From: Richard Shockey <[email-masked]>
Date: Sun, 12 Dec 1999 12:06:14 -0600

> > get upset that we wouldn't accept a 28 MB message he wanted someone to

He's probably now looking for a new ISP ...

>it's probably worthwhile to study what can be done to mitigate the

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.

You can purchase IFAX machines today from HP, Panasonic and Konica. Every 
Japanese manufacturer of fax machines is in the process of bringing to 
market low cost devices that support these standards for mass global 
distribution. The ROI and cost benefits to users are quite compelling.

Oh ..BTW in the US there are at least 15 free fax to email services and 
more on the way. (see my sig file below)

ISP's and corporate email administrators should just get used to large and 
frequent email attachments, upgrade their systems, or watch their customers 
or job go somewhere else.

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: Sun, 12 Dec 1999 12:06:14 -0600

Richard Shockey
Shockey Consulting LLC

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Dec 1999 13:16:43 -0500

> it's probably worthwhile to study what can be done to mitigate the

of course this is precisely why the SMTP SIZE extension was
developed in the first place.

and when the rescap group finishes its work it will be a trivial
matter to use rescap to advertise a per-recipient max-message-size 
attribute.

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Dec 1999 13:16:43 -0500

---

From: "Fred Marshall" <[email-masked]>
Date: Sun, 12 Dec 1999 11:25:46 -0800

Harald's comment about context is very appropriate.  The discussion so far
has mixed one-to-one email, list servers, etc.  If we assume that list
servers and other more specialized applications may be venues for limits
then:
perhaps we should focus on one-to-one email as the only mechanism that most
people effectively have for 2-way data transfer.

A case in point: ftp only applies, in effect, for downloads for most users
today.  e.g. AT&T cable as an ISP doesn't even provide ftp siting for
customers.  If people can't post or don't know how to post to an ftp site
then they can't use ftp 2-way.

All this would seem to suggest one of two things:
1) Remove limits altogether as Peter Deutsch mentions
2) Have indeed a "parcel post" protocol that effectively transfers large
files, messages, etc. in a way that's more acceptable in a system context.
As good as ftp and as easy as email.
One could hope for #1.  Perhaps #2 is needed to avoid conflict in
capabilities vs. needs?  Or, is the latter about capabilities getting to be
an anachronism?

In practice, I'm sure as far as most users are concerned, there is no limit
until something can't be sent.  Then whatever the limit that exists has to
be dealt with - not before.   Obviously, SMTP SIZE is a variable becauseit's
selectable - that horse has left the barn.

Imposing limits as guidelines may help somewhat but I'd suggest that we're
talking about a small fraction of the bandwidth and memory use anyway - the
increase in numbers of users will far oustrip the addition of message size
statistics - photos or no.  Accordingly, no limits as guidelines either.

I favor free enterprise in this case - which would appear to be "no change".
When locally imposed limits become too restrictive, people will complain and
solutions will be found - either the messages will get smaller or the limits
will be increased or the user will find a new provider or.....  It seems
clear that there's no magic number.

Fred

---

From: "Fred Marshall" <[email-masked]>
Date: Sun, 12 Dec 1999 11:25:46 -0800

Fred

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Dec 1999 22:22:12 +0100

>clear that there's no magic number.

Agreed.
I generally set limits in 2 places:

- on my spool area, so that no single message fills it.
   That's called "protecting the infrastructure", and everyone should do that
   (and monitor the number of times the limit triggers, so that they know
   when to buy larger spooldisks).
- on my mailing lists, according to what they're used for (those few that
   want Word documents to be a regular feature get a higher limit).

I see no need for any hard limits - but perhaps words of advice could be nice.
Over to the user services area.....

                       Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Dec 1999 22:22:12 +0100

Agreed.

                       Harald

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 12 Dec 1999 19:05:13 -0500 (EST)

> He's probably now looking for a new ISP ...

I don't think so.  His employer has already asked for my help in
identifying why their 56k frame-relay line is so saturated.  That one
28 MB message would have occupied its full capacity for more than an
hour.

> >it's probably worthwhile to study what can be done to mitigate the

Well, I can give my answer without further study: people with
corporate or university T3 connections need to remember that the most
common connection is still a 26.4 Kbps dialup.  A 2 MB message that
takes a fraction of a second to send over a T3 (or a few seconds over
a T1) takes dialup users about ten minutes to download.

During download of a large message, dialup users get no feedback
telling them something is happening.  When they get an unusually large
message, they think something is hung and hang up.  This leaves their
mailbox locked until TCP times out, so when they dial back in and try
again they get a cryptic error message.  After two or three tries at
this they're frustrated and on the phone to support.  This almost
invariably ends with a request that we delete the message for them.

> or job go somewhere else.

The Internet's bandwidth-blessed elite should keep in mind that the
vast bulk of Internet users does not share their good fortune or the
values that depend on it.

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 12 Dec 1999 19:05:13 -0500 (EST)

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 13 Dec 1999 11:42:57 +1000 (EST)

On Sun, 12 Dec 1999, Dick St.Peters wrote:

stpete> > > > > But how large is too large?
stpete> > > > I imposed a 5 MB limit here after someone sent a single message of more
stpete> 
stpete> The Internet's bandwidth-blessed elite should keep in mind that the
stpete> vast bulk of Internet users does not share their good fortune or the
stpete> values that depend on it.

I think the question has been expanded into 'How large is too large for
who?'.  On one hand, you have the 'bandwidth-blessed elite' and on the
other hand you have the 'megabit-challenged' (ie, modem users).

Having worked for an Australian ISP with the comparitively high costs of
bandwidth (per megabyte received), anything over 1meg starts getting
worrying for dialup users.  

The main problem, from the (AU) ISP perspective, is user perceptions.  The
Internet is there, waiting to be (ab)used, by their perspective, and so
some users get rather irate at having their ISP arbitarily reject messages
over a certain size.  

The ISP, on the other hand, knows from bitter experience that any message
over a certain size is unable to be downloaded by the average user, and
prefer not to pay for receiving the message, only to not recoup any
charges from it.  (ie, the user eventually requests the message be deleted
unread or the local tech support jumps through hoops getting it to the
user).

If you have significant dialup users, reject anything over 10meg (politely
of course).  If you do not have any dialup users, 100meg seems quite
adequate for the moment.  Your local administrative policies would also
come into play (ie, just why is user suchnsuch subscribed to
Playboy-in-brown-MIME-encoding at their work address? etc)

However, this is more a matter for the DRUMS (?) list which I'm sure
someone will provide the details for shortly.

-- 
  Bruce Campbell <[email-masked]>   Not speaking for my employer
                      Systems Administrator     Regional Internet Registry
    Asia Pacific Network Information Centre    For the Asia Pacific Region

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 13 Dec 1999 11:42:57 +1000 (EST)

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Dec 1999 22:43:05 -0500

> someone will provide the details for shortly.

no, not really.  DRUMS deals with protocol, not policy.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Dec 1999 22:43:05 -0500

Keith

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 13 Dec 1999 08:05:23 -0600

The magic word is "Content-Type: message/external-body".

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 13 Dec 1999 08:05:23 -0600

---

From: "David Mitton" <[email-masked]>
Date: Mon, 13 Dec 1999 12:48:15 -0500

There's at least one popular email client that allows the user to set a 
download size threshold.  If the message size exceeds the value, then 
it  only brings down a header, with an option to explicitly download the 
entire message.

I had a similar problem when travelling once and used this feature to 
advantage.

         Dave.

>values that depend on it.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Consulting Engineer, Nortel Networks           978-288-4570 Direct
Carrier Packet Solutions, Preside              978-288-3030 FAX
Billerica, MA 01821                     [email-masked]

---

From: "David Mitton" <[email-masked]>
Date: Mon, 13 Dec 1999 12:48:15 -0500

Dave.

---

From: "Getty Verma" <[email-masked]>
Date: Mon, 13 Dec 1999 10:21:44 -0800

Can someone tell me where is the draft or a spec or even some
explanation on this RFC 2225.

Thx
getty

---

From: "Getty Verma" <[email-masked]>
Date: Mon, 13 Dec 1999 10:21:44 -0800

Thx
getty

---

From: Jacob Palme <[email-masked]>
Date: Fri, 17 Dec 1999 09:53:13 +0100

> to ship around MRI images.

This (which is supported by ESTMP nowadays) does not solve
some of the possible problems. The load on the net and on
the user mailbox storage will be the same. Even worse. If I
get a large attachment, my e-mailer asks me if I want to
download it or not. If it is split into many small parts,
my e-mailer does not give me this option (but perhaps it
should?) The ESTMP extension for splitting large messages
is not supported by some email UA vendors.

------------------------------------------------------------------------
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: Jacob Palme <[email-masked]>
Date: Fri, 17 Dec 1999 09:53:13 +0100

---

From: "Dick St.Peters" <[email-masked]>
Date: Fri, 17 Dec 1999 12:13:46 -0500 (EST)

> is not supported by some email UA vendors.

I only mentioned the example as illustration that the desire to send
large files through email has been around a very long time.

Email was used for the same reason people use it now: because it was
there.  The transfers were arranged transfers, usually between sites
with direct-dial UUCP connections and no Internet connection on at
least one end.

---

From: "Dick St.Peters" <[email-masked]>
Date: Fri, 17 Dec 1999 12:13:46 -0500 (EST)