Closed Bug 89285 Opened 23 years ago Closed 21 years ago

Often get "message was sent but copying to sent folder failed" error dialog

Categories

(MailNews Core :: Networking: IMAP, defect, P2)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: steve, Assigned: Bienvenu)

References

Details

(Keywords: dataloss, fixed1.4.2)

Attachments

(5 files)

IMAP network log.
891 bytes, text/plain
Details
proposed fix
822 bytes, patch
cavin
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
IMAP log file
31.08 KB, text/plain
Details
proposed fix
566 bytes, patch
sspitzer
: review+
sspitzer
: superreview+
asa
: approval1.4.1-
mkaply
: approval1.4.2+
sspitzer
: approval1.5b+
Details | Diff | Splinter Review
IMAP log file (for Excel attachment)
19.31 KB, text/plain
Details 
Windows build 2001070304

It seems like after I send a newly composed, unsaved email (either a new email
or a reply), I frequently get a "message was sent but copying to sent folder
failed." prompt. It doesn't happen all the time, but it seems like it's
happening about half the time. I didn't have this problem using builds from
maybe a week ago.
reassigning
Assignee: bienvenu → ducarroz
Component: Mail Database → Composition
I occasinally see this message too. It seems to take an age for Mozilla to save
an item in an IMAP folder (saving in a local folder seems to be pretty quick).
If I send two messages simultaneously this increases the probability of the problem.
I'm just sending mail via SMTP for a POP account (copying to a local folder). My
original estimate was probably too high. Maybe a third of the time, I get this
error message and no copies in my sent folder.
rubber-stamp confirm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Copying sent mail to sent folder fails often. → Copying sent mail to sent folder fails often
Happens to me 100% of the time, on every release for over a month now, if it is
trying to copy to sent folder on local folders (Which is what happens when I
send email to a newsgroup).  Does not occur if copying to sent folder of POP3
account. (Just confirmed on build 2001073103).
Local folders directory does exist, and manually copying messages to sent folder
on local folders works fine.  If contents of local folder directory manually
deleted, files are recreated and bug still reproducable.
Happens to me as well - with 0.9.3 even heavvyer than with 0.9.2 before. Using
IMAP only here, and the copy should be stored within the Sent folder of the same
account the mail is sent from. With 0.9.2, when it failed once, it succeeded the
next time. With 0.9.3, when it failed once, it fails forever - until I restart
Mozilla.
It seems it needs some time until it appears the first time (I write a lot of
mail here, since it's my job :) - I try to count the messages sent befor the bug
happens, maybe there's some connection between the amount of messages sent until
it fails.
Running Mozilla under SuSE Linux 7.1 here.

</izzy>
I am getting the same problem with my IMAP sent folder.  It used to always work
smoothly, now I get one of the following responses:

1) It simply tries forever and I finally end up closing the send window.
2) It tries for a long time and then finally completes the copy.
3) It returns an error that the copy failed but sending suceeded.

We have observed that Mozilla takes unusually long to copy messages to the sent
folder, but this only seems to happen when there are many (several
hundreds/thousands) of messages in the target sent folder.  Changing the sent
folder to an empty folder (or one with just a couple emails) copies quickly.

Copying a message to a sent folder containing 3500 emails took 13 seconds on a
900Mhz system (384MB RAM) using the latest nightly (as of now).  There is no
additional load on the server, and the client is also idling, so I'm really not
sure what it's doing during the delay.
Jason, you might want to profile to find out where all the time is spent...
I'm no mozilla hacker, unfortunately.  Just a typical user. :)  Unless this is
something that doesn't require a knowledge of the code base and there is
documentation somewhere on how to profile the code or turn on debugging?
> Unless this is something that doesn't require a knowledge of the code base

It is. Hakan, asking testers to profile is a bit too much to ask.
I just saw this bug with Mozilla 0.9.2.1. UW-IMAP, Sent folder on server, 800
msg in Sent folder, high-end machine, exclusive server and and network.

I sent 2 messages a few mins ago and they were stored well. The last one did not
get stored (it's now 25 mins later and I deselected and selected in Mailnews the
Sent folder to force a refresh). All are sent from the same profile. I use the
custom ("Other") Sent folder pref.

Severe dataloss -> adding keywords and upping severity.
Severity: normal → critical
Keywords: dataloss, mozilla0.9.4
OS: Windows 98 → All
Hardware: PC → All
Noticed the same with the Linux version - miss more than 50% of the sent mails
from one of my accounts.
Since I changed the sent folders from IMAP to local, I got no errors of copy
failures for almost 4 days, so it seems to be strongly connected to IMAP.
</izzy>
mscott, please check this out.
Component: Composition → Networking - IMAP
There may be two different problems here.  I never use IMAP (only have POP3 and
news accounts).  It never happens with my POP3 accounts but always with news
accounts (ie: secnews.netscape.com).  I'm using Build 2001083003.
I need to investigate...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
I am seeing this as well. It is extremely annoying, and causes data loss. If you
need to come over and have a look at it happening, feel free :-)

Gerv

My 2 cents: I also have this happen frequenty (not every time, but 75% at
least).  My add is that during these incidents, I don't get any error message,
whereas some of you reported receiving some.
Just wanted to add a *me too* to this bug.  I get it on 0.9.5 on Running Redhat
Linux 7.1.  I get it 100% of the time I reply to a message using IMAP.  My IMAP
server is Lotus Domino R5, if that helps.
I use to have this problem but recently I haven't see it!
I must agree, I don't see this problem anymore either.
I am closing this bug as WFM, please reopen it if you are still able to
reproduce this problem often.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
J-F,

this bug has pleaged Mailnews since a long time, more or less often. It came and
went away mystically. It has been reported several times (in part by me), but
usually closed WFM, because QA and the developers couldn't reproduce it.

There seems to be a basic, but weird bug behind it. Considering the severity, I
think we must find the real cause and eliminate it before 1.0 can ship.

Reopening for those reasons.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can consistently reproduce this problem with Mozilla 2001102415.  My Sent
folder ({mail}INBOX.Sent) has 4600 messages, and copying the email to the sent
folder took 25 seconds.  If I change the sent folder to a folder with just a few
messages (in this case 18), copying to sent folder is instant.  So the naive
conclusion is that it is dependent on the number of messages in the sent folder.

Server side uses Courier IMAP 1.3.5.  Netscape 4.x does not behave this way.  As
I mentioned earlier, there is no server load during the time Mozilla stalls on
copying to sent folder, so it's almost certainly not a server issue.  Client
system is a Duron 800 with 384MB RAM.
Jason, this bug is about the copy to the sent folder failing, not taking a long
time. Is it failing for you or just taking a long time? You might try removing
your Sent.msf file, letting it get regenerated by clicking on the sent folder,
and then seeing if this problem persists. That fixed the problem for other
people who were having the copy take a long time (which was a different bug).
I don't see this problem either although I have recently switched my email to a
Courier IMAP solution instead of, as in my original post, sending it out via
SMTP with copying to a local folder.

