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: Scot McPherson <[email-masked]>
Date: Mon, 13 Dec 1999 09:26:24 -0500

My opinion is that people should use the proper service to an end. If
someone needs to transfer a file to you, than it should be done with FTP or
other similar service..Even ICQ (which negotiates clients for direct file
transfer). E-mail should be for text and small attachments related to the
message, not a method of transferring files...

Again, only in my opinion, it is the lesser learning curve of OSs such as
windows that have lead to less educated users,  and thus more often improper
use of services. This is due to Xerox/Windows Style GUI's reducing the slope
of the beginner's learning curve, although this may seem a great advantage,
it creates a steeper learning curve for even slightly more advanced uses of
their computers and subsequently the internet. It creates reliance on the
ability of the OS providers to create software.

On the other hand, we can also give some thanks the same OSs for the
explosive growth of the Internet, which is not without some cost..

Just some my opinions..

-Scot Mc Pherson
-Training Manager
-Wave Wireless Networking
-Div. of SPEEDCOM International
-Phone: 941.358.9283 ext.327
-Fax: 941.355.0291
-E-mail: [email-masked]
-http://www.speedlan.com

-----Original Message-----
From: Ross Finlayson [mailto:[email-masked]]
Sent: Friday, December 10, 1999 8:40 PM
To: [email-masked]
Subject: Email messages: How large is too large?

	Ross.

---

From: Bob Braden <[email-masked]>
Date: Mon, 13 Dec 1999 17:47:13 GMT

*> 
  *> 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,

Ross,

I recall the max size of email being an issue, but I also recall that
we customarily sent around fairly large documents as email messages.

  *> 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."
  *> 

This was addressed in section 5.3.8 of RFC1123, the second Host
Requirements RFC.  "Mailer software MUST be able to send and receive
messages of at least 64K bytes in length (including header), and a much
larger maximum size is highly desirable."

  *> 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: Bob Braden <[email-masked]>
Date: Mon, 13 Dec 1999 17:47:13 GMT

*> 

Ross,

---

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: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Dec 1999 08:35:04 -0600

Brian - is this observation too detailed to include in the Transparency
draft?

I'm thinking that at least some part of the loss-of-transparency issues
might get more attention from the nice people who want to put application
gateways between themselves and the rest of the world if you point out that
this has led to unintended results like 28-Megabyte attachments, because
it's MUCH easier to misuse e-mail for file transfer than it is to use
message/external bodies that invoke FTP for file transfer for an arbitrary
user inside a corporate firewall.

I'm trying to KEEP this from sounding like "negotiating with terrorists",
but it's not working, is it?

Spencer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 13, 1999 9:57 PM
To: Vernon Schryver
Cc: [email-masked]
Subject: Re: Email messages: How large is too large?

> 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: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Dec 1999 08:35:04 -0600

Spencer

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 14 Dec 1999 10:38:59 -0500

In message <[email-masked]>, "Sp

> user inside a corporate firewall.

The large email issue is mostly a UI issue.  To attach a file with most 
popular mail clients, one simply has to click on a few menues.  Little or no 
external configuration is required.  For an external reference, one has to 
upload the file to some repository, and make sure that mail message is 
delayed until the upload is complete.  Repositories vary in name, access 
method, authentication, etc., even without firewalls and NAT.  (It cannot, in
general, be on the user's machine, because dial-up machines aren't connected
all the time.)  The sender's mail system probably can't do that stuff
transparently, because of the authentication issues.  And the send needs 
a progress indicator for the upload of the file as well as the mail.

Bottom line:  it's not just harder, it's inherently harder, but good UIs would 
help a lot.

		--Steve Bellovin

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 14 Dec 1999 10:38:59 -0500

--Steve Bellovin

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Dec 1999 10:09:13 -0600

Steve,

You said this better than I could have - loss of transparency is making it
harder for application designers to make correct use of the Internet easier
for users, and it wasn't THAT easy to make correct use easy in the FIRST
place...

Spencer

> From: Steven M. Bellovin [mailto:[email-masked]]
> Sent: Tuesday, December 14, 1999 9:39 AM
> To: Dawkins, Spencer [RICH1:2011-I:EXCH]
> Cc: [email-masked]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Dec 1999 10:09:13 -0600

Steve,

Spencer

---

From: Danny Iacovou <[email-masked]>
Date: Tue, 14 Dec 1999 10:30:37 -0600

> in its spool directory, and the message would try to bounce.

 Maybe we need to start a working group responsible for following
 the current street price of storage, determining when affordability 
 calls for a change in protocol. That is the consequence of what you
 are saying is it not?

 In this particular case, for instance, why not let the ISPs figure 
 out how to deal with the problem? Why "ruin" a good thing for everyone
 just because increasing storage may cut into an ISPs profit margins.

 People can't always run their own FTP server. They are left with 2
 options: snail-mail; or e-mail. Who expects the choice to be snail-mail? 
 You do? Really?

 "How large is too large?" - we shouldn't be asking this question. We 
 should be asking the question "What do you do when too large tries to
 enter your system?"

----------------------------------------------------------------------------
----
Neophytos Iacovou                                              Ancept Inc.
[email-masked]                                             400 First Ave
N.
www.ancept.com                                                 Suite 450

---

From: Danny Iacovou <[email-masked]>
Date: Tue, 14 Dec 1999 10:30:37 -0600

---

From: Andrew Fletcher <[email-masked]>
Date: Tue, 14 Dec 1999 17:13:55 -0000

