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
