Closed Bug 1650626 Opened 4 years ago Closed 3 years ago

A dot is added to the end of messages received from outlook.office365.com using POP

Categories

(MailNews Core :: Networking: POP, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 196584

People

(Reporter: earlgreypicard, Unassigned)

References

Details

Attachments

(1 file)

original and received message.jpg
172.04 KB, image/jpeg
Details

User Agent:
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Overview:

A terminating dot is displayed without being discarded at the end of a message received from outlook.office365.com using POP.
In case of IMAP it is not displayed.
No problem with other e-mail clients.

Steps to reproduce:

  1. Set up a POP account for outlook.office365.com.
  2. Compose a plain-text message to yourself.
  3. Send it.
  4. Receive it and see last line.

Actual results:

A dot is added at the end of the message.

Expected results:

No dot is added at the end of the message.

Additional Information:

Message body

.
..
...

Protocol log (MOZ_LOG=timestamp,POP3:5)

  • In case of outlook.office365.com via POP
2020-07-05 08:49:18.435000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: 

2020-07-05 08:49:18.435000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: ..

2020-07-05 08:49:18.435000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: ...

2020-07-05 08:49:18.435000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: ....

2020-07-05 08:49:18.435000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: (null)
2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] Entering NET_ProcessPop3 3
2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] Entering state: 19
2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: .

2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] RECV: (null)
2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] Entering state: 15
2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: D/POP3 sink: [this=2EC28700] Calling ReleaseFolderLock from EndMailDelivery
2020-07-05 08:49:18.472000 UTC - [(null) 5296: Main Thread]: D/POP3 sink: [this=2EC28700] ReleaseFolderLock haveSemaphore = TRUE
2020-07-05 08:49:18.488000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] Entering state: 22
2020-07-05 08:49:18.488000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF190] SEND: QUIT
  • In case of other server via POP
2020-07-05 08:48:56.837000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] RECV: 

2020-07-05 08:48:56.837000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] RECV: ..

2020-07-05 08:48:56.837000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] RECV: ...

2020-07-05 08:48:56.837000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] RECV: ....

2020-07-05 08:48:56.837000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] RECV: .

2020-07-05 08:48:56.853000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] RECV: (null)
2020-07-05 08:48:56.853000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] Entering state: 15
2020-07-05 08:48:56.868000 UTC - [(null) 5296: Main Thread]: D/POP3 sink: [this=2EC4B280] Calling ReleaseFolderLock from EndMailDelivery
2020-07-05 08:48:56.868000 UTC - [(null) 5296: Main Thread]: D/POP3 sink: [this=2EC4B280] ReleaseFolderLock haveSemaphore = TRUE
2020-07-05 08:48:56.884000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] Entering state: 22
2020-07-05 08:48:56.884000 UTC - [(null) 5296: Main Thread]: I/POP3 [this=109AF580] SEND: QUIT

What version are you using?

Component: Untriaged → Networking: POP
Product: Thunderbird → MailNews Core

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

What version are you using?

Thank you for triaging.
As shown in user-agent, it's happening in Thunderbird 68.10.0.
I just tried it and it reproduced with 3.1.20 and 80.0a1 (build ID 20200711001911).

This bug can be reproduced using a free Outlook.com account.
I believe the direct cause is on the outlook.office365.com side.
According to the log, (null) is detected before reading the last dot.
As a result, it goes back to state 19, which seems to read the last dot and append.

I've noticed a difference between outlook.office365.com and other POP servers in the first line of the RETR command response.
In the case of other server via POP, for example:

2020-07-04 19:44:23.600000 UTC - [(null) 3092: Main Thread]: I/POP3 [this=2353E430] SEND: RETR 180

2020-07-04 19:44:23.816000 UTC - [(null) 3092: Main Thread]: I/POP3 [this=2353E430] Entering NET_ProcessPop3 5346
2020-07-04 19:44:23.816000 UTC - [(null) 3092: Main Thread]: I/POP3 [this=2353E430] Entering state: 3
2020-07-04 19:44:23.816000 UTC - [(null) 3092: Main Thread]: I/POP3 [this=2353E430] RECV: +OK 5247 octets.
2020-07-04 19:44:23.816000 UTC - [(null) 3092: Main Thread]: I/POP3 [this=2353E430] Entering state: 19

In the case of outlook.office365.com via POP, the response is only +OK.

2020-07-04 19:22:25.610000 UTC - [(null) 7176: Main Thread]: I/POP3 [this=239AF040] SEND: RETR 639

