![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.