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

Paul Menzel pm.debian at googlemail.com
Sun Apr 11 11:26:54 UTC 2010


tags 507431 - moreinfo unreproducible
quit


Dear Noèl,


thank you for following up on my report¹.


Am Samstag, den 10.04.2010, 22:48 +0200 schrieb Noèl Köthe:

[…]

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

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.

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.

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.

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.


Thanks,

Paul


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


[1] http://www.ietf.org/rfc/rfc0822.txt
[2] http://www.ietf.org/rfc/rfc2822.txt
[3] http://groups.google.com/group/mozilla.feedback.thunderbird/browse_thread/thread/660e4120fdd46064/5a8ee00b236f52b0
[4] https://bugzilla.gnome.org/browse.cgi?product=Evolution
-------------- 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/78fb950c/attachment.pgp>


More information about the Pkg-evolution-maintainers mailing list