GNOME.org
 

Re: [Evolution] does evolution respect standards of web ?

Le vendredi 30 novembre 2007 à 10:41 +0100, Matej Cepl a écrit :

On Thu, 29 Nov 2007 14:16:47 +0100, Xavier Bestel scripst:

This is a veeeeery loong-standing problem. I already reported it years
ago, but never had any good answer.


Could you provide the bug number of this report, please?


Sorry, I don't remember if I did that.

Here are the mails we exchanged about the subject:
--- Begin Message --- 
On Wed, 2004-06-16 at 21:21 +0800, Not Zed wrote:

Still, i'm extremely loathe to, since it is a clear breakage of a
pretty simple set of rules from a not-particularly complex rfc.
Seriously, MS should know better, for such a fundamental issue.  We've
had issues with rfc compliance in that code and fixed it, i'm sure
they can too.


Whatever happened to "be strict in what you send and flexible in what
you accept"? (I'm paraphrasing, but that was once the golden rule of the
Internet).

In the end this is a judgment call, but I suspect that those of us who
mostly use Evo in languages other than English probably give more weight
to this kind of issue than whether the Contacts widget can remember
birthdays (to pick a random example).

poc

--- End Message ---
--- Begin Message --- 
On Wed, 2004-06-16 at 11:24 -0400, Jeffrey Stedfast wrote:

On Wed, 2004-06-16 at 10:35 -0400, Patrick O'Callaghan wrote:

On Wed, 2004-06-16 at 21:21 +0800, Not Zed wrote:

Still, i'm extremely loathe to, since it is a clear breakage of a
pretty simple set of rules from a not-particularly complex rfc.
Seriously, MS should know better, for such a fundamental issue.  We've
had issues with rfc compliance in that code and fixed it, i'm sure
they can too.


Whatever happened to "be strict in what you send and flexible in what
you accept"? (I'm paraphrasing, but that was once the golden rule of the
Internet).


whatever happened to reading the spec?

seriously tho, rfc2047 is pretty clear about how to deal with broken
encoded-words. simply don't decode them... and this is what Evolution
follows.


Which would be a wonderful argument if Evolution was an RFC conformance
test suite. But it's not. It's an email client, and as such, it should
be focusing on helping people read their mail.

-- Dan

--- End Message ---
--- Begin Message --- On Wed, 2004-06-16 at 09:13 +0200, Xavier Bestel wrote: 
Hi,

I often receive mails with non-ascii titles, and sometimes Evo doesn't
display them right. For example, this subject (in the mail source):

Subject:
        =?iso-8859-1?q?www.amen.fr_-_Actualit=E9_Technique_:_Surcharge_des_serveurs_de_messagerie_=
        /_Disponibilit=E9_du_service?=

displays in the mail view as:

                           Subject: 
=?iso-8859-1?q?www.amen.fr_-_Actualit=E9_Technique_:_Surcharge_des_serveurs_de_messagerie_= /_Disponibilit=E9_du_service?=