It could be argued that the 'correct' solution to large mail messages is for
the 'system' (mail exchanger)  to handle all messages the same from the user
perspective but to sort the messages based on size and transfer then over
more than one smtp session.  Traffic filters/routing policies could then
ensure that smaller messages are sent quickly and larger messages delayed
until bandwidth becomes available.  The mail could then be split into
different pop mailboxes (normal and bulk) for later retrieval or the mail
tool could look at the headers before download.

Its not an original idea and I am sure that a lot of ISPs do it but simple
solutions can get forgotten at times. 

The point is that whilst educating users is a _GOOD_ thing. Human nature
means that users will look for the easy solution and that means that they
will find a single method for sending attachments and stick to it.

Anyway how do you define large, Ten years ago it was 64K, now it is
10+(?)MB, next year ?  

The solution must be scalable with the network infrastructure which means
that the ISPs/Gateways should be responsible for implementing size-based
routing policies.

Leave the users out of it, many of them have enough trouble setting up the
existing mail options. Does anyone really want the users on a network
defining the size-based routing policy on a per desktop basis ?

Just my opinion, flame me if you want :)

Andy Fletcher

---

From: Bob Braden <[email-masked]>
Date: Tue, 14 Dec 1999 18:46:38 GMT

*> 
  *> 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.
  *> 

Vernon,

As I recall, the reason that Mime was developed was precisely to allow
email to substitute for many file transfers.  Before Mime, it was
always a bit of an annoyance/embarassment that email could not be used
in place of FTP for binary files.

But I guess we forgot to take the next big step, redesigning email to
properly scale to handling arbitrarily large messages in a relatively
graceful manner when necessary.

Bob Braden

  *> 
  *> ] 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.
  *>

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 14 Dec 1999 12:29:57 -0700 (MST)

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

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

> 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  ...

Those of us with engineering pretensions don't try to offer the impossible
or the undesirable.  If you go to a gravel pit with your light duty
pickup truck and ask 3 tons of gravel, the operators will be extremely
reluctant.  They know that you'll blame them for the consequences.

> 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.

Well, based on having been around for a long time (I met the net in ~1971),
I do think so.  Even when people have perfectly good FTP areas available,
they still try email first.  Even worse, unless you impose limits on file
sizes on FTP areas, those who will use FTP (usually after trying email
and hitting administrative limits) don't stop to think.  They'll try to
send 600 MByte files over 56K links instead of doing the obvious
computation and realizing that a CDROM would be quicker.
Once you point out the obvious computation, only the hopelessly
pointy-haired are huffy.

> 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.

We disagree.  But I also think that no one should be allowed a driver's
license without passing a test that includes changing a tire and checking
a spark plug.  It is impossible to hide the difference between an external
path involving T1's and an internal path involving 100 Mbit/sec and 1000
Mbit/sec LAN's.

> 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.).

The scaling problem I meant exists only if you insist on a relay-service.
The reasons why FTP and SMTP are of similar ages are still compelling.

> :-) But please tell me which "usable" programs support this function,
> and what kind of providers offers this service.

That sounds like a coding opportunity.
The common FTP implementations also need to be enhanced to support the new
encryption options.  

> 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.

Instead of assuming people are stupid and pandering to their laziness,
why not educate them?  When you buy a light duty pickup truck, you
are bombarded with its load limits.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 14 Dec 1999 12:29:57 -0700 (MST)

---

From: [email-masked]
Date: Tue, 14 Dec 1999 18:03:36 -0500

From Dave Crocker: 
> 
> 
> In fact ESMTP is getting quite good at supporting large file 
> transfers:
> 
  < Items Snipped >
> 
> Since it is a highly asynchronous channel, with potentially very high 
> latencies, email is a bit of a challenge for dealing with 
> arbitrary message 
> sizes.  The existing and emerging specifications appear to be 
> adequate to 
> the task, but implementation has been slow.  That is almost 
> certainly a 
> question of lack of market pull.
> 
> d/
> 
> =-=-=-=-=
> Dave Crocker  <[email-masked]>
> Brandenburg Consulting  <www.brandenburg.com>
> Tel: +1.408.246.8253,  Fax: +1.408.273.6464
> 675 Spruce Drive,  Sunnyvale, CA 94086 USA 
> 
> 

I really have to agree with Dave's observations above.  The challenges we
face
are more related to properly setting the expectations of the end users than 
with actually getting the message delivered.  They tend to view SMTP message
transport throughout the entire Internet as equal to the internal transports
among our various offices.  These users have no conception of the
differences 
between locally connected recipients and dial-up recipients.  On the one
hand 
we have done our jobs extremely well and made Internet E-mail look
virtually identical to internal E-mail.  In MOST cases the differences are
negligible.  The times we run into problems are when a message is lost, or a
bounce
message is improperly addressed due to some problem with the user's MUA and
it 
never gets delivered to the end user.  These are issues that are not easily 
addressed in working groups and RFCs.

Greg G.

Greg Guldenschuh
Director, Distributed Systems Networking
National Data Corporation
1 National Data Plaza
Atlanta, GA 30329-2010
Phone (404)728-2966
Fax       (404)728-2282
E-mail [email-masked]

---

From: [email-masked]
Date: Tue, 14 Dec 1999 18:03:36 -0500

< Items Snipped >

Greg G.

Greg Guldenschuh

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 16 Dec 1999 16:30:25 -0500

> From: Jon Knight <[email-masked]>

    > sending an email with a large Word attachment to all 15000 users on
    > campus isn't a good idea as our mail servers will melt. ... especially
    > from non-academic departments who are used to doing paper based mass
    > mailings to students. ... depite us offering to put the Word document
    > on a web page and then send a small email pointing at it

