You also seem to assume that putting things into the main message
headers hides them somehow.
Actually, I'm not assuming that at all. My point is that the data
which is being arbitrarily forced into the body is data which actually
describes the true body, that is, it is data which belongs in the
header along with all of the other similar data.
Perhaps this was the point you intended to make, but it most certainly wasn't
what you said. What you did was complain, in at least three different messages,
about stuff at the beginning of messages being annoying to users. You even went
so far as to cite completely irrelevant examples of how Andrew didn't do this
properly.
I responded to what you said, not what you now claim you meant to say. Of
course you also went on to discuss some of the philosophical issues in another
place, which I then countered by showing that your approach is nowhere near as
philosophically consistent with current email practices as you claimed.
Encapsulation should
actually accomplish something. Otherwise, we should do away with
headers altogether and put *everything* in the encapsulation.
So what? Encapsulation *does* accomplish something in this case. You have now
effectively argued yourself around to a position that appears to support
security multiparts.
On the contrary, the point reflects substantial real-world
experience and is not circular at all. Removal of unrecognized
header lines, especially nonstandard X- headers, is actually quite
common. It has taken a lot of widespread community effort to get
MIME's own headers into the "standard" set for most of these
systems.
It still seems that you are arguing that standards should be dictating
by the systems which actively reject standards. IMO the message to
such systems should be, as Jamie Zawinski is fond of saying, `evolve
or die'.
Not at all. All I'm saying, and all I have ever said, in this or any other
discussion of MIME issues, is that a balance has to be struck between existing
infrastructure and new facilities. You ignore existing infrastructure at your
peril. MIME goes to considerable lengths to try to be compatible with both
pre-MIME infrastructure as well as new infrastructures we're building now,
(e.g. transport neutrality), and I happen to be believe that MIME widespread
success is largely due to the attention we paid to this.
The position which you are espousing seems more like `Standards should
bend over backwards to support systems which actively reject
standards'. If such systems choose anti-social behavior -- which of
course they are free to do -- they will be unable to interact with
society as well as others.
You are making a big assumption here that is in fact incorrect -- that these
systems that cause problems with schemes like yours are in fact "rejecting
standards". The fact of the matter is that they are doing nothing of the sort.
In particular, there is nothing in any standard specification I'm aware of that
says that user agents and agents that operate with user agent authority (and
list processors fall into this class) have to preserve and present all headers
unconditionally. As such, these systems are in fact conforming to the standards
that do exist, even when they remove MIME headers.
We've been down this path many times. When you try to club people over the head
with standards documents you'd better be very clear on what they actually say.
I know of no way to look more foolish than to run around badmouthing some piece
of software for being incompliant with the standards, only to find that it is
nothing of the sort.
You can argue many things based on what the standards say, but this isn't one
of them. Now, this doesn't mean that things don't or should not evolve as needs
change. They do and should. But this particular matter is NOT a standards issue.
I don't think that its at all unreasonable to suggest that systems
should not arbitrarily strip headers on incoming messages. If a
header was attached to a message, there was probably some reason for
it. These systems are choosing to arbitrarily damage a message.
It all depends on the circumstances. There are many circumstances where it
is reasonable. And there are also circumstances where it is not.
Consider the case of a gateway to a PC LAN mail system -- an incredibly common
case. Very few of these systems have any sort of header extension facilities.
As such, the only way you can carry around additional headers is in the message
body, typically as a text attachment. However, doing this is incredibly
inconvenient for end users, and thus may or may not even be an option. (When
the president of the company tells the network manager to get rid of the
headers in all messages, it boils down to a choice between the headers and the
network manager's continued employment. Guess what way the decision always
goes. In fact I've seen this exact scenario play out more than once in
companies I've dealt with.)
Now, you may say that the PC LAN mail system should evolve or be replaced. A
nice sentiment, to be sure, but one that is unlikely to happen any time soon.
The reality is that such systems are being installed everywhere, with a rate of
growth that, according to the analysts, exceeds the rate of growth of the
Internet itself right now.
So much for sweet reason.
Allowing a user to select which headers she does or does not want to
have displayed is a different matter altogether. I choose not to
display various headers, but occasionally have reason to go past my
user-interface filter to see the full set of headers.
I'm glad you have such flexibility in the software you use, as well as the
technical skill to use it. However, most of the users of the software I
develop and sell have neither the flexibility in the interfaces they use nor
the technical skill to use such flexibility even if were available.
Ned