User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 The Mozilla documentation states - "By default, Mozilla Mail & Newsgroups stores copies of your outgoing messages in the Sent folder for the current account. This is not being done for my outgoing messages. I even went to Edit->Mail & Newsgroups->Copies & Folders and manually checked "Place a Copy In" and filled the Sent button. None of the 6 test messages I sent (to myself) were stored in Sent folder on the IMAP server. Reproducible: Always Steps to Reproduce: 1. Entered email addressed to email@example.com or one of my web-based accts 2. Clicked Send button 3. Checked Sent folder... none of the 6 test messages was copied there. Actual Results: None of the test messages were copied/stored in the Sent mail folder Expected Results: Copies of the messages should have been stored in the Sent foldedr This bug would cause me and could cause others to reject usage of Mozilla mail client (and possibly suite).
(1) Does problem still occur on latest nightly? (2) Do you have "Sent" folder? (3) If no, can you create "Sent" folder? (4) If yes, isn't it "sent" folder instead of "Sent" folder? See http://forums.mozillazine.org/viewtopic.php?t=34079&highlight=imap+sent+folder
Had similar problem with sent, draft, and templates folder. Equivalent problem is failure to retain check marked and radio settings in "copies & folders". Problem resolved via string editing of specific user_prefs in prefs.js related to sent, drafts, and template folders and to server-name strings. System: WinXP and Mozilla 1.5, but the problems is probably common to WinOSes and other Mozillas I think problem arose as a consequence of a two-step transition (I did this!) 1 - Upgraded to Mozilla 1.5 from Netscape 4.79 with profile conversion 2 - Changed ISP and thus edited outbound mail server address. By comparison with clean install Mozilla prefs.js from a different PC, I observed file paths for clean Mozilla use %40 as separator whereas the sick Mozilla uses %25. Also looked like some other user prefs lines in user_pref ("mail.xxx") sections differed in clean prefs.js compared to bad one. Resolved by editing prefs.js (example: tediously replaced sent, draft, template folder paths and other "mail." strings with equivalent phrases from new Mozilla installation. When Mozilla mail started again, sent and draft folders worked correctly. My guess is that the Mozilla installed via the upgrade path doesn't know how to handle changed mail servers. That type of change should establish a new "server- named" directory just below the \\MAIL directory with equivalent changes in prefs.js. I don't think prefs.js changes server pointers and I don't think the new mail-server folder is established correctly. Thanks to those whose good intuitions suggested a possible relationship with changes in ISP and with upgrades. HTH, Andy
To Comment #2 From andy colb : > 2 - Changed ISP and thus edited outbound mail server address. Do you mean editied prefs.js directly and changed mail.server.serverN.hostname and/or mail.server.serverN.userName? If yes, it is user error. When user change server name and user name from account setting UI, new(changed) server name and user name are saved in mail.server.serverN.realhostname and mail.server.serverN.realuserName. See Bug 14295 These realuserName/realhostname are used in login to server when chaged but initial userName/hostname are used in internal mail path. Therefore if you change username/hostname in prefs.js manually, you have to change manually all internal mail path specification kept in Mozilla's profile, filters and so on too. In addition, your case seems to relate to problem when "%" in user name or server name - "%25" is escaped form of "%". See also Bug 221386 Comment #9
I also am having the same problem, recently upgraded from 1.5 to 1.6 and the mail app stopped saving my outgoing messages. Will not save when checked in the mail settings. I am running 1.6 on WinXP Pro.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.