This is an important distinction to make, between sending a large item to one
person who know's it's coming (which I view as an acceptable way to transfer
something from one person to another - but more on this below), and sending
it to an entire mailing list, most of whom won't be interested in the item.
Resources are far better used here by putting the item up for retrieval, so
that only those who are interested in it expend the resources to get a copy.

The caveat about using the email system to transfer things from one user to
another is that it is, after all, an *email* system, and engineered for that,
not a generic bulk-data-transfer system. To use a real-world analogy, the
post-office may take parcels, but above a certain size, you have to switch to
a shipping company, which is set up to deal with larger items. In a similar
vein, the email system was designed for certain characteristic payloads,
particularly size - i.e. *email*.

	Noel

---

From: Danny Iacovou <[email-masked]>
Date: Thu, 16 Dec 1999 16:57:07 -0600

> From: J. Noel Chiappa [mailto:[email-masked]]
> Sent: Thursday, December 16, 1999 3:30 PM
> To: [email-masked]
> Cc: [email-masked]
 
  Speaking of University campuses:

  The University of Minnesota has a great looking mall. They spend a 
  lot of time and money maintaining the trees, shrubs, and grass. The 
  sidewalks running between buildings were a great idea. A lot of people
  used them and stayed off the grass. But you know, a lot of other people 
  did the math and the shortest distance between 2 points is a straight 
  line. Too bad the sidewalks weren't designed to run along that line. 
  So a lot of nice pretty grass turned to ugly mud as more and more people 
  stomped over the grass to get were they needed to be in the most "optimal"
  way.

  This practice continued for a long time. Sure, eventually signs went up
  telling people not to step on the grass. But that didn't work.

  Eventually the University put chain fences on every corner of the mall. 
  The chain fences look nice. The grass is well maintained now. I guess they

  decided not to add sidewalks.

  E-mail should either be able to handle a message of any size or the user 
  should be told right away that the message can't be sent. People have 
  already mentioned the GUI aspect of this problem. I agree to a large
extent
  with them.

  So the problem essentially comes down to money. When are message sizes 
  causing too many problems for admins to cost justify their efforts on? At 
  that point we either decide to put up nice fences or we build sidewalks.

  The post-office has a nice fence in place. They didn't want to build a 
  sidewalk. I think eventually we are going to opt for the sidewalk.

---

From: "Mason, Shane" <[email-masked]>
Date: Thu, 16 Dec 1999 18:39:49 -0500

What's the SOLUTION???  Watching this thread is like watching a dog chase
it's tail.  The distinguished left hand keeps saying that "E-mail wasn't
designed to do this."  The down and dirty right hand keeps asserting "User's
will keep using it if there is no good alternative."

Well I have news for all of you.  You are all correct!

Quit arguing and let's come up with a solution.

Shall a new WG be created to deal with this issue??

ICMan

---

From: Robin Uyeshiro <[email-masked]>
Date: Thu, 16 Dec 1999 13:50:01 -1000

Comment from a rookie:

Perhaps the IETF, eminent body that it is, could put out somethng that 
RECOMMENDs that email software vendors display the size of email 
attachments and maybe the time it would take to download on an analog 
modem?  Then at least the information is there to see.  Otherwise a user 
has no clue that a problem might exist.  I can't see that a software vendor 
would have any motivation to provide that information unless someone 
asked/told them to.

-----Original Message-----
From:	Michael H. Warfield [SMTP:[email-masked]]
Sent:	Thursday, December 16, 1999 12:21 PM
To:	J. Noel Chiappa
Cc:	[email-masked]
Subject:	Re: Email messages: How large is too large?

> that only those who are interested in it expend the resources to get a 
copy.

The only problem with that is that the inDUHviduals who are at the heart of 
the problem are the very ones who will have no clue about what that 
distinction is.  Most of the time, they don't even realize they are sending 
a monsterous bloated blob.  One person I have in mind knocked her manager 
off mail by sending a monster to her entire department and his download 
then started timing out.  She later asked me "well, just how am I suppose 
to tell how big it is in the first place?"  One person told me that they 
didn't understand why they needed to learn how to something like "zip".  It 
wasn't important to their jobs so why should they have to learn it.
These are the people we are going to try and tell "you can send it to one 
person if they are expecting it but don't send it to a list" (what's a list 
- remember aliases) "and they're not".  That's only going to trade one 
brand of confusion for another.

	[...]

--
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: Robin Uyeshiro <[email-masked]>
Date: Thu, 16 Dec 1999 13:50:01 -1000

Comment from a rookie:

-----Original Message-----
From:	Michael H. Warfield [SMTP:[email-masked]]
Sent:	Thursday, December 16, 1999 12:21 PM
To:	J. Noel Chiappa
Cc:	[email-masked]
Subject:	Re: Email messages: How large is too large?

	[...]

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 16 Dec 1999 20:20:53 -0700 (MST)

| From: Robin Uyeshiro <[email-masked]>

| Perhaps the IETF, eminent body that it is, could put out somethng that 
| RECOMMENDs that email software vendors display the size of email 
| attachments and maybe the time it would take to download on an analog 
| modem?  ...

That points to a good solution, but does not go far enough.

