[Top] [All Lists]

Re: problems with messages over 50000 bytes

1992-06-24 15:53:08
** Sorry... the body of this seems to have gotten lost the last time **

Ann and Jon,
  I read your note, and some of the responses, with considerable
interest.  I disagree with some of the analyses that have
appeared; a few of them probably predict to future problems with
email systems.   Is is important to note two things before
  (1) Host Requirements imposes a minimum message size
limit for rejection of 64Kb (RFC1123 section 5.3.8, for those to
whom this comes as a surprise).  That is above the limit set by
some of these systems, but still significantly too short to
accomodate the Monthly Report.  However, some of the rejections
are coming from mail gateways or systems on the far side of mail
gateways and it is not clear that we make make HR, or any other
set of minimum capacity requirements, apply to such systems
without shooting ourselves in the proverbial feet.
  (2) There are at least two different types of causes of
rejections scattered among the various bounce messages you
  One of these might be thought of as a "transport limitation":
if you broke up the message into sufficiently little pieces and
mailed them out separately for later reassembly, there would be
no problem. 
  The other is a "delivery problem" or "mailbox problem":
Messages of that size cannot be stored for the user (the total
mailbox must be under some limit), or the user can't reassemble
them even if they arrive in pieces (users don't get that much
disk quota), or the site has to treat sending very large
messages (in one piece or several) as a (possibly unintentional)
denial-of-service attack.

A few mail service vendors have a firm policy that nothing that
happens from the outside should force a subscriber to incur
excessive marginal prices.  That isn't necessarily a bad policy:
a confiscation-of-dollars attack isn't much more attractive than
a denial-of-service one.  While I can't defend several of their
other policies, CompuServe has rejected suggestions that they
respond to large messages by "growing" the mailbox and charging
the user with this type of reasoning: it would permit someone
outside to attack a user simply by sending a few very large
messages.  Note that fragmenting messages and sending pieces
doesn't solve this problem, which is (at least partially) why
they have maximum-number-of-messages and maximum-mailbox-
capacity limits as well as per-message ones.

In the situations where these kinds of limits ultimately derive
from policy decisions, not technical restrictions, sending
through a 130Kb message in four or five pieces constitutes an
attempt to beat the system.  The response, if the problem is
perceived as severe enough, might be revision of the receiving
mail system to reject MIME-fragmented messages as a hostile
attack.  For those cases, at least, fragmenting the messages is
not a useful activity.

The other MIME facility -- use of Message/External-body -- holds
more promise, I think, but may be inappropriate overkill, at
least given that the systems that impose size limits are not
terribly likely to have MIME implementations at this time.  In
the trivial case, this is nothing more than an elaborate
mechanism for handling a "the monthly report is available, FTP
it from..." announcement.

I think where this is pointing is that you may be asking the
wrong question.  The right question might be closer to "given
that we have a monthly report that is circa 130Kb and growing,
what is the best model for distributing it"?  I suggest that
distributing it by mailing to the entire IETF list is not a good
answer to that question, and the bounce messages you are
receiving are a symptom of that, rather than a problem in and of
  Moving toward an announcement strategy, paralleling that for
internet-drafts and RFCs, with depositories and mail-based
servers, would seem to me to be a much better option.  If we
could have one or more of the mail-based servers prepared to
deliver the Monthly Report in parts (ideally using MIME
fragmentation), that would be a significant improvement for
those sites with transport limitations but no delivery or
mailbox limitations on size.  
  Finally, at the risk of heresy, I have significant doubts
about any regular publication that is that large.  How large a
fraction of the people on the existing IETF list do you think
actually receive this thing every month and reach every one of
the 130 Kbytes that make it up?