User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:18.104.22.168) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) Build Identifier: version 22.214.171.124 (20090605) Message filter always fowards emails as a .eml attachment regardless of preferences set in Tools -> Options -> Composition -> General -> Forward Messages Causing emails not to be sent if the mail server does not allow forwarding of .eml for security reasons. Also unless message is copied to a folder all emails that Thunderbird thinks it has sent get deleted. Can also make the client crash if it cannot send the mail after a substantial period of time (period unknown) Reproducible: Always Steps to Reproduce: 1. Setup forwarding as inline in Tools -> Options -> Composition -> General -> Forward Messages -> "Inline" 2. Setup message filter rule To contains: ##your address## Before Date: After Date: Perform These Actions -- Reply with this template Copy message to ##this saves the message from being deleted## Forward Message to: ##some valid address## 3. To test properly this requires a mail server that does not accept .eml attachments. Actual Results: Mail rejected Occasional TB crash. Expected Results: Forwarded the message inline. No crash? No addons used. Valid address used. Can mail to this address and forward messages manually.
Component: General → Filters
Product: Thunderbird → MailNews Core
QA Contact: general → filters
Version: unspecified → 1.8 Branch
This is bug 312025, except for the crash. Does it make any difference if > Reply with this template > Copy message to ## is performed prior to the forward? It wouldn't affect forwarding as attachment when forwarded as a rule, but the crash portion may be the relevant part here.
Seems to be ok until I force it to "Run Now". It then trys to forward all the mail, all the messages get refused by the mail server one by one until the message: Sending of message failed. The message could not be sent because connecting to the SMTP server ## failed. The server may be unavailable or refusing connections... etc etc etc. I have now sent a crash report with refernce to this bug report.
please cite talkback id for your crash http://kb.mozillazine.org/Talkback#Getting_an_incident_ID
Keywords: crash, stackwanted
Talkback reports no longer exist for Sept 2009. Please try to reproduce using v3 and report the crash id for your crash http://kb.mozillazine.org/Breakpad#Viewing_crash_reports question - And what specific server type caused this in your test? And why would a mail server care about what format an attachment is in? currently incomplete without stack and more detail, but putting on closeme list
Whiteboard: closeme 2010-04-15 [needs stack from reporter]
Just ran a test on Thunderbird 3.0.3 No longer crashes Thunderbird when unable to forward e-mail. The following message appears when the rule is run: An error occurred while sending mail. The mail server responded: * .eml file rejected * [Welsh version not yet translated] * * For security reasons this message has been rejected as it contains a * potentially executable attachment - (of type .eml). This form of * attachment has been used recently to propagate viruses and other * malicious content. * * If you have any queries regarding this, then please contact Advisory * (email@example.com). Please check the message and try again.
Severity: critical → normal
Regardless of the crash, it's still a bug that the message is forwarded as a message/rfc822 attachment instead of inline as specified in the preferences. I've experienced that behavior on Thunderbird 3.0.4 on Mac OS. Should there be two bugs, one for the crash (which can be dispositioned based on the repeatibility of the crash) and one for the incorrect forwarding behavior?
Eric, 3.1b1 contains a fix such that the filter forwards inline if that's your preference - see bug 312025.
Thanks David, I didn't find that one in my search!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 312025
You need to log in before you can comment on or make changes to this bug.