The IETF should follow the U.S.Postal Service, FedEx, AirBourne and the
rest of the real world carriers, and publish combined dimension and weight
limits for SMTP parcels.   We should change the old RFC 1123 minimum
maximum to be a generous but flat do-not-ever-exceed maximum, stop the
confusion among users, and squelch the years of gabage software from junk
vendors.  A 20-50 MByte limit would allow most of the abuses that have
accumulated to continue, while stopping worse.

And yes, of course, consenting adults can always do anything their
perverse hearts desire with their private packets.

 ..........

>   that point we either decide to put up nice fences or we build sidewalks.

The issue for the Post Office and SMTP has nothing to do with money nor
with "causing too many problems for admins."  In both cases, the transport
mechanisms simply don't work when pushed far beyond their design limits.
No plausible amount of money would let the U.S.Post Office deliver 500
kg. machinery.  It's not just the carriers who walk beats delivering mail,
but the tiny trucks they use that make the idea of mailing freight
obviously silly.  Imagine that you do give the USPS the money necessary
to replace all of their cute little jitneys with 3 ton (payload, not just
gvw) delivery trucks so that they could serve as a motor carrier.  Now
envision the consequences on city streets and for your letters.

On the wires, no amount of money could make SMTP carry GByte files--at
least not this decade--yes, eventually, maybe that will change, just as
the de facto SMTP limit has grown by at least 20X and probably 100X in
the last 15 years.

Yes, you could pay the USPS to run a motor carrier subsidiary, and you
might even use a few of the existing post offices for the freight yards.
However, would not change the letter and small parcel delivery system.
You would be creating a new network/protocol.  Again there are good reasons
why SMTP is of about the same age as FTP, as all of us here should know
(or keep silent).

SMTP has inevitable, unfixable, and *desirable* design limits would stop
flaunting their need for technical information.  Because SMTP transfers
typically involves at least 4 computers (even when only 1 is listed in
the Received headers) and often half dozen, and because each computer must
make a copy of the message in "stable storage," SMTP is simply and
desirably wrong for massive data transfers.  When you are moving big files,
you do not want to use an obligatory multi-store-and-forward scheme like
SMTP, no more than you want to put a 200 kg engine block into a letter
carrier's shoulder bag.

And no, automatically breaking up a 10 GByte file into 10,000 pieces would
not affect the problem any more than breaking up a 500 kg. freight shipment
would make it fit a USPS jitney, your mailbox, or the parcel-pickup counter
at your local post office.

And no, don't talk about making SMTP not be store-and-forward.  That is
a desirable and vital feature of a long-range mail transport protocol.

} When the sending user injects the message into the mail system, the SMTP
} server could detect large e-mail attachments and replace them with reference
} pointers; it would then cache the attachment someplace; possibly in local
} storage, ...

Thank you very much, but NO THANK YOU!
Having arbitrary SMTP MTA's in the path capriciously make copies of my
messages, and then forge and send new text that I did not write would not
merely be a hassle to implement, but has so many awesome non-technical
implications that I don't know where to start.

} When the receiving user's mail agent sees such a reference, it can directly
} contact the caching server and download the attachment. This retrieval can
} happen immediately or it can wait until the user explicitly requests it. The
} retrieval protocol should support interruption and restart of the download
} process.

If that could work, then why not move all email that way?
(one problem among many, authentication)

} In addition, SMTP servers which handle the e-mail message between the
} initial server and the end user could choose to fetch the attachment on
} behalf of the user and reassemble the e-mail message into a monolithic
} whole. They would presumably do this based on some local policy.

Part of the trouble may be in thinking of an "SMTP server" as something
like an HTTP server run by an ISP.  It's not.
Note also that SMTP servers are MTA's; SMTP is about Mail Transport.
Mail User Agents often don't talk to MTA's at all for receiving email
(e.g. UNIX where they just look in a specially named file)

]   > What's the SOLUTION?
]   
]       :
]       * ^Subject:.*How large is too large
]       /dev/null
]   
]   procmail is your friend

] Great solution for the last mile. Shame it makes some people pay to import
] what they will throw away...

I think that missed our esteemed colleague's point.  He recipe does
not discard messages, but instead messages with a particular subject
line, perhaps because he thinks they're uniformly without merit.
He is certainly right about messages that equate monetary costs
with all of the other design parameters that are traded off, at
least in any forum that is supposed to be about engineering.

I suppose it's too much to hope that this modest question won't get
turned into yet another official IETF Working Group that will spend 3
years and produce another 100,000 words of English that will need to be
ignored by people with lives, or at least engineering jobs.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 16 Dec 1999 20:20:53 -0700 (MST)

..........

 
]   > What's the SOLUTION?
]   
]       :

---

From: "Linscheid, Sven" <[email-masked]>
Date: Fri, 17 Dec 1999 09:37:41 +0100

Sorry, girls and boys. I could not understand what this
discussion should keep here.

You're discussion a point which everyone should decide 
in there own world.

I think Mails from 1 k - 1000 MB are OK. Because with
a 10GB Connection is that really something like should
I drive a Porsche or an Lamborgini!

This is not the place to discuss such a stuff!

Use a newsgroup for it, that like nonsene.internet.org!

Cya

.:MCM:. Sven Linscheid

BTW: /dev/null (I love procmail rules ;-) )

