to follow up on what Earl Hood said:
On November 13, 1998 at 14:39, Al Gilman wrote:
You are messing with their messages but it is their messages. If
I believe Chris only modified (would modify) the message data with
respect to MHonArc archiving. I.e. The actual message sent to list
subscribers is left untouched. This way, subscribers will receive
the message as sent by the sender into their own private mailboxes
and only mhonarc receives the modified data.
And what is done with the modified data? Is it publicly served
by HTTP? The originator of the message has just as much interest
in the integrity with which it is delivered by HTTP as by SMTP.
they really want the images inline in the archive, there are two
ways to get their. They all learn to use their mailers in
squeaky-clean MIME fashion or you bash attachments to INLINE for
purposes of the archive. So long as the list membership are
advised and you don't get an outcry there, you should not be too
fastidious in the handling of headers that after all are but an
encoding of what the mail client thought the users's wishes were.
In a small group like a mailing list you can appeal in natural
language to the users themselves and work accordingly.
I believe the wishes of the list subscribers is to see images
inline when accessing the Web archive.
There is not need to go on blind faith on this point. I believe
that, too, because I believe Chris is already prone to listen to
the subscribers. There is just a small measure of safety in
being explicit about this with the authors represented in the
website that MHonArc generates out of the list traffic.
I see nothing wrong in providing options in MHonArc to override
content-disposition if the user of MHonArc so desires. C-D is what
the sender has stated about the data, but the receipient is free to
honor, or not honor (especially wrt filename specification), the C-D.
MHonArc provides this flexibility wrt to filenames, but currently
not with attachment/inline specifications.
Well, yes. Since I argued vehemently that the end consumer
should have the last call both in the multipart-related
discussions on the mime-types list and as regards the control of
style rules in HTML/CSS scenarios, it would be utterly
inconsistent for me to argue that these headers are not amenable
subjects for override. In fact, that is not anything like what I
said earlier to Chris. I said "Yes, do it, but cover your bases
with the community."
The MHonArc operator is usually not an end-user, and is not in
this case. The MHonArc user is operating a gateway from SMTP
delivery to HTTP delivery, and needs to consider him/herself more
of a trustee for the originators of the messages than as a free
Yes, the options should be there; but they should be exercised in
a way consistent with the netiquette consensus of the group
served, not arbitrarily by the individual maintaining the
archive. That's all.