As for the Jason, have you hit Mozilla looking for bugs related specifically to
Mozilla and Courier because there were/are definitely issues in that
relationship. Mozilla appears to be a bit greedy in the # of connections to
Courier which eventually causes a massive slowdown or failure to connect when
Courier limits the number of simultaneous connections too low. Try bugs 87825
and 92072. 
OK, this is a hearty me too!

About 1/2 of the time, I get the error that the message was sent successfully
but the copy to the IMAP Sent folder failed (I then have to acknowledge this on
a couple of dialog boxes).

Another, perhaps related, issue is that dragging a bunch of messages at once
to an IMAP folder results in only some of those messages actually being copied
to the IMAP folder...
> Another, perhaps related, issue is that dragging a bunch of messages at once
> to an IMAP folder results in only some of those messages actually being copied
> to the IMAP folder...


Au. Filed bug 107233.
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Blocks: Beonex
I have noticed a more serious problem which seems to be related.  In
mozilla-0.9.5  tell it to put a copy in the Sent folder of your IMAP account. 
Mozilla will not complain.  Now try and send a message to anyone.  When you
press send mozilla will complain that there is no name in the recipient list of
the message even if you do have a recipient entered.  Mozilla will refuse to
send mail until you set the Sent folder back to the local folder.

My IMAP server is MS Exchange 2000 (not my fault, I just work here) which may
complicate matters.
This bug was created july 2001.  Since then we have solved other failures to
copy to Sent folder for both IMAP and POP (problems specific to IMAP and POP not
general).  This bug contains IMAP and POP reported problems.  We cannot
reproduce this problem with new profiles (migragted/not migrated) )(IMAP or
POP).  There may be individual problems with each reporter's profiles due to
installing builds that had some of these problems.  In order to find out if the
problem still exists with individual profiles I would like to ask each reporter
in this bug to  1. Remove the .msf file for the Sent folder that is a problem
(while app is closed).  2. Reset your Account Settings for Copies and Folders
for the problem account by clicking on the settings again and OK'ing the dialog.
 3. Try sending again multiple times and report back if you are still having a
problem.  If reporting back that it's still broke, please include: Using POP or
IMAP, if you have multiple mail accounts in the profile, about how much disk
space you have free on the drive where the Sent folder is located.  After I get
these updates, I will log separate bugs for IMAP/POP.  Note: Heber and Jason,
your scenarios are different from this one.  There is already a bug for Jason's
scenario, Heber please log a new bug with your steps, we will investigate that
with an Exchange Server (I saw this once before, it was a composer addressing
bug where there were  strange characters in addressing field that were not
visible).  Can you give exact steps so we can try to reproduce it here.  Thanks.
I noticed that even though I sent mail, the bug manifested when I clicked
Compose while a newsgroup (n.p.m.general, to be specific) was selected in the
folderlist. However, copy to sent folder seems to work fine if I have, say, the
Inbox selected.
With latest nightly RPMs (2001112815_trunk-0_rh7), Im unable to change "Place
copy in" setting, after I created valid IMAP-account. Before creating this
account, copies were going to Local folders/Sent, just like they should, but
after creating account, setting is "Sent folder on click here to select
account". No matter what I change on that page, even disabling sent copies,
always after visiting another page / closing settings / closing mozilla /
rebooting computer, settings are restored to default - Sent folder on click here
to select account.
I tried even ripping lines out from .mozilla/username/mumblemumble/prefs.js, or
replacing those with fcc pointed to local folders/sent, starting mozilla-mail
will overwrite those settings with "sent folder on click here to select account"

Practically, Im unable to send any messages now without headache and anger.
I managed to get it working now; I uninstalled mozilla, renamed .mozilla folder
on my home directory, installed 0.9.5 (0.9.6 had same behaviour), and updated
back to nightly build, now it seems to work.
I followed the advice of esther@netscape.com.  After this, it seemed
fixed for a couple days, but now continues to occur.

As far as my config goes: This is IMAP (I have no
POP accounts), and I have two accounts in my profile.  The
disk has 9GB free.
One very easily reproducible case for this bug is to create an IMAP account for
mozilla, and exit mozilla.  Ensure that your not running in "QuickLaunch" mode,
and that no mozilla processes are still running.  Also make sure that the only
thing that loads by default is the navigator.  

Now start mozilla, but do now open a mail window, instead goto File / New /
Message.  Compose a simple message and send it.  It should send the e-mail ok,
but it fails copying to the Sent Folder on the IMAP server with the error

"The current command did not succeed.  The mail server responeded: SUBSCRIBE
failed: Already subscribed to mailbox Sent."

err, thats "but do *NOT* open a mail window"
Brandon, what you describe is bug 90147.
QA Contact: esther → huang
This bug started for me when I asked Norton Antivirus 2002 to check my POP mail
(2 accounts). I am on build id 2001113003.

What happens is that it is impossible to set the sent folder location in the
account settings. It sets, you say OK, but if you reopen the settings window
again (even after a Mozilla restart), the destination folder is unset again!
I removed the sent.msf file a la #30 for the POP account. I reset the account,
and was still unable to make a sent folder selection thgat stuck. Furthermore,
sent.msf was never recreated!
I told Norton to stop scanning the e-mail, and lo and behold, the sent folder
settings could again be reactivated. 
This is a problem since I really need e-mail to be virus scanned!
That's probably bug 113682 or bug 10004 or similar.
Cavin point me to comment #5 in bug 87825 written by Brice Ruth which explain
the reason why it failed:

------- Additional Comment #5 From Brice Ruth 2001-08-11 16:31 -------

I'm seeing a problem that seems to be related to the way Mozilla handles
connections - when mail comes into my INBOX (courier-imap), more than likely, it
gets filtered (client-side, via Mozilla mail filters) into a subfolder.  Often,
when I switch over to see what mail I've received, I'll see that a new message
is in a subfolder, so I'll click on that subfolder (or hit 'N' for Next) at
which time Mozilla appears to think that a connection to the folder is still
open (since it filtered a message into it), but my IMAP server has since closed
the connection.  The result is that Mozilla just hangs there until I do
something else, like click back to INBOX and then back to my subfolder - usually
Mozilla then opens a new connection, but depending on the timing, it will not
'forget' that it thinks it has a connection open and I'll have to exit Mozilla
entirely to get back into that subfolder.  

The scenario I detailed is one aspect of this problem - the other is if a person
has their 'Sent' messages folder on the server (relatively common if you access
your mail from various stations).  What happens here is that sending mail waits
an inordinately long time on 'copying message to Sent folder' because Moz thinks
its connection is still open when in fact the server has closed it.  After a
while, the send operation times out and a message is displayed indicating that
the sending of the message succeeded, but copying it failed.  This gets pretty
annoying pretty quickly and again, sometimes the very next message will be
stored properly, sometimes exiting Mozilla is required to 'reset' Mozilla's memory.

