462866 - Error: Invalid MAIL extension (SIZE=0) on return receipt

Status: RESOLVED FIXED

(MailNews Core :: Networking: SMTP, defect)

Description

[Michael Baffoni]

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b2pre) Gecko/20081028 Shredder/3.0b1pre

Mail server (IMAP): Netscape Server 4.7

Steps to reproduce:
1) Receive an email requesting a return receipt
2) Select email to read.
3) If requested, allow return receipt

Expected results:
4) Return receipt should be sent acknowledging opening email

Actual results:

4) Two error dialogs are presented.
   4a) "An error occurred while sending mail. The mail server responded:  Invalid MAIL extension (SIZE=0).  Please verify that your email address is correct in your Mail preferences and try again."
   4b) On a dialog box titled "Send Message Error", I get the error "THIS IS JUST A PLACEHOLDER.  YOU SHOULD NEVER SEE THIS STRING."

I get this on every return receipt acknowledgement, but not on any normal email send.

Comment 1

[Mark Banner (:standard8)]

This works for me using imap with my isp.

Could you get a protocol log so that we can see what is going on with the messages? https://wiki.mozilla.org/MailNews:Logging details how to do this.

Comment 2

[Michael Baffoni]

Attachment: IMAP Protocol log for login, then read of email asking for return receipt.

This is a zip of the IMAP log, level 5.

Comment 3

[Magnus Melin [:mkmelin]]

Michael, since it's an error with sending, it's the SMTP log we want.

Comment 4

[Michael Baffoni]

Attachment: SMTP log during occurence (3rd sent email, sorry)

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> SMTP log during occurrence

> 0[29f4ae8]: SMTP Send: MAIL FROM:<[e-mail]> SIZE=0
> 0[29f4ae8]: SMTP Response: 555 Invalid MAIL extension (SIZE=0)

"Message Size" extension is defined by RFC 1870.
> http://www.faqs.org/rfcs/rfc1870.html

(1) Syntactically, SIZE=0 on "MAIL FROM:" is absolutely valid.
    If based on this rule, "555" can be said as "incorrect reply code".

(2) Semantically (from normal language view), "SIZE=0" is improper, because "SIZE=" on "MAIL FROM:" is defined as estimated size of message.
> 5.  Definitions
>(snip)
>   The declared message size is defined as a client's estimate of the
>   message size for a particular message.

(3) Mathematically, "estimated size==ZERO" should be accepted or cared.

(4) From programing view, rejection of "SIZE=0" on "MAIL FROM:" looks for me to be going over the edge, because usage of the "SIZE=" value on "MAIL FROM:" is limited for size limitation check.
> RFC says;
>   NOTE: Servers MUST NOT use the SIZE parameter to determine end of
>   content in the DATA command.

However, since SIZE= parameter on "MAIL FROM:" is optional, I think "SIZE=0 on MAIL FROM:" is better to be avoided by Thunderbird. 

Note: ZERO size value provided by SMTP server in EHLO keywrds is VALID, because ZERO is defined as "no size limitation".
>    (3) one optional parameter is allowed with this EHLO keyword value, a
>       decimal number indicating the fixed maximum message size in bytes
>       that the server will accept.
>(snip)
>       A parameter value of 0 (zero) indicates that no fixed maximum
>       message size is in force.

Comment 6

[Magnus Melin [:mkmelin]]

I don't think we'd block beta1 for this. 
BTW, did it work with thunderbird2?

Does look a bit like (also) a server bug to me. Though of course we shouldn't say the recepit is 0 bytes either...

Comment 7

[Michael Baffoni]

Return receipts work normally on this server using Thunderbird2.

Comment 9

[WADA:World Anti-bad-Duping Agency]

FYI. Bug opener of DUP'ed Bug 473382 also says; (Bug 473382 Comment #8) 
> Works flawlessly with TB2. Same server and config.

Comment 10

[Miguel A. Garcia]

