Re: [Evolution] SpamAssassin with Evolution

[Not Zed <notzed ximian com>]

On Mon, 2003-03-10 at 20:08, David Woodhouse wrote:
> On Sun, 2003-03-09 at 19:55, Peter Williams wrote:
> > Evolution is technically doing the correct thing here. 
>
> I disagree but wouldn't bother to argue with that in the context of
> normal display of email. But in the 'Show Email Source' view it's
> somewhat misleading. That should show the email unmunged, surely?
>
> > RFC822 specifies that the leading whitespace in a multiline email
> > header should be considered equivalent to a single space.
>
> RFC822 says, in §3.1.1, ...
>
>       Unfolding is accomplished by regarding CRLF immediately
>       followed by a LWSP-char as equivalent to the LWSP-char.
>
> More relevant is RFC2822, which more clearly states (in §2.3.3):
>
>       Unfolding is accomplished by simply removing any CRLF
>       that is immediately followed by WSP.
>
> The above two methods are identical, although the latter is more clearly
> stated IMHO. You may remove the CRLF but you may not convert multiple
> whitespace characters to a single one, or convert tabs to spaces, etc.
>
> What RFC2822 _does_ say, in §3.2.3, is that runs of comment or
> whitespace 'that occur between lexical tokens in a structured field
> header are _semantically_ interpreted as a single space character'.
>
> That is _not_ a reason to _display_ them like that, especially in the
> 'raw' message view mode. Would you advocate eliding comments too?

Because of a change someone made to the parser about 2 years ago, this
IS the "raw" message as far as evolution is concerned.  Evolution has
already 'munged' the message headers by the time it reads it in the
first time, and the information is lost.

I wanted this not to happen, but when the code got changed i couldn't be
bothered fighting the change to re-fix it, because it is a relatively
sensitive bit of code.  The problem goes a bit deeper with text/* parts,
so a fairly major redesign is required to fix both problems.

> >  The mailer collapses the spaces in its internal representation of
> > emails. In this case it happens to mess up the formatting, but they're
> > really relying on behavior that's not guaranteed.
>
> It's not clear to me that RFC2822 permits this deviation from standard
> practice. 

It doesn't explictly disallow it, that i can recall anyway.

Folding loses no semantic information.

> Note that it's not just cosmetic -- when adding X-Evolution headers to
> _every_ mail in a multi-gigabyte archive on startup (presumably just to
> say 'no interesting status change from default' in _all_ of them), Evo
> ate all the whitespace in all the headers while it was at it too. I had
> to restore from backup. 

Use maildir or imap ...