So, is this related?  If not, is another bug addressing this already?  Should I
file a new bug?  This particular issue has been around since way back in NS4 - I
have users complaining *all the time* that they get server disconnect messages
w/ NS4.7x.  Highly annoying as I'm sure you can imagine. :)

-Brice


I don't think I am the right owner for this bug. Reassign to cavin. Maybe should
be for mscott!
Assignee: ducarroz → cavin
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Keywords: nsbeta1+
Brice, when we filter messages into imap folders, we don't open a connection to
the destination folder, because we don't need to, unless the imap folders in
question are on a different server. It doesn't sound like they are on a
different server, from your description.

We cache imap connections for 29 minutes, which is the amount of time the IMAP
RFC says we can. Does your imap server shutdown connections if they've been open
for less than 29 minutes, or is something mozilla is doing causing the
connection to get shutdown? Have you tried generating an imap protocol log?
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap 

the log would show if the client is doing something to kill the connection. It's
also possible (if not likely) that the fix for bug 72928 might help.


Ccing Brice to read comment #44 from bienvenu. 
Wow, the posterity that my comments have achieved :)

Anyway - I haven't been using Moz for my mail for a little bit (I switched over
to OS X and the mail/news situation there was a bit hairy for a while). In any
case, to re-encounter this bug, I will need to switch over my mail to Mozilla
again, which in and of itself isn't difficult, but transferring all my filters
from Entourage to Mozilla may prove to be quite tedious. I should really start
doing server-side filtering of my messages. Does Moz have a setting where it
will examine IMAP subfolders for new messages periodically? That would be
particularly nice for using server-side filtering.

The point: it will take me at least a few days to get to the point where I can
check this out, I think. I'll report back when I have something.

-Brice
Just a note.

I was having this on one Windows machine (build 2001122803, and at least one
before that one). But I managed to work around it.

What was happening was that I had a POP account and SMTP mail send set up, with
all mail being saved on the local system. At some point I changed the settings
for the account. I think it was the smtp server setting. I also got rid of an
older directory from a previous account I'd set up. After that point I got the
"Mail sent OK, but wasn't able to copy message to Sent folder" message with
most, if not all, send attempts.

I looked in the preferences and changed the "Save mail in this sent folder" (and
the same for the draft stuff, which also was not working) setting. But whenever
I changed anything on that pane it was set back to "Click here to select and
account" or whatever.

So I went into the prefs file. In there the path was to the directory I had
destroyed for an account I wasn't using anymore. So, after some trial and error
(looking at the format of the relevant lines in the prefs file) I changed the
settings and when I started up, things worked fine.

What this indicated to me was that at some point the system, unable to locate
the directory which was listed in the prefs file, had decided that it was
impossible to alter the directory preference setting at all.

It seems to me that at some point (perhaps when I'd set the account I'm using as
the default one), the system should have asked me, or something, whether I
wanted to change the Sent location for my mail. And at the very least, it should
have been possible for me to set it after that time to an existing account
successfully.

Personally, I think that after one attempt to save to a directory that didn't
exist, it should have complained to me and asked to change it to the Sent folder
for the existing account. Surely that wouldn't be too hard.

Anyway, If anyone else is having this sort of problem (and I realize from this
bug report that there are many different conditions which cause this error),
perhaps my experiences can give them hope, and a pointer to a possible resolution.

Take care.
Navin is this a dup of your copy service rewrite bug?
Well, this bug seems to have evolved over time, but the copy failing for 2nd
imap message because 1st one is still being copied is related to copyService issue. 

taking, should get fixed by copyService rewrite, if not I will give it
back to you.
Assignee: cavin → naving
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Priority: -- → P2
FYI: I haven't seen this bug since (incl.) 0.9.4.1 anymore, IIRC. (But I still
think that you should find out what is going on.)
Attached file IMAP network log. — 
This is a log of the IMAP append command.  The message is appended and command 

response is ok but Mozilla says "..., copying to Sent folder failed".
Target Milestone: mozilla0.9.9 → mozilla1.0
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
I am using build 0.9.9 2002031008 on Red Hat 7.1. I am having the same problem
as comment #47 above, I can not set the sent folder to anything. 

Everytime I try to change it to a Local folder or my regular sent folder, I
click OK but if I open the preferences again it was not changed.

Like comment 47 I recently cleaned up my email accounts and deleted some old
unused ones.

With previous build I was getting the message "send successful but could not
copy to sent folder". Now I am not getting any error message, and the email is
not copied anywhere, so for now I have to bcc to myself if I want to keep a copy
of it.

I notice (using 0.9.9) that even when saving in "Sent" hangs or fails, that
saving the unsent message in "Drafts" works. I traced the two different messages
on the IMAP Server side: the byte counts in the underlying APPEND commands were
different for the two cases, which makes sense as the "Drafts" message contains
two headers that do not appear in the sent message, but if those headers are
taken into account the different byte count does *not* allow for the additional
return-character added near the end of the Content-Type field in "Sent" case.
This means the server will send its OK response before the client has finished
sending data: I think the client then sends one more byte and then waits for a
response that has already happened. 

Here is the line from the server side trace 

Content-Type: text/plain; charset=us-ascii; format=flowed\r\r\n
No longer blocks: Beonex
*** Bug 106451 has been marked as a duplicate of this bug. ***
*** Bug 136134 has been marked as a duplicate of this bug. ***
*** Bug 123063 has been marked as a duplicate of this bug. ***
I'm still seeing this bug on with 1.0rc1 on MacOS 9.2. I have 79 messages in my
Sent mail folder on my server and it fails to copy here nearly every time. I
tried using both the "Sent mail on server" option and the "Other" folder option.
Once I must of twiddled something because it worked OK for several messages and
now it fails nearly every time again. 
To follow up on my own comment: I was saving mail into a  mail folder named:
sent-mail in a directory named sent-mail. However, this directory appeared as a
mail folder in Mozilla. I visited the preferences and found that the directory
was "subscribed" as a mail folder. I unsubscribed that folder and it appears
that my "saving to sent-mail" bug is currently not reproducible anymore. I think
this a seperate bug though: Mozilla shouldn't allow me to "subscribe" to a
directory as if it were a mailbox, since that's never meaningful. 
Mark, two things - 1) it's only not meaningful if your IMAP server doesn't
support folders that can have both messages and sub-folders (many do), and 2)
we've made it so you can't subscribe to noselect folders with the subscribe ui,
anymore, but if you subscribed with a previous version, we won't unsubscribe
you. It's also possible that if you create "a/b", we might subscribe you to "a"
as well as "a/b" or even "a" if you create "a/" - I'm not sure of the current
state of that. 