> 
> Tim's suggestion has real merit.  It's an embodiment of what 
> I suggested in
> an earlier post - without being the inventor - that something 
> as easy as
> email and as flexible as ftp might be a really good idea - if we agree
> there's a real problem.  How does one proceed with this in IETF?
> 
> To summarize much of what's been said and to wholeheartedly throw my
> (crrent) bias into it:
> 
> I continue to reject the notions:
> 1) People who are clueless are pathetic examples of internet 
> humanity.  At
> least training should be required.
> 2) We need to have rules or guidelines for email.
> 
> I continue to support the ideas:
> 1) Users are the public now - they don't understand all the underlying
> technical details.  Accept it and deal with the reality.  
> They will send
> files that somebody (with good reason) will deem are "too big".
> 2) Focus on the real issues - not the things that happen at 3 
> sigma.  Are
> download rejections and other disruptions at 1 sigma, 3 
> sigma, 6 sigma?
> What's an acceptable rate?
> 3) Users and providers alike will respond to real problems - 
> either with
> larger capabilities or smaller message content.
> 4)  Hard drives are quite cheap.  Populations are rising 
> rapidly.  File
> sizes have reason to be going up as well.  Pipes are getting 
> fatter.  Right
> now storage spaces are limiting and pipes/access (therefore 
> transport times)
> are limiting.
> 
> So, if we need to do something, let's support at least the 
> spirit of Tim's
> idea and make something happen.  First thing on the agenda 
> should be to
> decide if we need to do something - which will include at 
> what cost?  to
> what benefit?  for how long (i.e. will the need disappear before the
> solution appears)?  I'm not suggesting a flurry of emails to 
> address these
> questions right here and now.  I'm suggesting a bit more 
> deliberate process
> to deal with it.
> 
> Fred Marshall
> Mission Systems, Inc.
> http://fcmarshall.home.mindspring.com
> http://expert-market.com/pengroup/missionsystems/index.html
> 
> 
> ----- Original Message -----
> From: Tim Dierks <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, December 16, 1999 4:21 PM
> > OK, I'll make a suggestion.
> >
> > When the sending user injects the message into the mail 
> system, the SMTP
> > server could detect large e-mail attachments and replace them with
> reference
> > pointers; it would then cache the attachment someplace; 
> possibly in local
> > storage, but an ISP or an enterprise with multiple SMTP 
> servers could have
> a
> > seperate set of file storage servers. The reference pointer 
> would refer to
> > the storage location of the attachment and would be 
> obscurely chosen in a
> > manner to make it difficult to index and/or retrieve 
> attachments without
> > access to the e-mail message containing the reference link.
> >
> > When the receiving user's mail agent sees such a reference, it can
> directly
> > contact the caching server and download the attachment. 
> This retrieval can
> > happen immediately or it can wait until the user explicitly 
> requests it.
> The
> > retrieval protocol should support interruption and restart 
> of the download
> > process.
> >
> > In addition, SMTP servers which handle the e-mail message 
> between the
> > initial server and the end user could choose to fetch the 
> attachment on
> > behalf of the user and reassemble the e-mail message into a 
> monolithic
> > whole. They would presumably do this based on some local policy.
> >
> > The attachment would be deleted from the SMTP server's 
> cache based on some
> > set of criteria, which could include:
> >  - After some period of time
> >  - After being completely fetched by the intended recipient[s]
> >  - Some combination of the above.
> >
> > If the initial SMTP server doesn't have enough caching 
> space, the user
> agent
> > could automatically upload the attachment to some other 
> caching server
> > (possibly just using the user's local machine, if it has appropriate
> access
> > to the Internet and sufficient availability) and edit the 
> outgoing message
> > to include a reference rather than the inline attachment.
> >
> > Regardless, compression should be added to MIME and 
> integrated into user
> > agents to automatically compress and decompress large attachments.
> >
> > While it's non-trivial to implement and deploy this 
> proposal, it would
> seem
> > to offer a more flexible mechanism for large message 
> delivery without
> > forcing users to unduly conform their usage to the limitations of
> > implementations.
> >
> >  - Tim
> >
> > Tim Dierks
> > Chief Technology Officer, Certicom
> > [email-masked]
> > 510.780.5409 [Hayward] -- 905.501.3791 [Mississauga]
> >
> > > From: Mason, Shane [mailto:[email-masked]]
> > > Sent: Thursday, December 16, 1999 3:40 PM
> > > To: [email-masked]
> > > What's the SOLUTION???  Watching this thread is like 
> watching a dog
> chase
> > >   This practice continued for a long time. Sure, 
> eventually signs went
> up
> > >   Eventually the University put chain fences on every 
> corner of the
> mall.
> > > Neophytos Iacovou                                         
>      Ancept
> Inc.
> > > www.ancept.com                                            
>      Suite 450

---

From: "Linscheid, Sven" <[email-masked]>
Date: Fri, 17 Dec 1999 09:37:41 +0100

Cya

.:MCM:. Sven Linscheid

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Dec 1999 09:24:01 -0700 (MST)

> From: "Linscheid, Sven" <[email-masked]>

> Use a newsgroup for it, that like nonsene.internet.org!

That statement is as wrong as the statements that there should be no limits
on SMTP message sizes.  The main charter or goal of the IETF is about
interoperability.  What started this thread was a reference to the ancient
complaint about very large SMTP messages not getting through.  It as a
reference to an interoperability problem among SMTP servers, and as such
is clearly an IETF topic, although perhaps not for the main list.
The maximum size of SMTP messges is just as legitimate a topic today
as it was when section 5.3.8 of RFC 1123 was published 10 years ago.

Without a published standard for a maximum SMTP message size, users are
unable to know when their email messages will be delivered and when they
will fail.

