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
agent.
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.
Al
