Re: [Evolution] SpamAssassin with Evolution
- From: Not Zed <notzed ximian com>
- To: David Woodhouse <dwmw2 infradead org>
- Cc: Peter Williams <peterw ximian com>, evolution lists ximian com
- Subject: Re: [Evolution] SpamAssassin with Evolution
- Date: 11 Mar 2003 12:00:41 +1030
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
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 ...
] [Thread Prev