Re: Full Headers?

[<balsa microwave com>]

On Tue, 10 Jul 2001, Brian Stafford wrote:

> On Tue, 10 July 16:48 balsa@microwave.com wrote:
> >
> > Ok, I cede the point.
> >
> > Regardless, it really doesnt matter in the context I was using, since the
> > resrictions on format would all be imposed on the creator of the message.
> >
> > The feature I was talking about was to just display the full unmodified
> > source as it is received, regardless of which standard it was created for.
> > I wasnt talking about the specific syntaxes of the headers, I was simply
> > referring to the concept of having the message displayed, with all the
> > headers first, the blank seperator line, and then the body as transmitted
> > by the underlying structure, WITHOUT any decoding having been applied..
>
> I was making the point about the correct standard rather than commenting
> on the message presentation in the UA.
>
> My own opinion:
>
> Given that RFC 2821 (and 821) only permit an MTA to add Received: and
> Return-Path: headers to the *start* of a message (albiet with some latitude
> for changing content transfer encoding in MIME documents).
>
> a) an MUA should be liberal in what it accepts as messages and should make
>    a reasonable attempt at presentation.
>
> b) since trace headers are useful, an MUA should show headers in the
>    order they are present in the message when viewing all headers.
>    The ordering of Received: and Resent-*: headers is important.
>    When viewing minimal or selected headers, the presentation can be
>    beautified somewhat.
>
> c) since some MTAs are fond of mutilating messages (Exchange, sendmail ...)
>    it should be possible to view the message exactly as received with
>    no attempt at formatting whatsoever.
>
> Balsa seems to do a) reasonably.  b) when viewing full headers they seem
> to be sorted or rearranged somehow.  c) is missing.  I always found
> Netscape's "View Message Source" option useful.  Since we use exchange at
> work, I get a lot of mutilated mail!


Exactly.. I normally use pine, which does b) fully, and has a sufficiently
complete c) (It does some parsing on multipart messages and MIME coding
before showing it to you.... Its not a signfigcant disadvantage unless you
are troubleshooting MIME related stuff)

It would be very nice if c) was added to balsa.

It is also VERY useful, from a spam/abuse reporting standpoint, of being
able to forward c) in-line as part of a new message (without having to
cut&paste or save to a file first.. - eg, from the "display full message
source function', beingable to hit 'forward', and have that source be what
is forwarded...