I have seen the same bug, which I never saw on Thunderbird 2.0.

The server here is Microsoft Exchange. In SMTP it identifies itself as :
Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830

I have noticed that the error is also related to the SIZE=0. The original e-mail was sent with an Outlook client (I am not sure if this is relevant).

/Miguel

Comment 11

[Michael Baffoni]

I see this with Blackberry returns, and Outlook clients.  I'd imagine all clients requesting return receipts with this client and server combination requesting read (not delivery) receipts will get the same error.

Comment 12

[Michael Edenfield]

Just another confirmation that this used to work with Thunderbird 2 and subsequently breaks in 3.0b.  Same sender, same server software, etc. as previously.  I'm connecting to:

220 mail.*****.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Tue, 3 Feb 2009 13:32:28 -0500 

and in this case MS is explicitly saying:

MAIL FROM:<medenfield@*****.com> SIZE=0
501 5.5.4 Invalid arguments

Comment 14

[Mark Banner (:standard8)]

I think the question here is why are we setting the size to zero. I've just looked at the code, and unless we're trying to send a zero size message, or we've messed up somewhere, I wouldn't expect the size to be zero.

Can someone attach an example message saved as .eml (or email me one) which when allowing the return receipt causes this error?

Comment 15

[Michael Edenfield]

Attachment: Email requesting return receipt which causes error

Comment 16

[Luke G.]

I'm in agreement with Mr. Banner...am I reading too much into it to suggest we...

if (size==0) {
  size++;
}

?  Seriously.  When will we ever send a legitimate zero-sized message?  I've had to reject sending notifications for a month and a half because of what seems to me like a simple, logical omission.  Is it possible for me to check out the source code and key in my three line fix?

Comment 17

[Ludovic Hirlimann [:Usul]]