For some reason, it seems the subject isn't decoded. Can anyone spot if
there's a problem with the syntax, or if it's an Evo bug ? (in which
case I'll do a proper bugreport).
The syntax is wrong.  It looks like the mailer that sent it tried to do content quoted-printable line wrapping, which is totally incorrect in this context!

The string can't contain any spaces, including linear white space.  The whole token is supposed to be less than 76 characters  for this purpose, so that any folding (wrapping on multiple lines) is outside the token boundaries.

>From rfc2047, the relevent rfc, it is pretty clear and quite explicit about how the headers should be interpreted.  Subject is a text field.

6.1. Recognition of 'encoded-word's in message headers

   A mail reader must parse the message and body part headers according
   to the rules in RFC 822 to correctly recognize 'encoded-word's.

   'encoded-word's are to be recognized as follows:

   (1) Any message or body part header field defined as '*text', or any
       user-defined header field, should be parsed as follows: Beginning
       at the start of the field-body and immediately following each
       occurrence of 'linear-white-space', each sequence of up to 75
       printable characters (not containing any 'linear-white-space')
       should be examined to see if it is an 'encoded-word' according to
       the syntax rules in section 2.  Any other sequence of printable
       characters should be treated as ordinary ASCII text.

We more or less do this exactly, but we relax it slightly - we do no length checking.

And while i'm at it: 

6.3. Mail reader handling of incorrectly formed 'encoded-word's

   It is possible that an 'encoded-word' that is legal according to the
   syntax defined in section 2, is incorrectly formed according to the
   rules for the encoding being used.   For example:

   (1) An 'encoded-word' which contains characters which are not legal
       for a particular encoding (for example, a "-" in the "B"
       encoding, or a SPACE or HTAB in either the "B" or "Q" encoding),
       is incorrectly formed.

   (2) Any 'encoded-word' which encodes a non-integral number of
       characters or octets is incorrectly formed.

   A mail reader need not attempt to display the text associated with an
   'encoded-word' that is incorrectly formed.  However, a mail reader
   MUST NOT prevent the display or handling of a message because an
   'encoded-word' is incorrectly formed.
Which again, is exactly what evolution does.

--
Michael Zucchi <notzed ximian com>

Ximian Evolution and Free Software Developer

--- End Message ---
--- Begin Message --- 
On Wed, 2004-06-16 at 14:21 +0200, Xavier Bestel wrote:

On Wed, 2004-06-16 at 18:12 +0800, Not Zed wrote:

The string can't contain any spaces, including linear white space.
The whole token is supposed to be less than 76 characters  for this
purpose, so that any folding (wrapping on multiple lines) is outside
the token boundaries.


Ok. I also have this one, which doesn't contain whitespace in the
encoded part:

Subject: d=?ISO-8859-1?B?6Q==?=claration assurance

And it's still not decoded by Evo.


an 'encoded-word' is defined to be tokenisable as an rfc0822 'word'
token, of which this is not - it is instead embedded into the middle of
an rfc0822 word.

to make it work, do this:

Subject: d =?ISO-8859-1?B?6Q==?= claration assurance

then it will decode (except likely it won't look right, but that's
because the original mailer is braindamaged (yes, that's a technical
term)).

Jeff

--- End Message ---
--- Begin Message --- On Wed, 2004-06-16 at 14:52 +0200, Xavier Bestel wrote: 
On Wed, 2004-06-16 at 08:29 -0400, Jeffrey Stedfast wrote:
> On Wed, 2004-06-16 at 14:21 +0200, Xavier Bestel wrote:
> > On Wed, 2004-06-16 at 18:12 +0800, Not Zed wrote:
> > > The string can't contain any spaces, including linear white space.
> > > The whole token is supposed to be less than 76 characters  for this
> > > purpose, so that any folding (wrapping on multiple lines) is outside
> > > the token boundaries.
> > 
> > Ok. I also have this one, which doesn't contain whitespace in the
> > encoded part:
> > 
> > Subject: d=?ISO-8859-1?B?6Q==?=claration assurance
> > 
> > And it's still not decoded by Evo.
> 
> an 'encoded-word' is defined to be tokenisable as an rfc0822 'word'
> token, of which this is not - it is instead embedded into the middle of
> an rfc0822 word.

I see. Braindamaged sender mailer, indeed.
The rfc also says that encoded words MUST be surrounded by whitespace, etc etc. 
Any chance for Evo to workaround this (mainly from Outlook for Mac, but
also various web mailers), or will this complicate the parser too much ?

This was discussed previously, at least this second case.  Someone worked on a patch but unfortunately the workaround isn't trivial (its not super hard, but we're busy).

Still, i'm extremely loathe to, since it is a clear breakage of a pretty simple set of rules from a not-particularly complex rfc.  Seriously, MS should know better, for such a fundamental issue.  We've had issues with rfc compliance in that code and fixed it, i'm sure they can too.

--
Michael Zucchi <notzed ximian com>

Ximian Evolution and Free Software Developer

--- End Message ---
--- Begin Message --- 
On Wed, 2004-06-16 at 10:35 -0400, Patrick O'Callaghan wrote:

On Wed, 2004-06-16 at 21:21 +0800, Not Zed wrote:

Still, i'm extremely loathe to, since it is a clear breakage of a
pretty simple set of rules from a not-particularly complex rfc.
Seriously, MS should know better, for such a fundamental issue.  We've
had issues with rfc compliance in that code and fixed it, i'm sure
they can too.


Whatever happened to "be strict in what you send and flexible in what
you accept"? (I'm paraphrasing, but that was once the golden rule of the
Internet).


whatever happened to reading the spec?

seriously tho, rfc2047 is pretty clear about how to deal with broken
encoded-words. simply don't decode them... and this is what Evolution
follows.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature


--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]