2020-07-04 19:22:25.664000 UTC - [(null) 7176: Main Thread]: I/POP3 [this=239AF040] Entering NET_ProcessPop3 5
2020-07-04 19:22:25.664000 UTC - [(null) 7176: Main Thread]: I/POP3 [this=239AF040] Entering state: 3
2020-07-04 19:22:25.664000 UTC - [(null) 7176: Main Thread]: I/POP3 [this=239AF040] RECV: +OK
2020-07-04 19:22:25.664000 UTC - [(null) 7176: Main Thread]: I/POP3 [this=239AF040] Entering state: 19

How does Thunderbird work if no octet count is given?

perhaps nomis101 can help

Version: unspecified → 68

This bug occurs in all versions of Thunderbird.

TB1.0 TB3.1.20 TB10.0.9 TB31.8.0 TB52.9.1 TB68.10.0 TB78.0.1 TB79.0b2 TB80.0a1 Win10 Mail Sylpheed Becky! EdMax
bad bad bad bad bad bad bad bad bad good good good good

ping: nomis101 (instead of comment 5)

Flags: needinfo?(Nomis101)

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

perhaps nomis101 can help

I would love to, but I don't use outlook.office365.com, so it's tricky for me to reproduce.

Flags: needinfo?(Nomis101)

(In reply to Nomis101 from comment #8)

I would love to, but I don't use outlook.office365.com, so it's tricky for me to reproduce.

Maybe you can reproduce it by creating a free account at outlook.com.

The following settings are required for Outlook.com to accept POP.

  1. Select Settings > View all Outlook settings > Mail > Sync email.
  2. Under POP and IMAP, select Yes under Let devices and apps use POP.
  3. Select Save.

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

perhaps nomis101 can help

The steps to reproduce this bug are simple, anyone can get an Outlook.com account for free, and it's 100% reproducible.
Would anyone please just check the reproduction of this bug?

(In reply to EarlgreyTea from comment #11)

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

perhaps nomis101 can help

The steps to reproduce this bug are simple, anyone can get an Outlook.com account for free, and it's 100% reproducible.
Would anyone please just check the reproduction of this bug?

It seems to me it is not that simple. I now opened two outlook.com accounts to send emails from Thunderbird (78.1.0, macOS) . But TB always tells me my Password is wrong. It is not. So, I opened another Outlook.com account, checked the password twice and did set it up without a password in Thunderbird. After sending the plain text message from that account and entering the password I always get the same error message.

Fehler beim Senden der Nachricht. Der Mail-Server antwortete: 554 5.2.0 STOREDRV.Submission.Exception:OutboundSpamException; Failed to process message due to a permanent exception with message WASCL UserAction verdict is not None. Actual verdict is HipNotify, ShowTierUpgrade. OutboundSpamException: WASCL UserAction verdict is not None. Actual verdict is HipNotify, ShowTierUpgrade. [Hostname=AM6PR04MB4183.eurprd04.prod.outlook.com]. Bitte überprüfen Sie die Nachricht und wiederholen Sie den Vorgang.

So, sorry. I'm not able to test and reproduce this. Maybe somebody other has more luck.

(In reply to Nomis101 from comment #12)

I'm visiting an Outlook.com site for the US via VPN to create an account and use it to see this bug reproduced.
But I'm sorry. I haven't tried Outlook.com for Germany so I'm not sure.
In the case of Outlook.com for the US, when sending a message for the first time, I had to pass some tests to prove that "I'm not a robot".
These tests are puzzles of reorienting images and selecting images in the right orientation.
This means that you must open Outlook.com in your web browser and send messages before you can send it using Thunderbird.

However, sending a message from Thunderbird is not required to reproduce this bug.
Please send a message from another email address and try receiving the message with Thunderbird.

(In reply to EarlgreyTea from comment #11)

Would anyone please just check the reproduction of this bug?
Yes, I can confirm this behavior with outlook.com.

The Server delivers the wrong message size in the LIST response.

This is a well known issue. See: Bug 97912, Bug 196584 and so on...

Bug 196584 Comment 3 mentions a Workaround:
(In reply to Tom Sommer from comment #3)

Try setting user_pref("mail.server.default.dot_fix", false); in your user.js
(this will fix only newly received mails)

Yes, that works for me.

(In reply to Alfred Peters from comment #14)

(In reply to Tom Sommer from Bug 196584 comment #3)

Try setting user_pref("mail.server.default.dot_fix", false); in your user.js

I couldn't find a description, what the purpose of this Pref is. But if I should guess, I would say it's a workaround for servers that don't double the dots inside of a normal message body.

Since servers with this error should rarely occur today, I think it is a good idea to change the default of this pref to false.

Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 97912, 196584

(In reply to Alfred Peters from comment #14)

Bug 196584 Comment 3 mentions a Workaround:
(In reply to Tom Sommer from comment #3)

Try setting user_pref("mail.server.default.dot_fix", false); in your user.js
(this will fix only newly received mails)

I also tried it and confirmed that the dot was not added to the received email.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
See Also: 196584 →
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: