1140308 - Garbled error message is shown when including a space in e-mail address, unclear whether or not it comes from the MTA

Status: RESOLVED DUPLICATE of bug 1140884

(MailNews Core :: Networking: SMTP, defect)

Description

[mdavids]

Attachment: Screen Shot 2015-03-06 at 09.17.56.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

Steps to reproduce:

Earlybird 38.0a2

Trying to send an e-mail to and address that accidentally contains a space, like:

testing@exampe.[space]nl

Then press send.


Actual results:

Weird error with Chinese characters. All garbage. 


Expected results:

A normal error, indicating the address is invalid.

Comment 1

[Wayne Mery (:wsmwk)]

This entire error text is what is being reported by your MTA (your ISP), not thunderbird.  The key is "the mail server responded".

Comment 2

[rsx11m]

Well, the interesting part here is that "Please check the message recipient [...] again" is corrupted too, not just the response to the server (if a request was ever sent). Thus, it would be good to know what was actually communicated with the server.

Bottom line: There still /may/ be an unchecked buffer somewhere causing or contributing to this issue.

Comment 3

[Wayne Mery (:wsmwk)]

True.

mdavids, you can reproduce this repeatedly?

Comment 4

[rsx11m]

Testing this with the gmail.com server while running NSPR logging shows that indeed the recipient is sent out literally and without quoting as "SMTP Send: RCPT TO:<test@example. com>"; so, that part seems already flawed given that a space shouldn't be allowed in a mailbox specification. Nevertheless, I can't reproduce the main issue, given that smtp.gmail.com actually accepts the message despite the broken recipient address but then returns then a Delivery Status Notification "Internal parse error: Illegal envelope To: address (invalid domain name)" instead.

mdavids, it would help if you can create an SMTP log of such a failed transaction. To do so, please open a command shell and enter the following commands while Thunderbird is not running:

export NSPR_LOG_MODULES=SMTP:5
export NSPR_LOG_FILE=smtp1140308.log
/Applications/Thunderbird.app

This should run Thunderbird and allows you to produce the error, then exit. It should have created a file "smtp1140308.log" with the log. You can edit it with any text editor and "xxx" over any information you don't want to be seen publicly (while this bug is currently hidden, it will become visible again later after resolving the issue).

Comment 5

[mdavids]

> mdavids, it would help if you can create an SMTP log

I don't get the error with Gmail. I do get it, repeatedly, when communicating with an Exchange server.
(but bear in mind: I use Earlybird 38.0a2 - I don't see the error with Thunderbird)

The difference is that Gmail seems to accept the message:

2109035264[10033d1a0]: SMTP Send: RCPT TO:<testing@example. nl>M
2109035264[10033d1a0]: SMTP entering state: 0
2109035264[10033d1a0]: SMTP Response: 250 2.1.5 OK m4sm14412902wik.20 - gsmtp

Exchanges refuses it:

2109035264[10053d1a0]: SMTP Send: RCPT TO:<testing@example. nl>M
2109035264[10053d1a0]: SMTP entering state: 0
2109035264[10053d1a0]: SMTP Response: 501 5.1.3 Invalid address

Comment 6

[mdavids]

Attachment: smtp1140308_gmail_modified.log

Comment 7

[mdavids]

Attachment: smtp1140308_exchange_modified.log

Comment 8

[rsx11m]

Comment on attachment 8574564 [details]
smtp1140308_exchange_modified.log

This looks unsuspicious and a proper 501 response, thus no clues here.

jcranmer, any way to reproduce the issue on a test/fake-server?
(probably tough without knowing the exact response...)

Comment 9

[mdavids]

Added a screenshot from 31.4.0, talking to the exact same Exchange server. It doesn't has the weird error.

Comment 10

[mdavids]

Attachment: Screen Shot 2015-03-09 at 14.17.45.png

Comment 11

[mdavids]

Comment on attachment 8574658 [details]
Screen Shot 2015-03-09 at 14.17.45.png

Thunderbird 31.4.0
(31.5.0 same behaviour)

Comment 12

[rsx11m]

It does show the bad parsing of the recipient field (here creating an empty "" string rather than the malformed address), thus an indication that something is going wrong here when building the dialog.

Comment 13

[Andrew McCreight [:mccr8]]

This sounds kind of bad, but it doesn't really seem exploitable. Feel free to adjust or remove if desired.

Comment 14

[Kent James (:rkent)]

No reason anymore for this to be security restricted.

Comment 15

[Kent James (:rkent)]

Removing tracking because this does not seem to be going anywhere.

Comment 16

[Magnus Melin [:mkmelin]]

This looks like bug 1140884. Tb 38 already got the fix.

Comment 17

[rsx11m]

Clearing obsolete request.