And finally, I'm a bit confused - you're not saying that your sent mail folder
was a directory, are you? If I read your comment correctly, you were saing you
have a folder "sent-mail" in a directory "sent-mail", i.e.
"sent-mail/sent-mail". My guess is that unsubscribing to that folder made us
create a new sent mail folder for you - is that true?
I get this also.  To reproduce, set up Mozilla with an imap server.  No special
folders are required.  Send a message BEFORE or AFTER, but not during, reading
mail.  Mozilla responds with:

    The current command did not succeed.
    The mail server responded: SUBSCRIBE failed:
    Already subscribed to mailbox Sent.

Mozilla will keep trying forever with the message:
     Copying message to Sent folder

The old Netscape 4.7 trick of using 'send later' or 'save as draft' does not
work.  You're stuck, the only choice is to cut & paste the message.

-----------------------------------------------------------------------------

My version numbers are:
     * OK idiom.com IMAP4rev1 v11.241 server ready
      Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020424

See also bug #90064 and bug #96932
Depends on: 90064
Duplicate bug #134471 has the best summary of steps to reproduce the bug.  It's
100% repeatable, as the poster says.  It's also cross-platform.
Depends on: 134471
bryce, what you have is another bug (which I also saw) with a different cause.
This bug appeared in other circumstances.
No longer depends on: 90064, 134471
Does this exist now?

We have just fixed bug 27002 & bug 90494 related to the same issues of Cyrus &
Courier IMAP server (also mentioned in the comments here).

Pls try the refresh nightly build if you want to try. The patch has just in.
Fix looks good; I can easily reproduce the problem - by sending 4 emails
simultaneously - using a build from a checkout of about 3pm GMT 6th August, and
cannot reproduce at all with a build from a co of 7pm GMT 7th August.

Is it my imagination, or is the general speed of copying to Sent also much improved?

Great stuff, thanks...
if you were sending messages simultaneously, then my fix for bug 129495
(slowness copying to sent folder on imap servers that don't support uidplus) is
probably why this is fixed for you, and not Henry's changes (his changes would
only fix it if it NEVER worked for you). My fix makes it much faster, and makes
it much less likely you will lose the race conditions you get into with
simultaneous sends.
I thought the right way is to use nsMsgCopyService to never experience this
problem(like for slower connections).
I didn't make that change to fix this problem, Navin. It's just a fortunate side
effect that it makes it less likely to happen.  Please read bug 129495 for
details as to why that change was made.
bienvenu is right. My patch solve the issues that you cann't send or save mails
on some IMAP servers, such as Cyrus and Courier server. His patch solves the
speed issue.

Since this bug doesn't exist now, I think we can close it. Anyway, we can still
keep it open for 1 day or so. Can anyone verify this again? Thx.
I don't think that the recent checkins could have fixed this bug.
This bug was about the fact that sending *sometimes* failed, not all the time
(what Henry fixed), and to fix that problem *completely* (which bienvenu's fix
could not have done, as he said himself).
So, either it was already fixed before the checkins or it is not yet fixed.
For me, there is no change since comment 51.
Attached patch proposed fix — — Splinter Review 
This fix depends on the copyService cleanup I attached in another bug. The fix
is to queue the request if we are already processing a request.
Cavin, David, Can you review the fix ? thx. I have tested the fix and it works.
Comment on attachment 95012 [details] [diff] [review]
proposed fix

r=cavin.
Attachment #95012 - Flags: review+
Comment on attachment 95012 [details] [diff] [review]
proposed fix

sr=bienvenu
Attachment #95012 - Flags: superreview+
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
This fix should be verified on trunk (Buffy).
Reassigning QA to Gregg.
QA Contact: huang → meehansqa
Tested using Trunk build 20020905, working correctly. Closing as VERIFIED.
Status: RESOLVED → VERIFIED
This is broken again in the 9/27 Linux build. It always worked before this build.
It happens when I copy the sent mail to a local folder and the message is going
to an smtp server that requires a uid/pwd.

sending the same mail thru an smtp that does not require a uid/pwd, and using
the same local folder works.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
do you remember what build you were running before the 09/27 build so that we
can have a better idea when this regressed?
I think it was the 9/11 build.

I also think something funny happens when the smtp server needs authentication,
and it is pulled from the Mozilla stored passwords. I say this because I also
have trouble in Windows at this point when Norton antivirus tries to check the
outgoing mail for viruses, and everything also hangs (bug 166867).

But I was unable to do anything in the windows 9/27 build and had to regress
back to 9/14 or thereabouts. So, I have not seen this problem in Windows lately...
it looks to me like 

166676, 155532, 16989, 170181, 173119 are all dupes. there may be more (my 
lunch hour is ending ;) ).

however 170777 and 171685 may be a corruption elsewhere (in prefs) that are 
causing this behaviour as a side-effect.
Just to add my two cents: this happens to me on Windows build 2002101612 (Mox
1.2b).  I send an email on my IMAP account.  It gets sent, but the "Copying
message to Sent folder" just hangs and hangs.  If I cancel, and try and save the
message to Drafts, same thing: hangs on trying to copy to Drafts folder.

