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