(In reply to comment #16)
> seems to me like a simple, logical omission.  Is it possible for me to check
> out the source code and key in my three line fix?

https://developer.mozilla.org/en/comm-central are the instructions patches are welcomed.

Comment 18

[Luke G.]

Got it!  I finally was able to build TB on my system and have verified that my fix idea works and allows read receipts to be sent as intended.  But, now what?  How do I submit the changed source file?  

I read something about a code freeze coming right up, and as an enterprise user I can't justify TB to others or even try to convince my management to let me use it for others if it would continue to barf on such a thing as sending read receipts!  >_<

Sorry to be a newbie at this, but I want to make sure I do this the right way so that my efforts will be beneficial and not mess something up instead.

Comment 19

[Ludovic Hirlimann [:Usul]]

(In reply to comment #18)
> Got it!  I finally was able to build TB on my system and have verified that my
> fix idea works and allows read receipts to be sent as intended.  But, now what?
>  How do I submit the changed source file?  

you need to check out the source code using mercurial (
https://developer.mozilla.org/en/Comm-central_source_code_(Mercurial) ).

You need to provide diffs using the hg diff command, attach it to the bug and request review ( see http://www.mozilla.org/hacking/reviewers.html ). Address comment and review and if it works/fits etc ... it will end up into thunderbird.

Comment 20

[Luke G.]

Attachment: patch to nsSmtpProtocol.cpp

This is my proposed patch!

Comment 21

[Mark Banner (:standard8)]

Hmm, I'm sorry I've not got back to this earlier.

I still think we should be understanding *why* m_totalMessageSize is zero, not just wallpapering around it.

There seems to be two possibilities:

1) The protocol isn't being given a file to send (is there a string buffer we send to?
2) The file for the receipt being sent is empty, i.e. we're trying to send an empty message.

The second option is an error condition, which we should be handling, not hiding.

The first would be a simple coding error where we should be able to get the size of the string buffer.

Comment 22

[David :Bienvenu]

I agree with Mark - if the size is really 0, then we're not sending the receipt, and that's a bug.

Comment 23

[David :Bienvenu]

Comment on attachment 374901 [details] [diff] [review]
patch to nsSmtpProtocol.cpp

we need to figure out why the total message size is 0. Is there some way I can reproduce this bug?

Comment 24

[Mehmet Tahir SANDIKKAYA]

See bug 472868

Comment 25

[David :Bienvenu]

thx, that bug seems to be more useful as far as reproducing this is concerned. My guess is that we're bailing out creating the return receipt message at some point...

Comment 26

[Luke G.]

David,

When I applied my patch to force it to at least size=1, it *did* send a legitimate receipt (it wasn't bailing out).  The only failure is the size=0 which Exchange gripes on.  If we figure out why the zero size and fix it, we will be perfect.

You should be able to reproduce this on any Exchange 2003 system.  Even telnetting into SMTP on it and trying SIZE=0 causes the error.  I have such a system four feet from me if you need any additional info.

Comment 27

[David :Bienvenu]

heh, ok, I see the problem - I think this means return receipts are broken with any server that doesn't like size == 0. I think the issue is that nsILocalFile caches its size, so we need to clone the file after changing it. Thx, Luke, I should have a patch for you to try in a few minutes.

Comment 28

[David :Bienvenu]

Attachment: proposed fix

cloning the file object will make us get the file size from disk.

Luke, could you try this patch without the prev patch to see if this patch fixes the issue by itself?

I'm not sure why the return receipt case specifically causes this problem - maybe we set the post message file earlier in the process of return receipts, when it's still 0 size.

Comment 29

[Luke G.]

I've applied the patch and just started compiling now, so I should know by tomorrow morning if this fixes our issue!  :)

Comment 30

[David :Bienvenu]

great, Luke, thx for testing this.

Comment 31

[Luke G.]

Your patch worked perfectly!  I both tested and verified that the receipt was sent.  Good job, thanks for fixing this!

Comment 32

[Mark Banner (:standard8)]

Comment on attachment 375825 [details] [diff] [review]
proposed fix

Windows only problem I see ;-) This fixes it when I tested on my VM.

Would it be worth just a brief comment as to why we clone it? So that someone doesn't take it out later without realising.

r/sr=Standard8

Comment 33

[Luke G.]

As far as this being Windows only: Knowing the direct cause of the error message (Exchange barfs on SIZE=0 and denies the message on SMTP), I would have to say that it would be reasonable to me to conclude that this *does* occur just as readily when using TB in Linux to connect to an Exchange server.  I did not take the time to configure TB on my Linux @ home to test this, but still...SMTP connection...Exchange's response...the problem is not at the OS level...right?  

Or are you saying that on Linux systems there would not be the condition where size would be zero?

If we're not sure, then again, this is a failure I could verify personally if I need to.

And, yes, from having to support lots of legacy stuff, I agree that a decent comment would be fantastic.  :)

Comment 34

[Mark Banner (:standard8)]

(In reply to comment #33)
> As far as this being Windows only: Knowing the direct cause of the error
> message (Exchange barfs on SIZE=0 and denies the message on SMTP), I would have
> to say that it would be reasonable to me to conclude that this *does* occur
> just as readily when using TB in Linux to connect to an Exchange server.  I did
> not take the time to configure TB on my Linux @ home to test this, but
> still...SMTP connection...Exchange's response...the problem is not at the OS
> level...right?  

It could happen on linux, but I didn't actually check.

The "issue" is with the platform-dependent implementations of nsILocalFile - the windows version caches the size of a file, the mac version doesn't (hence on my Mac I couldn't see the bug). Not sure about Linux, but I think we've come across this sort of windows-only problem before.

Comment 35

[David :Bienvenu]

yes, I was thinking a comment would be good.

I can't remember if our linux nsILocalFile code has the size caching issue or not

Comment 36

[David :Bienvenu]

fix checked in.

Comment 37

[Magnus Melin [:mkmelin]]

Size caching shouldn't be an issue on linux anymore (bug 456435). The windows bug should be bug 456603.