Closed Bug 383719 Opened 17 years ago Closed 3 years ago

Doesn't abort sending when 535 Authentication failed

Categories

(MailNews Core :: Networking: SMTP, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: mozilla, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Build Identifier: 2.0.0.0 (20070326) When sending an e-mail and typing a wrong password for the SMTP authentication, Thunderbird doesn't stop sending when 535 Authentication failed occurs. Even when the server closes the session, Thunderbird sends a mail from: < 220 Jana-Server ESMTP Service ready > EHLO [192.168.0.5] < 250-Jana-Server < 250-AUTH LOGIN CRAM-MD5 PLAIN < 250-AUTH=LOGIN CRAM-MD5 PLAIN < 250-STARTTLS < 250 HELP > AUTH CRAM-MD5 < 334 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX== > YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY== < 535 Authentication failed. > AUTH PLAIN ZZZZZZZZZZZZZZZZZZZZZZ < 221 Jana-Server Service closing transmission channel > MAIL FROM:<asdf@asdf.com> Reproducible: Always Steps to Reproduce: 1. Compose a mail and click on send 2. type a wrong password Actual Results: A universal error-message appears "Senden der Nachricht fehlgeschlagen ..." Expected Results: A input box should appear, to type the correct password in.
Component: Message Compose Window → Networking: SMTP
Product: Thunderbird → Core
QA Contact: message-compose → networking.smtp
Not stopping on error is by design. In this case every mechanism supported by the server is tried and the password isn't requested again until the last mechanism failed. You're not getting this far since the server disconnects before. While I agree that our behaviour isn't optimal (though needed to succeed with other servers), it's allowed. The behaviour of the server on the other hand is a clear violation of RFC 2821, chapter 3.9. So I'm inclined to close this as WONTFIX.
"AUTH CRAM-MD5" version of Bug 428611. Bug 428611 : CAPA => SASL PLAIN LOGIN AUTH PLAIN => -ERR => Server disconnects => wait for AUTH LOGIN response forever Bug 429069 is for phenomenon when similar situation but no other way to try. CAPA => USER USER (& PASS) => -ERR => Server disconnects => wait for CAPA response forever When Bug 428611, no chance to enter correct password until restart. I think improvement is needed even though server side RFC 2821 violation.
Note: Bug 428611 & Bug 429069 are POP3 cases, but same problem as this bug is involved.
Product: Core → MailNews Core

Version 91 has all new smtp backend code. If you can still reproduce this issue, please file a new bug report https://bugzilla.mozilla.org/enter_bug.cgi?product=MailNews%20Core&component=Networking%3A%20SMTP

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.