There are inevitiably limits on everything, from SMTP message sizes to
FTP file sizes.  Those limits involve administrative fiat as well as
external considerations (e.g. physical disk) and other such limits as
protocol limits.  If the IETF would say "No SMTP or ESMTP message should
be larger than 28 MBytes," then the people trying to move pianos using
virtual FedEx envelopes would be happy....well, I am making the big leap
of assuming that email GUI's would tell users when their harmonicas got
too big to fit in an FedEx or AirBourne envelope.   Really fancy GUI's
could to really fancy things, such as try to use FTP, HTTP, or external
SMTP bodies when offered a piano.

Without a standard maximum SMTP size (and not just a minimum maximum as 
in RFC 1123), really fancy GUI's are impossible, since they can't know
whether a 280 MByte attachment will work.

Note that contrary to some implications, no outfit that I've encountered
uses the same procedures for shipping overnight letters (SMTP) as pianos
(FTP, NSF, rcp).  The choice of motor carrier for the piano and courier
service for the overnight letter is often left to the shipping department.
However, things generally work as well when you put your overnight letter
on a pallet and call the shipping department as when you put your piano
in the FedEx pile on corner of the adminstrator's desk.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Dec 1999 09:24:01 -0700 (MST)

---

From: "Mason, Shane" <[email-masked]>
Date: Fri, 17 Dec 1999 14:57:49 -0500

A couple of points.  In 3) you say that you demand that message not be able
to be altered.  Can that be done?  I can only think that alteration is
detectable (signatures, et. al.)

Also, I would add that if a store and forward method is used, the message
must not be readable at the storage site.  These days, users have a minor
expectation of privacy (in fact, I would imagine that a poll of Joe Shmoe
email users would show that most of them have high expectations of privacy)
because the email process gets most mail to it's destination in one shot.
Hijacking a session is hard (for the non-dedicated), so it can't happen all
that often, and email that doesn't get sent to an intermediate hub is on and
off the net quickly.  However, if the message is stored in clear text on an
intermediary server that is universally accessable...

Security Issue.

At least most people's mail servers at, say, an ISP are behind some form of
protection from the average script kiddie, and corporate email servers are
typically behind a Firewall.  This allows the luxury of mail storage in
plain text.  However, temporary storage sites that anyone can access should
store the email in an encrypted file.  How do we get encryption into the
equation?  Is there another way?  Do we, as a group, believe that privacy is
a requirement?

ICMan

-----Original Message-----
From: Martin Djernaes [mailto:[email-masked]]
Sent: Friday, December 17, 1999 3:59 AM
To: Vernon Schryver; [email-masked]
Subject: Re: Email messages: How large is too large?

Hi Veron,

Vernon Schryver wrote:
> (I'm not replying to the list because you didn't)
Sorry - I answer back to the list....

> > I will not try to pick out all the points where we do not agree, but
> > just say than it is not always possible to create a visible metaphor for
> > a virtual function. I agree with you that we actually have or will get a
> > problem, but I can not accept that we tell the user "it was not supposed
> > to be used that way" - that does not work for me.
> 
> Of course, you must explain convincingly why it's not supposed to be
> used that way, and then offer a reasonable alternative.

Yes you are right, we should all suggest some way of solving this
problem.

I have the following "demands" to such a solution:
1. It should be possible for dial-up users to send a large message from
one user to another (relay)
2. It should be possible for a user to reject a big incomming message.
3. The message text may not be altered.
4. We should make the transmition as efficient as possible.
5. *All* users should be able to use the new service without knowing how
what it is (I already think it is a problem that we call the retrieval
service for POP3 and the transmit/send service for SMTP!)

What I could imagine is a new MIME-like mail format where all
attachments are stored in external files. When sending the messages, the
transmit protocol communicate with the relay/mail server to figure out
of the max message size (totally) it would accept. If we are below the
limit the messages it might be "legal" to attach the external messages
binary at the end of the message (including MIME-like headers). if we
are abowe the limit we transmit the attachments in a ftp like fashion or
at least as efficient as we can to a attachment-relay-server. 

Another "nice to have" feature would be the negotiate the place where to
relay the attachments. 
- Lets assume that a machine with a permanent connection to the net want
to send a large message. It would be prefered that the message is send
to the end receiver but the attachments is stored locally until the
receiver retreive/delete it (or another rule apply). 
- Lets assume that a dial-up user want to send a large message. Now it
would be prefered that the message is moved as little as possible, so
the mail client ask the mail server where to deliver the attachments.
The mail server (based on the mail of cource) try to find the closed
relay server which would accept an attachment of this size (for example
the mail server itself, or in case of missing resources another mail
server on the path to the receiver).

--- 
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: "Mason, Shane" <[email-masked]>
Date: Fri, 17 Dec 1999 14:57:49 -0500

Security Issue.

ICMan

-----Original Message-----
From: Martin Djernaes [mailto:[email-masked]]
Sent: Friday, December 17, 1999 3:59 AM
To: Vernon Schryver; [email-masked]
Subject: Re: Email messages: How large is too large?

Hi Veron,

--- 
Regards,
  Martin Djernæs

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Dec 1999 12:49:57 -0700 (MST)

> From: [email-masked]

> ...
> No, it would be an old protocol.  See RFC1440, from July 1993.
>
> Is there sufficient interest to create a working group to overhaul RFC1440
> into something more usable in today's Internet?

In today's internet, filled with mentally challenged hacker d00ds, who
would allow any installation of a protocol that could fit the title
"Sender-Initiated/Unsolicited File Transfer" to move files larger than a
very few MByte, or what SMTP can already be (ab)used to move?
"Unsolicited" is the killer.

In other words, do you still have a writable anonymous FTP area?

