Closed Bug 604574 Opened 14 years ago Closed 11 years ago

Message Filter: Reply with Template does not use Identity specified in the template

Categories

(MailNews Core :: Filters, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mozilla, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11) Gecko/20101007 Thunderbird/3.1.5 When using a Message Filter to auto-reply to emails (Reply with Template), the Identity specified in the Template is not used in the reply email. Only the primary/default Identity is used. Reproducible: Always Steps to Reproduce: 1. Create second identity (i.e. postmaster@domain.com) 2. Create Template with specified identity and content 3. Create Message Filter to trigger a "Reply with Template" Actual Results: Email is sent from default account, not the specified identity. Expected Results: Email should be sent as from the identity set in the Template. Auto-replies (i.e. postmaster as example) would then come from the user's default address, instead of the actual postmaster account which was chosen. Creates a 'spam' source, when the receiving parties computer gets infected with a windows virus. *sigh*
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
This isn't (exactly) the same bug: BUG 303310 expects that Thunderbird can extract and use the identity email address which triggered the filter to be used for the reply identity. (i.e. Difficult to figure out which identity to send it from) The bug I'm raising is different. Even when the reply identity is explicitly specified in the Template (in the FROM field), the FROM field is entirely ignored in the Template in the Filter operation, and the email is still sent from the default identity - even though an explicitly specified email address was provided. (i.e. Ignoring an explicit Template identity to send it from) Regards, Robert.
The other BUG 303310 can also be "mostly resolved" if this issue can be addressed: If the Template specified FROM address is used for the Message Filter reply, then the message filter rule could contain an "[AND] To or Cc / contains / (email identity)", which would permit a reply from a different identity to be possible. To solve BUG 303310 would then require a Message Filter and Template to be set up for each identity needing a reply. However, this is a minor inconvenience and would be a workaround in the interim (given how long the bug has been open).
Marking as unconfirmed as this is a different bug and not a duplicate. BUG 303310 - Determine identify to reply from when using a Message Filter BUG 604574 - Identity specified in Template is not used in Message Filter
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Component: Account Manager → Filters
Product: Thunderbird → MailNews Core
QA Contact: account-manager → filters
anything in error console?
There are no errors that I'm aware of. The message rule I'm using to perform this operation is as follows: Apply Filter when Checking Mail or Manually Run (*) Match all of the following - To or CC contains (email address) - Status is New Perform these actions: - Reply with Template - "Incorrect Email Address" - Mark as Read Template has been set up to reply with appropriate content, and with a "From Address" specified as "Postmaster" (alternate identity). The email address used in the actual reply is however the default email identity and not the one specified in the template. No errors in the log from my knowledge (but could probably test this if needed sometime later). Regards, Robert.
My patch in bug 604574 makes us use the identity the mail was sent to. I don't think it would really be expected that the mail comes from "someone else" just because the template was composed using another identity.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago11 years ago
Resolution: --- → WONTFIX
Err, in bug bug 904478.
You need to log in before you can comment on or make changes to this bug.