Closed Bug 47311 Opened 24 years ago Closed 5 years ago

Shouldn't just ignore server response (NO) when appending, for a server that does not support literal+ and the server immediately responds with an error

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1079280

People

(Reporter: bugzilla, Unassigned)

References

Details

Attachments

(1 file)

In bug 41504 it's describe what mozilla does when a IMAP append command fails.
Mozilla starts by sending:
append "t" (\Seen) {404}
The server responded: NO [TRYCREATE] The specified mailbox does not exist
Then mozilla tries to send data like:
Message-ID: <398801ED.3050706@dk.net>

This is bad!

Mozilla shouldn't send data when it recieves a NO response from the server. 
NO indicates failure!
Keywords: nsbeta3
Keywords: mail2
Henrik, what are the externally visible symptoms of this?  Would a regular user 
ever know?
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
The error message is shown, so the user see it as a error message.
It's just a IMAP protocol error to send data when the IMAP server says "NO"
In testing bug 47324, this bug will cause the user to be prompted with the 
password dialog!
Bad, bad bad...:(
Just did a little more investigation, cause this is really bad bad. Because 
Mozilla just send the entire message after the server response "BAD" the user is 
repeatally prompted with the "password" dialog. But it doesn't matter what the 
user enters since Mozilla just sends part of the message that it's encorrectly 
trying to append. I'll attach my IMAP log.

To reproduce:
Setup your send folder to folder test on you imap server. Now rename the folder 
to test2. Now send a mail. You'll get the error saying Your send operation when 
OK, want to open in Composer again. Say yes. Now press send again and everything 
seems to go wrong.
Attached file IMAP log...
Severity: normal → major
QA->me
QA Contact: lchiang → huang
sorry for the extra email. Removing mail2 keyword.
Keywords: mail2
Keywords: nsbeta3mail3
Whiteboard: [nsbeta3-]
adding keyword - we should fix this. 
marking nsbeta1+ and moving to mozilla0.8
Keywords: nsbeta1
Whiteboard: [nsbeta1+]
Target Milestone: Future → mozilla0.8
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
marking nsbeta1- and moving to future milestone.
Keywords: nsbeta1nsbeta1-
Whiteboard: [nsbeta1+] → [nsbeta1+ 2/13]
Target Milestone: mozilla0.9 → Future
getting off my nsbeta1+ radar
Whiteboard: [nsbeta1+ 2/13]
QA Contact: huang → gchan
What's the deal with this bug?  Seems to still be lurking in my latest nightly 
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040426).

I'm thinking my server isn't liking the LITERAL+ on the APPEND to the "Sent" 
folder after sending a message.  The server responds with a BAD and Mozilla 
babbles off the message anyway.  As an end user I couldn't see symptoms of 
that, but I believe it still violates the IMAP spec.  Short transcript yanked 
with ethereal follows:
-----------------------------------------------------------------
3 append "Sent" (\Seen) {398+}
3 BAD Argument given to APPEND when none expected
Message-ID: <408DB0CE.3090300@XXXXXXX.XXX>
Date: Mon, 26 Apr 2004 18:01:02 -0700
From: Alex Sanks <XXXX@XXXXXXX.XXX>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) 
Gecko/20040426
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  XXXX@XXXXX.XXX
Subject: sdfdsf
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

sdgfdgfd


Message-ID: BAD Command unrecognized: <408DB0CE.3090300@XXXXXXX.XXX>
Date: BAD Command unrecognized: MON,
From: BAD Command unrecognized: ALEX
User-Agent: BAD Command unrecognized: MOZILLA/5.0
X-Accept-Language: BAD Command unrecognized: EN-US,
MIME-Version: BAD Command unrecognized: 1.0
To: BAD Command unrecognized: XXXX@XXXXX.XXX
Subject: BAD Command unrecognized: SDFDSF
Content-Type: BAD Command unrecognized: TEXT/PLAIN;
Content-Transfer-Encoding: BAD Command unrecognized: 7BIT
* BAD Null command
sdgfdgfd BAD Missing command
* BAD Null command
* BAD Null command
4 logout
bugs don't magically get fixed
Assignee: mscott → ere
(In reply to comment #14)
> bugs don't magically get fixed

Understood.  It's just that it's marked as "major", but there's been no
discussion here in 3 years....(although I know you folks are busy working on
more important stuff)

That said, I looked a little closer into this and it turns out my server was
incorrectly reporting LITERAL+ capability (bad proxy on the firewall).  Looks
like in nsImapProtocol::UploadMessageFromFile(), status won't be checked between
the command and the message data if LITERAL+ is used and that sounds correct if
I'm interpretting RFC 2088 right.  So you can probably disregard my previous (I
can't comment on how things work on a BAD without LITERAL+)

Sorry about that.
Product: MailNews → Core
Product: Core → MailNews Core
Ere, do you still want assignee?
(STM there is a similar, newer bug out there, perhaps someone could check)
Status: NEW → ASSIGNED
QA Contact: grylchan → networking.imap
Assignee: emaijala+moz → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
Target Milestone: Future → ---
No longer blocks: 1079280
Depends on: 1079280
Does bug 1079280 indeed fix this report?
Flags: needinfo?(gds)
Yes, it fixes it but only for the exact case reported: append an email to a mailbox on a server that does not support literal+ and the server immediately responds with an error. The fix in bug 1079280 stops tb from going through the motions and uselessly uploading the whole email in vain.

However, the useless upload may not be able to be avoided when the server does support literal+. (I need to research this.) In that case there is no error notification either. Jorg has asked me to submit a new bug to address this.
Flags: needinfo?(gds)

Gene, thanks. Please file a new bug if you haven't already.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Summary: Shouldn't just ignore server response (NO) when appending → Shouldn't just ignore server response (NO) when appending, for a server that does not support literal+ and the server immediately responds with an error

I don't remember much about this at this time. I will set a NI flag to myself, assuming that's possible, and will come back to it.

Flags: needinfo?(gds)

(In reply to Wayne Mery (:wsmwk) from comment #19)

Gene, thanks. Please file a new bug if you haven't already.

I filed Bug 1484400 for the literal+ case with a patch. However, in it I concluded that it's not worth the effort since it only mildly helped in the case for Outlook imap server. I closed it with "WONTFIX".

Flags: needinfo?(gds)
You need to log in before you can comment on or make changes to this bug.