Yes, I agree that is still entirely possible and quite desirable to have
a writable anonymous FTP account, but only if you erect sufficient
defenses, such as limiting file sizes and names and making files written
by outsiders unreadable by outsiders (thus fixing the warez/gif plague),
and if you are willing to deal with endless shrill warnings from CERT and
many other well meaning parties that your anonymous FTP area is writable.

Could such defenses be used with a "Sender-Initiated/Unsolicited File
Transfer" system?--probably, but they would not fix the reason for having
such a protocol.  The reason for it now seems to be to hide the unhidable
differences between big and small files and between internal and external
file transfers.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Dec 1999 12:49:57 -0700 (MST)

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Fri, 17 Dec 1999 13:52:58 -0600 (CST)

>into something more usable in today's Internet?

People using SMTP for large file transfer has been a pet peeve of mine for 
several years, having been tasked with administering email for a large federal 
agency (I don't do that anymore, thankfully, but I sympathize with admins who 
do), so I for one would be quite interested in participating in such an effort 

RGF

Robert G. Ferrell
Internet Technologist
National Business Center, US DoI
[email-masked]

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Fri, 17 Dec 1999 13:52:58 -0600 (CST)

RGF

Robert G. Ferrell
Internet Technologist

---

From: "Mason, Shane" <[email-masked]>
Date: Fri, 17 Dec 1999 15:04:38 -0500

Does ESMTP support the recipient being able to tell the sender to not send?
How about when I have a POP or IMAP client, and my ISP has the SMTP server?
Can I easily and transparently set an attribute for myself at the SMTP
server that instructs the sender to abort if the message is over my personal
limit?  Is the ISP going to support the idea that I can set my own recieve
limit and, more to the point, that I may set it to infinity?

How do we make this work?  Is a new protocol needed?

ICMan

-----Original Message-----
From: Dick St.Peters [mailto:[email-masked]]
Sent: Friday, December 17, 1999 10:50 AM
To: Stephen Sprunk
Cc: [email-masked]
Subject: Re: Email messages: How large is too large?

> Customers are generally much happier when you give them what they ask for
> instead of forcing them to use something else; if people want to be able
to
> mail full DVDs to each other, it's our job to determine how to make that
> technically feasible and (hopefully) efficient.

Communication has the unusual property of having two users, and sender
and recipient don't always agree on what they want.  I for one think
it is *not* the ietf's job to continue making it ever easier to send
what recipients do not want.  The recipients' wishes deserve respect,
and the inability of email (as it exists today) to take them into
account is a major flaw.

My first posting in this thread observed that I had imposed our 5 MB
limit on email message size because someone sent a 100 MB email to one
of our dialup users.  A one-size-fits-all limit is a rather blunt
instrument for protecting users, and it occasionally gets in the way
of things users legitimately want to transfer.  It's a balancing act
with no happy alternative.

--
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: "Mason, Shane" <[email-masked]>
Date: Fri, 17 Dec 1999 15:04:38 -0500

ICMan

-----Original Message-----
From: Dick St.Peters [mailto:[email-masked]]
Sent: Friday, December 17, 1999 10:50 AM
To: Stephen Sprunk
Cc: [email-masked]
Subject: Re: Email messages: How large is too large?

to

---

From: "Mason, Shane" <[email-masked]>
Date: Fri, 17 Dec 1999 15:23:50 -0500

But I can do that already, by sending an email with a huge attachment direct
to your SMTP server that has a destination with a name and IP, but no
physical site.  It will stay at your site until your SMTP timeout kicks in.

This is, of course, assuming that the RFC still says all SMTP servers must
accept mail to any destination, and your site is RFC compliant.

What about an SMTP server negotiating a size limit based on a profile for
the mailbox of the recipient?  Or perhaps a hold and verify, so the
recipient is notified of the document, it's size, who sent it, and at what
time, and then the recipient could send an ACK or a FIN for immediate
delivery or immediate bounce BEFORE it travels to the recipient's mailbox.

ICMan

---

From: Richard Shockey <[email-masked]>
Date: Fri, 17 Dec 1999 16:09:46 -0600

>the mailbox of the recipient?

This is one of the tasks of the RESCAP WG now officially chartered.

>Or perhaps a hold and verify, so the

I'm also beginning some work in the IETF called QUALDOCS which may have 
some bearing on these ideas. IESG has just informed me that they view the 
charter in a positive light with some revisions and a initial focus on a 
Goals and Requirements charter vs protocol development.

Proposed Charter:

QUALDOCS - HIGH QUALITY DOCUMENT DISTRIBUTION

Chair(s):   Richard Shockey
         <[email-masked]>  [PROPOSED]

Applications Area Director(s):
         Keith Moore     <[email-masked]>
         Patrik Faltstrom   <[email-masked]>

  Area Advisor
         Keith Moore  <[email-masked]>

  Mailing lists:
      General Discussion:        [email-masked]

To Subscribe:

[email-masked]

In Body: subscribe ifx  [your-email-address]

         The subject line should be blank

Archive:

<http://www.pwg.org/hypermail/ifx>

Description of Working Group:

The transmission and reception of final form documents (i.e. presented in a 
format that describes their final rendering) is an essential global 
communications service.

Several protocols and services have been developed over the years to 
facilitate document transmission, including the GSTN Fax service [ITU 
-T.30].  Within the IETF several protocols have been developed that 
facilitate document transmission, including RFC 2305 and RFC 2532 [Store 
and Forward Internet Fax] and the Internet Print Protocol [IPP].

