One more observation on this "large message" problem, for the people
whose solution is to say "your problem" or "their problem".
Let's look at who really has a problem here.
There are three separate issues, I think:
(1) The IETF mailing list is trying to send a moderately large message
to a user on CompuServe. CompuServe will not accept that message,
rejecting it at 50Kb. With a threshold at 50Kb, rather than 64Kb, they
are out of compliance with HR. Too bad; that isn't the only reason they
are out of compliance with HR. They handle the error situation in a
reasonable way. Who has a problem?
-- well, the user may have a problem, if he or she is concerned about
getting the monthly report. Maybe he or she isn't. If the report is
critical, then, as has been pointed out, CompuServe may not be the right
service. Their policy is pretty clear. Unless the erosion of users
becomes serious, this is not a CompuServe problem--they chose a policy
and just need to live with it. And it is certainly not an internet
problem.
-- The IETF mailing list may have a problem, in that it has to send
the 51st kilobyte in order to determine that CompuServe isn't going to
accept > 50Kb messages. If that is a problem, then SMTP is broken, or
at least inappropriate for transmission of large messages.
(2) CompuServe said "why don't you break this into pieces"? Reasonable
request, can't hurt to ask. But it is not, in and of itself, a problem.
the IETF list can either agree or not agree.
I suggest, Sam, that you don't, in fact, want to ask for that until
and unless you manage to do some overhauling of your per-user-mailbox
error handling. Otherwise, these biggies, arriving in fragments, are
going to cause a lot of "no more space" messages, and we know those are
not handled very well. So, if this suggestion were accepted, CompuServe
would have a problem. If it were not accepted, they may not be able to
offer a slightly marginal service to their users. As problems go,
probably not a big deal.
If it were partitioned, the monthly report arrives for all the rest
of us in fragments and possibly not in order. That is, at best, a
nusiance and, at worst a problem.
Now, one could, of course, maintain two ietf mailing lists: the "big
mail" list, and the "small mail" list, with the latter getting little
chunks. I suggest that option is a problem, if for no other reason than
a perception that Jon and Ann have a large collection of other things to
do with their time.
Stef says...
A basic premise of communications theory is that if you want to
communicate something to someone, you should make it possible for the
target recipient to receive and understand what you are trying to
communicate.
Yes, but maybe "we" don't care. Maybe it is the responsibility of
anyone who needs this information to receive it in a way in which it can
be received. Maybe they should look for someone (or some automated
agent) on the Internet who receives these things and can break them up
into pieces before forwarding, possibly for a fee.
If you do not wish to communicate with the target recipient, then it is
easiest to just not bother to send anything. It is pretty silly to send
stuff that will not be received.
But, as often happens with Stef and me, I had exactly this thought and
concluded not "make into two messages" but "maybe mailing this sort of
thing is the wrong model". His argument about relative efforts clearly
applies to either approach.
So, in my view, the burden of breaking the messages up into smaller
sized bundles is properly laid upon whoever wants the information to be
received.
Seems to me that is CompuServe's customer, who, if this information is
wanted, should be looking into appropriate arrangements, whatever they
might be.
Things would be different if Jon had come on the list and said "hey,
it went over 50Kb and a major chunk of the on-internet sites started to
reject". Then we would have discovered that the 64Kb limit in HR does
not reflect current implementation reality (or, as asserted, the "de
facto mimimum"), and, probably, that things should be repackaged until
there was a much higher level of conformance. As Bob Braden put it,
"both".
But as long as it is a few users, on the far side of gateways, then
the answer ought to be "their problem" (and I think I mean the user's,
not CompuServe's, unless the latter makes a policy change) rather than
motivation for inconveniencing the Internet users.
I'm also feeling the desire to pick a nit here. Let's assume that we
have an enforcement model, and we can, e.g., paint anyone green who does
not conform to a MUST in HR. Does CompuServe get painted green for
imposing a 50Kb limit, rather than 64Kb? I suggest that they do not!
Now, if I impose a 50Kb limit, you get to paint *me* green, but how
about CompuServe? In the mail area, HR, like 821 and 822 before it,
carefully avoided specifying the behavior of other systems and networks
that sit on the far side of gateways off the Internet. CompuServe isn't
an "internet host" or collection thereof by any reasonable definition.
So, suppose we send them a 65Kb message, and they "accept" every
single byte of it, and send back a 250 (?) code after they get the
CRLF.CRLF. The "internet side" of the gateway is now conforming, they
have "received" a 65Kb message. Now they mail the thing back to you in
a message that says, very politely, "the CompuServe network side of this
gateway refuses to process messages over 50Kb". We can't impose a
requirement on their message sizes or formats, as long as they behave
properly wrt anything they put onto, or get from, the Internet. I
suggest that this is proper behavior, if not wonderful, and we can keep
the green paint.
And, as Stef says, "it is pretty silly to send stuff that will not be
received".
--john