My Sent and Drafts folders are on the IMAP server.  Sent only has 20 items in it
now (so the "only happens when there are hundreds of items in the folder" fact
isn't true).  Drafts is empty.  The hanging usually happens at the end of the
day, after a fair amount of activity on the account.

The only solution seems to be to kill all my imapd processes on the server,
completely shutdown Mozilla, and restart it ... but even that doesn't always work.

There also isn't any IMAP traffic from my machine to the server during a send. 
I realize the send goes out on port 25, but is the "copying to sent folder"
supposed to happen on port 143?  If it is, then it doesn't.

Hope this helps.
When sending mail, mozilla does *not* save it to Sent mail.
Also, when trying to get it to save it there (through account
settings, copies&folders) it will *not* save the settings
i set there. ie: i want it to copy the files to my imap
sent mailbox, but after i press ok, the setting is lost.
Mozilla *used* to save email to my sent mail, but for a VERY
long time, it hasn't worked. Same goes for BCC'ing (can click,
can fill in, setting not saved.)

Mozilla data:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

imap server data (if it helps):
* OK [CAPABILITY IMAP4REV1 X-NETSCAPE LOGIN-REFERRALS AUTH=LOGIN] <hostname>
IMAP4rev1 2001.315 at Wed, 13 Nov 2002 11:19:52 +0100 (CET)

type of imapd: wu-imapd (2001adebian-6)
It happens to me also with Mozilla 1.1: copying a (second) sent message to the
"Sent folder" (which is an IMAP folder) fails when mozilla is already saving a
previously sent message ("message was sent but copying to sent folder
failed").  Mozilla should recognize that the folder is somehow locked by another
operation and patiently wait until that operation is finished.  Then the lock
should be removed and saving the second message should be re-tried.

I'm confirming this bug due to the long list of various comments about fixed/non
fixed issue.

Cheers
Problem still exists for me in 2002101612 (1.2b) Linux.  I'll add that the issue
comes up *only* on a modem connection (56k); on a T1 line, I've never seen it. 
Once one message fails to copy properly, Mozilla must be entirely restarted to
get copying back to normal working order.
I see the problem on my office LAN connection, so I don't believe it is
exclusive to modem users or slower connections.  However, I agree that
completely restarting is the only way to fix it ... but sometimes then that
doesn't even do the trick.

I've just installed yesterday's nightly build, so we'll see how that goes.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021123

Jan, your problem is different from the other problems. You're having a problem
with the preferences UI, so the setting isn't getting set. My guess is that a js
exception is getting generated for some reason. My first suggestion would be to
try a newer build. Another suggestion is to turn on the javascript console
(Tools | Web Development | Javascript Console) and then try setting the prefs
again, to see what error if any is getting displayed on the js console.

I'll look into the simultaneous copy problem. That was supposed to have been fixed.
Jan, can you send me, or attach here, the settings in your prefs.js for the fcc
folder? They look something like the following:

user_pref("mail.identity.default.fcc_folder", "...");
user_pref("mail.identity.identity1.fcc_folder", "...");
user_pref(mail.identity.id1.fcc_folder_picker_mode", "0" or "1");

I believe somehow they've been set to an invalid setting, and we're not dealing
with the error.
We have the same problem with mozilla-1.2.1, Linux (both on client and server)
and Cyrus IMAPD 1.6.24.

In our paticular case whe have two IMAP accounts for one user: for the first
one, saving in the account's "Sent" folder works, for the second account it doesn't.

Here are the "Advanced" prefs.js server-settings for both accounts:
[...]
user_pref("mail.server.server1.namespace.other_users", "\"user.\"");
user_pref("mail.server.server1.namespace.personal", "\"INBOX.\"");
user_pref("mail.server.server1.namespace.public", "\"\"");
user_pref("mail.server.server1.server_sub_directory", "INBOX.");
[account #2 is the "Local" account]
user_pref("mail.server.server3.namespace.other_users", "\"user.\"");
user_pref("mail.server.server3.namespace.personal", "\"INBOX.\"");
user_pref("mail.server.server3.namespace.public", "\"\"");
user_pref("mail.server.server3.server_sub_directory", "INBOX.");
[...]

As far as I can tell, advanced server settings are identical for both IMAP
accounts (and they show exactly the same values in the configuration dialog)

But I found an interesting detail in the TCP/IP traffice log for the IMAP
connection between client and server:

Look at this:

    No. Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.12          192.168.1.2           IMAP    
Request: 11 list "" "INBOX.Sent"
      2 0.000378    192.168.1.2           192.168.1.12          IMAP    
Response: * LIST () "." "INBOX.Sent"
      3 0.000555    192.168.1.12          192.168.1.2           TCP      32898 >
imap [ACK] Seq=730952999 Ack=157236098 Win=7504 Len=0
      4 0.059132    192.168.1.12          192.168.1.2           IMAP    
Request: 12 subscribe "INBOX.Sent"
      5 0.059567    192.168.1.2           192.168.1.12          IMAP    
Response: 12 OK Completed
      6 0.059736    192.168.1.12          192.168.1.2           TCP      32898 >
imap [ACK] Seq=730953026 Ack=157236115 Win=7504 Len=0
      7 0.132685    192.168.1.12          192.168.1.2           TCP      32900 >
imap [SYN] Seq=777846812 Ack=0 Win=5840 Len=0
      8 0.132758    192.168.1.2           192.168.1.12          TCP      imap >
32900 [SYN, ACK] Seq=211069600 Ack=777846813 Win=32120 Len=0
      9 0.132914    192.168.1.12          192.168.1.2           TCP      32900 >
imap [ACK] Seq=777846813 Ack=211069601 Win=5840 Len=0
     10 0.153722    192.168.1.2           192.168.1.12          IMAP    
Response: * OK bach Cyrus IMAP4 v1.6.24 server ready
     11 0.153940    192.168.1.12          192.168.1.2           TCP      32900 >
imap [ACK] Seq=777846813 Ack=211069645 Win=5840 Len=0
     12 0.190907    192.168.1.12          192.168.1.2           IMAP    
Request: 1 login "office" "password"
     13 0.191026    192.168.1.2           192.168.1.12          TCP      imap >
32900 [ACK] Seq=211069645 Ack=777846841 Win=32120 Len=0
     14 0.208304    192.168.1.2           192.168.1.12          IMAP    
Response: 1 OK User logged in
     15 0.208468    192.168.1.12          192.168.1.2           TCP      32900 >
imap [ACK] Seq=777846841 Ack=211069666 Win=5840 Len=0
     16 0.259848    192.168.1.12          192.168.1.2           IMAP    
Request: 2 append "INBOX.INBOX^Sent" (\Seen) {423+}
     17 0.277487    192.168.1.2           192.168.1.12          TCP      imap >
32900 [ACK] Seq=211069666 Ack=777846885 Win=32120 Len=0
     18 0.277758    192.168.1.12          192.168.1.2           IMAP    
Request: Message-ID: <3DF5EB51.4060708@weisser-ring.at>
     19 0.278072    192.168.1.2           192.168.1.12          IMAP    
Response: 2 NO Mailbox does not exist
     20 0.278290    192.168.1.12          192.168.1.2           TCP      32900 >
imap [ACK] Seq=777847310 Ack=211069695 Win=5840 Len=0

Mozilla on 192.168.1.12 first requests a listing of INBOX.Sent, which is ok.
But on line 16, it tries to append to mailbox "INBOX.INBOX^Sent", which of
course does not exist, and hence the IMAP server responds with an error message.

So the question is, where does this strange name "INBOX.INBOX^Sent" come from?

I could reproduce this behaviour now several times, and Mozilla always tried to
use this strange mailbox name.

Andreas, try removing the server subdirectory INBOX. in your advanced imap
server settings. It's not needed, because your cyrus server supports the
namespace extension, as does Mozilla.
Thanks, we figured the trick with removing the IMAP server directory entry 5
minutes ago :-)

The problem with this solution is: Mozilla now shows the folder structure below
the "Inbox" folder, which confuses our users. Also special folders like "Sent"
or "Drafts" loose their special icon as soon as I remove the IMAP server
directory entry.

I'm also still wondering why Mozilla sometimes (not always!) uses such strange
folder names like "INBOX.INBOX^Sent" or "INBOX.INBOX^^Drafts" (yes, the problem
appears with the Drafts folder, too, as I just found in the TCP/IP traffic log).
Shouldn't this be considered as a bug?

Btw, I can reproduce the problem with mozilla-1.2.1 on Windows, too.


the "INBOX.INBOX^Sent" is due to bug 148043
I am experiencing similar problems.
If I do not have the Mail application open and I send an email by hitting either
a mailto: link or Ctrl+M to create a Mail Composition window and I am running
IMAP (uw-imap) I get this exact error 100% of the time without failure.
The email is sent using my localhost smtp server, but the IMAP dialog to save to
Sent folders fails.
I have never seen this under POP, POP-SSL.
I have (almost?) never seen this if I have the Mail application already open
(hence establishing an IMAP session with the server).

I suspect that the simple Mail Composer isn't running the overhead of the IMAP
session when it runs but is able to manage the local POP based file/folder updates.

Mozilla 1.3a - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

Having the "Copying message to Sent folder..." progress window appears to be
staying up for a very long time (after about an hour, I kill the app) is not
unusual (about 50% of the time) when I send messages while I am also in the
process of downloading (also via Mozilla) large amounts of data at the same time.

Switching to the Sent folder prior to the kill, a busy sign (large clock)
prevents any action in the Sent folder, but other folders can be viewed and
edited, and the browser does not appear to be affected at all, apart from the
slower download of web pages because I am already downloading a large app or two.

Checking the Sent folder using an external editor usually shows that the entire
mail has already been copied, but not always.  I have confirmed that the emails
sent so far have been received intact.

The Sent folder is local, and mail is being sent via POP.  No IMAP involved at all.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212

Exactly the same problem as Karl Scriba (94), this time on Win XP.
I also get the problem every time I send an email. The progress bar stays up
permanently or I get a dialog "Could not be copied. I also happens when I try
to save a draft.
For me  the problem seems to happen only on my ISDN connected client
(nightly build 20030131, Win2k)

The copy to the sent folder always fails if the ISDN line has disconnected so
the send has to trigger a new connestion to my IMAP server.

In older builds (several months ago) the problem occurred sometimes (not often)
when connected via leased line also. But I haven't seen this lately.

Hope this can be of any help.

/Mats-Olof Sander
Blocks: 193931
I too can confirm this is happening to me under Linux x86 Mozilla 1.3b with
UW-IMAPD. Didn't seem to occur (at least very often) in 1.2 or prior versions. I
happen to be using TLS over port 993 to access the IMAP server.
Is this the same issue as in Bug 191398?
*** Bug 191398 has been marked as a duplicate of this bug. ***
related: bug 123063, bug 163951
Summary: Copying sent mail to sent folder fails often → Often get "message was sent but copying to sent folder failed" error dialog
Me, too. This seems to be more likely to start happening when I have 
attachments, but it happens regardless.


I started having the problem at least as far back as 1.3a, and I see it on both 
W2ksp3 machines as well as my XP machine.


IMAP, I think using Kerberos for authentication (MIT).


The progress bar "Copying message to Sent folder" stays up forever. Sometimes it 
collapses to "The message was sent successfully, but could not be copied to the 
Sent folder. Would you like to return to the Compose window?"


While I had four messages up with their 'copying' progress bars, I created a few 
folders named "Sent-MMMYY" and started moving messages out of the Sent folder by 
date. The first two times I tried to move messages, one of the messages being 
sent went to the 'could not be copied' dialog box. But, I still have two up.

I have a similar problem:

I use an IMAP server only to share Maildirs between few clients on a LAN

Courier-IMAP Server on linux
clients: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

Coping sent messages in personal Sent folder works fine(IMAP namespace INBOX.).
Coping sent messages in Sent on a shared folder (IMAP namespace shared.) produce
ALWAYS the following message:

 The current command did no succeed. 
 The mail server responded: Invalid mailbox name

If I copy or move in this shared Sent folder dragging a message everything works
fine.
it happens 90% of the times in mozilla 1.4a. Although I was facing this problem
with older builds also, it is much more common in mozilla 1.4a.
forgot to mention in the earlier message, i am using it on RH9.
This is still happening in 1.4 Alpha. It's a big problem, and has been getting 
apparently more frequent with more recent builds. I used to be able to restart 
Mozilla and get the desired behavior, but now it doesn't copy to Drafts, either.



I think this is a dupe of 180706

Dupe of 71650?

I just installed the latest nightly build (April 15th 2003) and got this 
problem with my Fastmail IMAP account.  Here is what I did to fix it:

1) Went to advanced server properties and changed "IMAP Server Directory" 
from "INBOX." to blank (should be INBOX. for Fastmail)
2) Closed Mozilla
3) Moved my user.js to another folder (it has check all imap folders setting)
4) Edited my prefs.js and changed check all imap folders setting to false
5) Started up Mozilla, let the mozilla server/folder check do its thing
6) Shut down Mozilla
7) Started up Mozilla again and put the INBOX. setting back in
8) Shut Down, start up, shut it down again
9) Put my user.js file back into Mozilla folder