Problem Statement:

Each of these services has one or more severe limitations or restrictions 
that may not be suitable for all document transmissions.

Among those limitations that could be applied to one or more of the above 
services:

1. Limitations on Quality (resolution or color transmission)
2. Ability to repudiate request for receipt confirmation (MDN - DSN)
3. Lack of clear and unambiguous legal identification of sender and recipient
4. Lack of ability to adequately determine the success or failure of a 
document transmission during processing
5. Inability to establish reliable knowledge or negotiation of recipient 
capabilities
6. Inability to satisfy legal as well as general custom and practice for 
document transmission technologies, as typically applied to GSTN Fax.
7. Inability to establish transaction security, authenticity and 
confidentiality of document transmission

Work Group Objectives:

The purpose of the work group will be to investigate current work within 
the IETF and identify protocols, procedures and policies that can satisfy 
the requirements for reliable document transmission with a high degree of 
fidelity and reliability.

Essential attributes for Quality Document Delivery Services include:

Timely Delivery.
Transaction Security, Authenticity and Confidentiality.
High quality output with sender control of presentation detail
Legal identity exchange.
Document format selection based on confirmed capabilities of sender and/or 
receiver.
Proof of Delivery (Receipt Notification).

Study will be given to the requirements of 3rd party document delivery 
service providers.

The WG will not submit any new protocols only extensions or augmentations 
to existing or proposed Standards Track protocols.

Proposed solutions:

Proposed solutions should not impose undue burdens on implementers in order 
that the protocol should be available on a wide variety of devices and systems.

The working group will closely coordinate its activities with other IETF 
Work Groups, including the Internet Print Protocol working group [IPP] and 
the Internet Fax working group [FAX] as well other document transmission 
related standards bodies and related work groups, notably the ITU-T Study 
Group 8. The group will take note of other areas and Work Groups within the 
IETF that may have direct bearing on reliable document delivery.

Relevant areas include:

-  Security, Authentication and Encryption (TLS, etc)
-  Sender Identification (vCard)
-  RFC 2301 File Formats
-  Digital Signatures and Certificates
-  RESCAP
-  IMPP
-  ENUM

Particular emphasis will be taken to design protocol elements that would 
likely reduce the possibility of document "spaming" as well as other forms 
of denial and abuse of service.

Goals and Milestones:

April 2000  Submit Internet Draft of Goals and Objectives for Quality 
Document Distribution  for publication as a Standards Track RFC.

June 2000 Submit Internet Draft for QUALDOCS service for publication as a 
Standards Track RFC ( Based on Selected Protocols)

August 2000 Submit Internet Draft of Requirements for QUALDOCS Service 
Interworking for publication as a Informational RFC

October 2000 Close QUALDOCS 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: Fri, 17 Dec 1999 16:09:46 -0600

Proposed Charter:

  Area Advisor

  Mailing lists:

To Subscribe:

[email-masked]

Archive:

Problem Statement:

Work Group Objectives:

Timely Delivery.

Proposed solutions:

Relevant areas include:

Goals and Milestones:

Richard Shockey
Shockey Consulting LLC

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Dec 1999 15:20:33 -0700 (MST)

> From: "Mason, Shane" <[email-masked]>

> physical site.  It will stay at your site until your SMTP timeout kicks in.

What is a "physical site"?  Does it mean a host or IP address named in the
SMTP envelope that differs from the host of the SMTP server, but that is
not currently reachable by the SMTP server?

How does that mitigate the problems inherent in giant SMTP messages?  Who
is running systems that has SMTP spool space for a few 100,000 messages,
each several dozen MByte, each waiting for some next hop to awaken?

> accept mail to any destination, and your site is RFC compliant.

Which RFC ever said such nonsense?  I thought it has always been legal to
bounce any and all email based on whatever capricious criteria the SMTP
server feels like imposing.  That is the basis for one of the 3 major spam
rejection mechanisms.

> delivery or immediate bounce BEFORE it travels to the recipient's mailbox.

Note that for good technical reasons, an SMTP (or ESMTP) bounce
does not involve the server merely sending a TCP FIN or a TCP ACK.
Please see RFC 821.

Note also that at least one common SMTP implementation, sendmail, does
not copy directly from the wire into the recipient's mailbox under any
circumstances, for what I think are compelling reasons.

Note also that "notifying a recipient" can be a pretty complicated idea
that could involve waits of days or longer, during which many of us would
prefer not to preserve TCP connections and SMTP client and server state.
(I'm just guessing about what "recipient" is intended to mean, since it
clearly cannot be the notion used in RFC 821 or RFC 822.  My guess is that
it means something about the final SMTP server.)

See also RFC 1870.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Dec 1999 15:20:33 -0700 (MST)

See also RFC 1870.

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 18 Dec 1999 10:28:39 -0700 (MST)

> From: Kent Crispin <[email-masked]>

> >          http://www.patents.ibm.com/patlist?icnt=US&patent_number=5790790
>
> You would be hard pressed to come up with a more absurd patent...

Computer-based methods for determining the head of a linked list
http://patent.womplex.ibm.com/details?&pn=US05446889__

and I bet there are many, even better examples.

---

From: Scott Bradner <[email-masked]>
Date: Sat, 18 Dec 1999 14:03:56 -0500 (EST)

>To revisit a theme I raised back in the summer, this need to be able to
>prove prior art is the reason I believe we need to preserve Internet
>Drafts, 

the IESG has asked the IETF Secretariat to do this and the old IDs
should be on-line soon

Scott