[Evolution] Bug#507431: #507431 evolution: ? is displayed instead of date, although Date: is specified in header.

[Noèl Köthe]

Hello Paul,

Am Sonntag, den 11.04.2010, 13:26 +0200 schrieb Paul Menzel:

> > I checked your submitted email header http://bugs.debian.org/507431 and
> > it looks like the sent email didn't had the Date: and it was added at
> > the recipient/by your evolution.
> > The date should be the date of the sender but chronological its after
> > all Received: timestamps.
> > Additional the Date: line is after the X-Evolution-Source: line which is
> > written at the sender/your evolution so this is a sign for
> > later/recipient Date:
> > 
> > Could you reproduce this with the sender and/or could you agree with my
> > arguments?
> 
> Your theory sounds reasonable. I would never have thought about that.
> 
> An other point supporting your theory is that the Date timestamp is
> bigger than the received by timestamps.

Yes. Thats what i meant with my second sentence.

> You tagged this bug unreproducible. Did you try to import my inlined
> email? I can still reproduce this bug. I forgot to note that this is
> happening with an IMAP account. I therefore removed the tag
> »unreproducible« again.

You can reproduce this with the mentioned email or are you getting new
emails from time to time with the same problem?

> Just a note. The sender uses the O2 mail service with the MUA O3SIS UMA
> Mail 7.1.0 Cologne Edition.
> 
> Anyway I glanced through RFC #822 [1] and RFC #2822 [2] and `Date` is
> required. So the MUAs do not comply with the standard.

I aggree with you that the sending MUA is doing it wrong.

> Regarding the order of the header fields I found the following in [1].
> 
>         4.  MESSAGE SPECIFICATION
>         
>              4.1.  SYNTAX
>         
>              Note:  Due to an artifact of the notational conventions, the syn-
>                     tax  indicates that, when present, some fields, must be in
>                     a particular order.  Header fields  are  NOT  required  to
>                     occur  in  any  particular  order, except that the message
>                     body must occur AFTER  the  headers.   It  is  recommended
>                     that,  if  present,  headers be sent in the order "Return-
>                     Path", "Received", "Date",  "From",  "Subject",  "Sender",
>                     "To", "cc", etc.
>         
>                     This specification permits multiple  occurrences  of  most
>                     fields.   Except  as  noted,  their  interpretation is not
>                     specified here, and their use is discouraged.
> 
> So Evolution tries to make the message standard compliant by adding a
> `Date` field. But it should display it correctly when doing so.

OK.

> Anyway in my case I am using Exim as MTA and reading [3] suggests that
> Exim is adding `Delivery-date` header field when no `Date` header field
> is present.
>
> So there is definitely an error in Evolution because as noted when
> replying the date is taken “correctly” from the `Delivery-date` header
> field.
> 
> I searched the GNOME Bugzilla but could not find a report containing
> `Delivery-Date`.
> 
> If you could not reproduce it it is maybe a bug in the Evolution IMAP
> code. Evolution 2.30 has not yet entered Sid/unstable so I could not yet
> try with the latest release. I think, I read the IMAP code has changed
> quite a bit.

So the problem we both see is:

- when a sender is not rfc-compliant and don't add a Date: line
- we guess evolution adds the missing Date: line
- but doing this wrong because after the addition to the header its
still not shown in evolution

I will report this upstream to see what the developers say.

> ¹ To preserve threading when replying to bug reports you do not have the
> original messages from you can get them using `bts show --mbox 507431`
> and import that mbox file (in `~/.dev-scripts/bts/`) to your MUA (for
> example Evolution).

I have hear about this ;) but because im working on all the old bugs I
used URLs so the reporter will find everything and not just my quoting.

-- 
Noèl Köthe <noel debian.org>
Debian GNU/Linux, www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/pkg-evolution-maintainers/attachments/20100411/81e4b8d3/attachment.pgp>