Red Hat Bugzilla – Bug 145634
Evolution's resending violates RFC2822 and confuses the user.
Last modified: 2008-08-02 19:40:35 EDT
When asked to 'redirect' a mail, Evolution behaves in a confusing and
broken fashion. See section 3.6.6 of RFC2822.
Evolution does not always add Resent-Date: and Resent-Message-Id:
headers. I resent a message to myself and they were absent.
I resent the same message to myself again using a different account
(in the same running instance of Evolution). On the second occasion,
Evolution _did_ seem to add those headers but it deleted the original
Resent-From: and Resent-To: headers, which it should not have done. It
should have preserved those.
The user interface when resending mail is very confusing. It displays
the mail with your signature attached, although when it comes to send
the mail your signature will be absent. If you change accounts (as I
did on the second test described above) you seem to get two copies of
your signature, although still it's only displayed; not sent. The
headers which you edit are still labelled 'From:' 'To:' and 'Cc:' even
though they are to be the Resent-From:, Resent-To: and Resent-Cc:
Finally, on a vaguely related note -- Evolution should be displaying
Resent-From:, Resent-To: and Resent-Date: headers by default. It
should _possibly_ also favour the most recent Resent-From: header and
display that in mailbox indices instead of the From: header, too.
Still broken in FC5.
Dare I ask, is there an upstream bug report for this problem?
If I didn't add it to this bug, then probably not.
The distribution against which this bug was reported is no longer supported,
could you please reproduce this with the updated version of the currently
supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue
turns out to still be reproducible, please let us know in this bug report. If
after a month's time we have not heard back from you, we will have to close this
bug as INSUFFICIENT_DATA.
Setting status to NEEDINFO, and awaiting information from the reporter.
Thanks in advance.
Sorry, David, I have to close this bug now as INSUFFICIENT_DATA.
Why so? It's still broken (and takes less time to check that than to interact