ietf-822
[Top] [All Lists]

Re: large messages

1991-08-17 07:11:46
We've run into a problem in distributing the Internet Monthly Report.
It seems that some of the people recently added to the distribution 
list (primarily by being on the ietf list) are behind mail relays or 
have mail systems that do not handle large messages.

This is a problem for these people, and they in turn ask us to break the
large message into pieces and send the pieces as separate messages.  This
is more work for us.  Should we do it, or should we ask that these mail
systems be fixed?

Jon,
  Let me suggest looking at this question in another way.  The monthly 
report has risen over 50Kb.  That causes CompuServe (and some others) 
problems at the gateway.  It could cause almost any "smaller" host 
problems with just disk capacity/quota overflow if a few of these things 
arrived, destined for the same mailbox, in a short period of time 
("short" is defined by how frequently users clean out mailboxes).

  At the same time, HR suggests rejecting at 64Kb is the smallest 
acceptable number, so there is justification for saying "just fix your
gateways, guys".  But, given what I perceive of as the rate of
size-expansion of the Monthly Report, how long is it going to be before
is complaining about 65Kb where, presumably, we can't say "fix your
server"? 

  The problem in this case, as I see it, isn't the size or the gateway 
code, it is the decision to send this to the IETF list.  Many of us feel 
that we need to be subscribed to that list for various important 
information.  The monthly report is quite interesting and useful, but 
might be marginal to some, especially those who can't get it anyway 
because their gateways do something unpleasant after using up lots of 
bandwidth.  Consider instead a model of, e.g.,
  -- putting copies of the file in the usual places for FTP.
  -- sending an announcement to the IETF list indicating that a new 
monthly report is available.  Ideally, use the same mechanisms used for 
internet drafts and RFCs, s.t. the announcement contains "how to obtain" 
information.
  -- ideally, find a convenient LISTSERV-running BITNET or EARN site 
which can store the things too, for those for whom that method of 
obtaining files is more reliable or convenient than FTP.  If that can be 
coupled to LISTSERV's "AFD" (automatic subscription to changed files) 
service, so much the better for those who want that.
  -- provide some mechanism, whether a mail-type server such as 
server(_at_)nic(_dot_)ddn(_dot_)mil or a short 
subscribe-only-if-you-can't-possibly-
get-this-some-other-way mailing list, for people who can't get it by 
direct or indirect FTP to collect it.
   These get-file-by-mail options could rationally store and deliver the 
file in several pieces without imposing the burden of manual reassembly 
on uses of conforming hosts.  And probably some of the CompuServe-like 
subscribers would decide that they did not need to see the monthly 
report at all, which is ok too.
   These alternatives would, of course, also reduce the demands on the 
mailing mechanisms for the IETF list.  I gather from the RFC you and Ann 
put out that this would be a small additional benefit :-).

While my system has no problems accepting 50Kb (or 64Kb for that 
matter), they still tend to choke up my UA and my cognitive ability to 
cope (for me, a big problem :-) ).  So, independent of technical issues, 
I'd rather get that file when I'm ready to deal with it.  I might even 
want to obtain and read it on a machine other than where I normally want 
to read my mail, or something.  I don't believe that reaction is 
completely atypical.  So I'd suggest that, when possible, we look for 
alternatives to wholesale mailings of very large files, especially to 
mailing lists that have related, but not identical, purposes.  And I 
think we should view that as a courtesy and human efficiency issue, not 
a protocol one.

Since I've gone on this long, three additional comments:

(1) As Sam and Karl and I have discussed many times offline, the
CompuServe gateway has many problems.  Indeed, the list is probably
longer for it than for the much-maligned BITNET gateways.  The technical
problems are complicated by, as I understand it, one of those "two
hosts, funny protocol over a wire" gateway arrangements similar to the
original MITVMA <-> MIT-Multics hookup that did Internet and MAILNET <->
BITNET service and, if I recall, the original UUCP <-> Internet or UUCP
<-> BITNET gateways at Berkeley.   Those things are much more difficult 
to get right--to get all the right information moving back and forth--
than a gateway in which one host speaks both protocols.  That is not an 
excuse for them not doing it right, it is an argument for a little 
patience and sympathy.  But there are also philosophical problems: 
several suggestions that Sam and I have discussed for alleviating their 
"two big" and "too many" problems would, if implemented, run squarely 
against a CompuServe policy of never letting something one user (or an 
outside mail system) does force another user to incur extra charges.  
That is probably a reasonable policy, but it does make things a little 
more complicated.
  In any event, if they are going to start fixing things to make us 
happy, absolute size ought to be pretty low on the list, behind a whole 
lot of things like correct error handling (someday, an error-bounce loop 
is going to start from there, and we will all be *real* unhappy).  There 
is also an interaction: if we get them to raise the "too big" bouncing 
threshold, we presumably start seeing significantly more of the "user 
has no more space for messages" error behavior.  We wouldn't like
that--they tend to be bounced to the list, rather than the return path
:-(. 

(2) The "right" way to handle a high-volume list in the CompuServe 
environment is to pipe it into a forum and get the individual 
subscribers off the list.  To my knowledge, that has not been done with 
any of the Internet lists, presumably due to economic factors and lack 
of motivation (maybe the same thing).  I note that Sam's note indicates 
that the 50Kb limit is ultimately an administrative decision: 
other-than-ordinary users can receive long messages.  Again, I think we
would solve more problems by encouraging them to support that sort of
facility than by insisting on an extra 14Kb of mail capacity.  Or of
making the rest of us put up with reassembly to compensate for their
limitations. 

(3) We kicked it around in HR and decided we couldn't do anything 
because it was an extension rather than a clarification, and it has come 
up once or twice in the IETF-SMTP discussions, but there is a strong 
case to be made for an optional SMTP verb, or command-variation that 
would specify a size-approximation.  We could then recommend its use for 
mail files of larger than moderate size, and insist (at least at the
SHOULD level) on its use for files larger than, e.g., the 64Kb 
threshold.  It wouldn't get any more of this mail through, but there 
would be a lot less load on clients, servers, and the network if a 
client could pre-announce a size and the server could respond with 
  5xx No way I can handle anything that big
or, if appropriate, by scurrying around and finding some extra space and 
buffers before 
  2xx Sure thing, 10Mb mail files are not problem around here.
     As I've said to several people in private conversations, I predict 
that one of the outcomes of the multipart/multimedia mail work will be a 
significant shift to the right of the distribution of message sizes.  
Pictures, especially moving pictures, and music tend to do that.  And I 
think that argues that we need to think more broadly about these issues 
than in terms of getting a gateway to handle an extra 16Kb.  Whether 
that should be in terms of SIZE verbs, or in terms of facilities for 
automatic partitioning and reassembly of multiple-mail-unit messages, or 
both, ought to be part of other discussions.

If the discussion above it the right one (not the right answers, but the 
right questions), can we move it to ietf-smtp (where there is hope of
doing something), rather than the three-way cross-post? 

    --john

<Prev in Thread] Current Thread [Next in Thread>