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

[Paul Menzel]

Dear Noèl,


Am Sonntag, den 11.04.2010, 14:48 +0200 schrieb Noèl Köthe:

> 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 copied a test message to a local message folder, i. e. no IMAP, and I
can observe this too.

> 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?

Yes and yes. I can reproduce this with the test message and I get
messages from time to time (for example with the MUA mentioned in the
next quoted line) showing this behavior.

> > 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

+ a `Delivery-date` header field is added by the MTA

> - 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.

I do not know how other MUAs handle this, but maybe no `Date` header
field should be added and just `Delivery-date` should be
parsed/considered.

> > ¹ 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.

In my case your reply would be threaded to the acknowledgment message
from the Debian BTS and there is a link to the bug report’s web page.


Thanks,

Paul


PS: Sorry for quoting the whole message. I did not know what information
are unnecessary.
-------------- 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/c58021cd/attachment.pgp>