After all this, I don't have problems with messages being copied into my Sent 
or Drafts folder now.  Hope this helps.

PS: I'm not running quicklaunch
I don't seem to have a user.js file, nor does my prefs.js file has a check all 
IMAP folders setting.
Is there any fix or workaround for this bug now? I presume the posted one from 
last August has either been discarded or folded into Mozilla.
To add a little information, I'll sometimes get a "System I/O error" dialog box 
20 minutes or so after a message has hung sending.
This bit me again with the 4/17 build. The work-around is to make a new folder
for sent mail with a different name. Then it works again. So, I have to suspect
that the folder is getting corrupted.
Blocks: 200056
I am experiencing this bug in Mozilla on OpenVMS with one difference than what
is being reported on this bug report.

My sent folder is local, not over a network connection.

As an experiment, can those people that can reproduce this easily try setting
your sent folder to be a local folder, and see if the problem still exists?

If so, this would tend to eliminate it as a network related issue.
As mentioned in comment #94, the Sent folder was local.
The problem persists with 1.4a (Linux), and I am still using only local folders.
Yes, it happens with local folders (for me on Win2k) also. The workaround is to
make a new local folder (with a different name). Obviously, the folder is
getting corrupted. I now have 3 sent mail folders, only one of which can
actually accept sent mail. But I can read all of them.
You see this with local folders, I saw it with remote UW-IMAP folders (I still
haven't seen it in the last year, BTW, using 1.0.x), and other people (assuming
that it's the same bug they saw) saw it with a varity of other IMAP servers.
That kind of excludes a physical corruption of the mail file. Maybe Mozilla does
in some cases some havoc to the folder on the mail/header level and stumbles
over these later? Just a shot in the air... :(
mass re-assign.
Assignee: naving → sspitzer
Status: REOPENED → NEW
*** Bug 206408 has been marked as a duplicate of this bug. ***
Still happening with 1.5 Alpha.
This is due to the .msf file for sent mail being screwed up. If you delete
sent.msf, it will work again. For a while.
Since the .msf file rebuilds itasel, when the copy to the sent folder fails,
Mozilla should delete this file and rebuild it automatically. Or better yet, fix
the problems with .msf
these comments and questions are all about the local folders version of this
problem - the imap problems are different and imap-specific.

I don't believe the .msf file is getting corrupted in the sense of  database
corruption - if you can read mail in the sent folder, than the database is not
corrupt. It's more likely that some client code has stored a value in the
database that messes up the client code, like the name of the folder, or some
folder flags. Do the sent folders that don't work have the sent mail folder
icon, or the normal folder icon? Is it the case that it always fails for you on
the accounts that don't work? Or does it work a few times and then stop working,
until you shut down and restart?
I actually (at home) put all sent mail in a local sent mail folder. It gets
trashed regularly, and will not work again until I get rid of the .msf file.
I'll have to look at the icon the next time it screws up.

The last time it died, I was doing a few things at once I recall, but don't
recall what.
The sent folders that don't work have the sent mail folder icon, not the normal
folder icon.

The "copy to sent" always fails for me under the scenario described in #94 and I
can't access the Sent folder until I shut down and restart Mozilla.  No other
scenarios cause this behaviour for me.

Deleting the .msf file or not had no effect.  I combined this with running
"Compact Folders", but the Sent folder could still not be accessed until Mozilla
was stopped and restarted.
I am using an IMAP sent-mail folder in Mozilla 1.4.  I find that short of
restarting Mozilla, the only way to fix the problem is to choose "Work Offline"
from the File-->Offline menu, then uncheck it again.  Once I have gone off- and
back online, the sent-mail works again.  

Also, I find that this problem happens more often when the message contains an
attachment.  When it happens, I cannot read any of the messages in my sent-mail
folder, but once I go through the process listed above, I can read the sent-mail
folder again.
I've been bitten by this bug in every version of mozilla since 1.0 as far as I
can remember. I've seen it when I was using a pop3 account, and now I've moved
to IMAP , I still see it (on WinXP). I've been watching it for a while, but I'm
contributing now, because the dataloss issue just caused me a lot of problems. I
use my mail archive as my history, and it is important to my work that I can
track these things. I now have no record of an important mail I sent to a
client. This is embarrassing and unprofessional.

For a while, I worked around it by having mozilla configured to save to a local
folder, but now I use IMAP (and access my mail from multiple machines), this is
no longer an acceptable workaround.

I see there is at least a partial patch from (almost exactly) a year ago that
fixed it but then it regressed. 

This is a long-standing, critical and dataloss bug... Can we get it a little
more attention? or at least update the target milestone to something more realistic

Personally, I think this should have been a blocker for every release of mozilla
so far, can we make it one for 1.5?

>  I worked around it by having mozilla configured to

As a workaround, you can configure Mozilla to send a bcc to yourself. I did this
because of this bug, and this should work in any case.

> Can we get it a little more attention?

Not unless either
- you can help a developer to reproduce the bug on his own systems,
  preferably 100% (every time)
- you can track the problem down yourself and point to a certain code point and
  convincingly argue why that code is the culprit, so a another developer
  can fix it blindly.
I like to see something like this:

------------------------------------------------------
| Message was sent but copying to sent folder failed |
|
| [ Save to Sent Folder on Local Folders ] [ Cancel ]|
|-----------------------------------------------------

Yep, I knew about that workaround. I don't like it though, because as
accessibility impaired user who doesn't use a mouse, it screws the UI in the
addressee panel, and I end up bcc-ing everyone. I don't think that should be an
acceptable workaround though, at least not without a relnote to help people out.
This has been going on for years.

Is there anything I can do to instrument the browser to try and gather some
data? I'm willing to help if someone's willing to spend some time at least
answering questions to help me figure my way around the codebase.

I have (some) time to devote to this if I can help track and test, but I'm a
long way from being a coder (more a management drone these days :( ) I can't
reproduce the bug 100% of the time, because it doesn't occur 100% of the time.
Stefan, here's what you can do to help me here:

tell me what version of Mozilla you're using, and if it's not the today's trunk
1.5b build, try downloading the new build. (I fixed a recent regression
yesterday that caused some problems that might be related).

Try to figure out if there's any pattern to the occurrences of this bug that
might help diagnose it.

Generate an imap protocol log by following these instructions and when the bug
happens, attach or e-mail me the imap protocol log.

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

thx. - David
Assignee: sspitzer → bienvenu
Attached file IMAP log file — 
I just installed Mozilla 1.5b, and can easily recreate the bug by sending a
particular attachment to myself. I use IMAP with SSL at MIT. This bug has
occurred since Mozilla 1.3 on both the Windows and Tru64 OS's (1.2.1 was the
last release that worked for me), and it also occurs in Thunderbird 0.1.

To create the bug, I sent an Adobe Illustrator file to myself as an attachment.
The attachment is not particularly large, approx 130kb. The message is sent
fine and it is copied to the "Sent" folder on the IMAP server just fine, yet
the "Copying to Sent Folder" progress dialog remains active. If I cancel the
progress dialog, all appears well, except that I cannot list new messages in
any folders. Even after I close Mozilla with the "X", it remains active in the
Task Manager, and I cannot get new messages on any client on any computer until
I kill the Mozilla process.

I have attached the IMAP log.
thx, yeah, the append is never finishing. My guess is that this is a problem
with quoted printable, or something like that - the size of the message is
probably not what we're reporting to imap, so the append never finishes.
Status: NEW → ASSIGNED
Note that in the bug as I originally reported it, the Sent copy actually failed,
there was no copy at all.
Nicoli, can you look at your preferences and tell me what you see under
Navigator | Helper Applications, especially the adobe illustrator specific stuff?
ok. I've got an IMAP log with the problem reproduced. it took me a little while
to do it (which is what I normally see, the first x messages always send and
copy fine).

I was a bit heavy handed with the size of the attachments - trying to send a
small  message without an attachment while sending a large attachment seems to
be a good way to trigger it. 

(the IMAP log I have is too big to attach to the bug, but I can mail it...)

stef
Nicoli (and anyone else who is having this problem when sending attachments on
IMAP), can you try adding this to your prefs.js? This will force all attachments
to get sent as binary (base64 encoded). I believe that will fix the problem. I
believe there's something seriously wrong with our quoted printable handling -
comments in the code make me think it's a line-ending issue but it seems to me
we shouldn't be using it if it generates bad attachments or messages.

user_pref("mail.file_attach_binary", true);

That solved the problem I was having!
Don't know if this matters, but...
The size of the file I was trying to send was 183kb. For the buggy message, the
size of the email was reported by Mozilla to be 350kb. But for the one I just
sent, the message size has been reduced to 252kb.
yes, quoted printable really screws up everything, the size, the attachment
itself, everything...
what are the relative merits/demerits of the two mechanisms? could the solution
be to just change the default for that pref? what's the likely impact. I.e. is
this a fix, or another workaround while the quoted-printable code gets worked on.

(I've switched it on and am testing to see if I can reproduce). Nothing bad yet...
Stefan, I don't think this is going to fix the problem where you get two appends
going to the UW Sent folder, but it might fix it if you've also been the problem
Nicoli had. Your protocol log did not show the problem Nicoli was having.

The only advantage of QuotedPrintable that I can see from the comments in the
source is that if the recipient happens to not have a mime-aware e-mail client,
the message text can be more readable if it's quoted printable. This is not a
compelling argument to me, especially given how broken QP is. I'm looking at the
QP code to see if anything is obviously wrong, but I'd be happy to switch the
pref, or add a pref that says don't use QP ever, and default that to be true.
The pref I mentioned earlier also prevents other sorts of encoding that might
actually work, so we might want a new pref that just prevents QP.
Attached patch proposed fix — — Splinter Review 
this should fix most cases of the qp problem - there was some code that checked
if the attachment had > 10% unprintable characters, and if so, used binhex. But
it wasn't getting triggered because m_size was never set. So I set m_size when
we analyze the attachment.

This gets the code working like it used to. I think I'd also like to make
AnalyzeAttachment also detect if there are naked CR's or LF's, in which case qp
won't work. But this should be good enough for now.
I'd like to nominate the last patch for 1.4.x and 1.5b - it's a nasty bug, which
results in corrupt attachments getting sent out that can't be read by the
recipient.
Flags: blocking1.5b?
Flags: blocking1.4.x?
hmm... Today I sent out a smaller attachment, and the bug resurfaced (but the
attachment from yesterday still seems to go through OK with the work around in
place). This time the attachment was a 24kb Excel file. I've attached the log.
Comment on attachment 129695 [details] [diff] [review]
proposed fix

r/sr/a=sspitzer for 1.5 beta
Attachment #129695 - Flags: superreview+
Attachment #129695 - Flags: review+
Attachment #129695 - Flags: approval1.5b+
like to get this in by friday if we can so we can do 1.5 beta next week
David, 

I just noticed this other bug related to QP-related corruption, also marked up
for 1.5b, thought you might want to just check there's no crossed wires.

http://bugzilla.mozilla.org/show_bug.cgi?id=168098



Just a note: when I see this problem, most of the time it is a plain text email
without an attachment. 

Gerv

Stefan, thx, that's very helpful - I'll look at the other bug.

Gerv, we'll just try to deal with the causes of this problem one at a time. Are
you running 1.5b? Do you ever send two messages at a time?
it turns out that this fix does also fix bug 168098
bienvenu: I am running 20030816 at the moment on my Linux machine. I do
sometimes send multiple messages at once, and that can trigger this problem -
but I also see it when sending a single message.

Gerv
Attachment #129695 - Flags: approval1.4.x?
David, if this has landed, can you resolve this bug as fixed so that it's
obvious to drivers doing 1.4.x evaluations that it's landed on the trunk and was
verified as having fixed the problem? Thanks.
Flags: blocking1.5b?
OK, I'm going to mark this fixed. Let's please open new bugs for remaining cases
of this - this bug has too many very different problems all mixed together.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
What? You're going to resolve it fixed because it's still broken, but for 
multiple reasons?
I'm just reporting problems. I don't know what Mozilla is doing, just that it 
can not always copy my sent mail to the Sent mail folder. I can answer questions 
about what happens, or run diagnostic tools, but I can't categorize my bug 
reports by underlying cause.
No, you can't, but I can try. I was asked to mark this fixed so people can let
us know if it's fixed for them or not. I realize that it's still happening for
some people, but I think a new bug would be cleaner. For one thing, this bug is
about both IMAP and POP3, which obviously are going to have different causes.

Have you tried a recent build to see if it's still happening to you? Other
questions - do you get multiple sends going at the same time? And have you tried
generating an imap protocol log?

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
I don't think resolving this as fixed is a good idea. It will give potential
reporters the impression that mozilla just IS broken (for some undefined reason,
since it can't be THIS bug). Better to make this a META-bug. € 0.02
Comment on attachment 129695 [details] [diff] [review]
proposed fix

This is not going to make 1.4.1.  Please re-request aproval after 1.4.1 ships
if you'd like to get this in for 1.4.2.
Attachment #129695 - Flags: approval1.4.x? → approval1.4.x-
Flags: blocking1.4.1? → blocking1.4.1-
asking for 1.4.2 approval
Flags: blocking1.4.2?
Comment on attachment 129695 [details] [diff] [review]
proposed fix

I guess David wanted to ask for approval
Attachment #129695 - Flags: approval1.4.2?
Comment on attachment 129695 [details] [diff] [review]
proposed fix

please get this in fast
Attachment #129695 - Flags: approval1.4.2? → approval1.4.2+
Keywords: mozilla1.0, nsbeta1- → fixed1.4.2
Flags: blocking1.4.2?
OK, I'm getting something similar now, but it's bugged under 206408 and 250657
(In reply to comment #151)
> No, you can't, but I can try. I was asked to mark this fixed so people can let
> us know if it's fixed for them or not. I realize that it's still happening for
> some people, but I think a new bug would be cleaner. For one thing, this bug is
> about both IMAP and POP3, which obviously are going to have different causes.
> 
> Have you tried a recent build to see if it's still happening to you? Other
> questions - do you get multiple sends going at the same time? And have you tried
> generating an imap protocol log?
> 
> http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap


I have found lots of interesting things which might be of interest to you.

I run layers of protection: Panda Platimum 7 antivirus, Spybot, Adaware, &
PestPatrol. But what happens is that some day one viruses get into my E-mail on
Mozilla. Now the always on "Perminent Protection" will block access to a virus
found in my E-mail database. 

So the resulting effect is to choke Mozilla Mail.

The fix has been to run automated manual scans every night. If a virus is found,
then after it is deleted, teh index is now off compared to the proper place in
the database file.

Attempts to "Compact" the E-mail fail. So I have a simple batch file that simply
deletes all indicies. Next time Mozilla opens, everything is OK.

r.mcclintock@snet.net
This is STILL happening to me, and I believe it happened on a build later than 8/12.
It is hard to test because it occurs intermittently.
My sent folder is in local folders on Win XP SP2
This bug has never gone away entirely for me for larger messages.  The easiest
way to make it happen is to create an email with a *large* attachment and then
save it to drafts.  
Zach, I don't know if this is your situation, but there is/was a buggy version
of the Cyrus imap server at MIT. I had a long exchange with a Cyrus developer,
and his advice was to upgrade the server.
Bienvenu: any idea which server versions? And how would I find out the vendor
and version of my IMAP server?

Gerv
Gerv, you'd generate an imap protocol log and look at the greeting returned by
the server, at the top of the log. It was a cyrus server, 2.1.5. However, I
thought the problem you're seeing is that your imap server goes up and down and
we're not detecting that the connection has gone bad.
Bienvenu: not quite. I'll open a new bug describing my symptoms, rather than
re-using this one.

Gerv
Mozilla 1.7
Mozilla/5.0 (X11; U; OpenVMS AlphaServer_DS10_617_MHz; en-US; rv:1.7) Gecko/20040621

This bug is still present.  It seems to be triggered by a lot of pasting spam
sources into the spamcop.net parser window, and then also forwarding the spam to
uce@ftc.gov.

With the 1.5 released of Mozilla for OpenVMS, any acknoledgement to the dialog
box would crash the browser.

With 1.7, now acknowledging the box will usually hang the browser and mailnews
client.
Look also to the new bug about this:
http://bugzilla.mozilla.org/show_bug.cgi?id=196095
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: