Re: [exim-dev] Changing received_header_text default?

On Mon, 2006-03-13 at 16:14 +0100, Michael Haardt wrote:
> You are right, RFC 2822 does not tell how clients should behave,
> meaning it simply does not answer the question.
>
> So, how should clients behave? :-)

My answer would be that they should preserve as much information in its
original form as possible. Make no changes which aren't necessary.

> Everybody agreed that line breaks in headers do not carry any semantic
> content, because agents may re-fold unstructured headers to their taste,
> and in fact do. You can not rely on line breaks to be preserved where
> they are.

It's email. Of _course_ you can't rely on any of it to be preserved,
even if it gets through at all. Just as you can't _rely_ on PGP
signatures to make it through intact, because weird stuff might happen
-- especially if interim mailers violate the principle of minimal
munging and decide to mess around with 'syntactically equivalent'
changes for no good reason.

Nevertheless, you can optimise for the sane case, and lay out your
headers (and indeed the rest of your mail) so that they're easy to read
in a mail client which doesn't screw with them.

> Does displaying semantically useless information make sense? That's the
> point where no consensus could be reached in the past. Perhaps that's
> why RFC 2822 does not even mention the topic.

To pick a specific example of 'semantically useless information', let's
look again at http://david.woodhou.se/evo-ate-my-spam-report.jpeg

My answer to your question would be a resounding 'yes'. It _does_ make
sense to display it as it was sent. There was often a _reason_ it was
sent the way it was. Even RFC2822 hints at this (§2.2.3 again):

Note: Though structured field bodies are defined in such a way that
folding can take place between many of the lexical tokens (and even
within some of the lexical tokens), folding SHOULD be limited to
placing the CRLF at higher-level syntactic breaks. For instance, if
a field body is defined as comma-separated values, it is recommended
that folding occur after the comma separating the structured items in
preference to other places where the field could be folded, even if
it is allowed elsewhere.

Think about it... why would it suggest that you wrap at 'higher-level
syntactic breaks' if it's expected that the receiving MUA is going to
disregard the line breaks anyway?

Let's ask the converse question -- why would it make sense to tamper
with it?

I can see the justification for fixing up MIME headers which are
actually broken, in an attempt to deal with the mail as its sender
_presumably_ intended it to be received. But to mangle whitespace for no
better reason than 'because we think we can' would be bizarre.

--
dwmw2