178672 - mailnews doesn't reliably honor userid and password settings for SMTP AUTH

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: SMTP, defect)

Description

[Jeff McAdams]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1

mailnews will prompt for a userid and password and/or use an already entered
userid and password when the SMTP server offers AUTH {...} in its EHLO response,
even if the UI is set to not use userid and password.

Note: When an SMTP server includes "AUTH" in its EHLO response, it is *NOT*
indicating that SMTP AUTH is *required*, only that it is *offered*.  The UI
should be reliably honored as an indication of when to use SMTP AUTH.

Reproducible: Always

Steps to Reproduce:
1.Set SMTP server to an SMTP server that offers AUTH in its EHLO response
2.Make sure that "Use name and password" in "Outgoing Server (SMTP) Settings" is
not set.
3.Send an email.

Actual Results:  
mailnews prompts user to enter a userid and password if one is not already
configured.  If a userid and password is already configured, SMTP AUTH is used
with that userid and password.

Expected Results:  
Not used SMTP AUTH at all.

Due to this long-standing bug in Mozilla, SMTP server operators (most notably
ISPs) frequently have to go to extreme convolutions to determine when to offer
SMTP AUTH, rather than the much simpler provision of just offering it all of the
time (which is the ideal).

Comment 1

[Shoshannah Forbes]

I just saw this on my OS9 Mac.
This bug prevents me from working around bug #195749 (the server I used there
can have non-auth as well, but due to this bug here I have no choice but to bump
in to that bug there)

Comment 2

[guanxi]

The report says,

"If a userid and password is already configured, SMTP AUTH is used
with that userid and password."

"already configured" where?  Under SMTP only, or will it use a POP or IMAP id &
pw if available?

I ask because I'm trying to assess its relationship to bug 195749.

Comment 3

[Jeff McAdams]

I'm not sure as I haven't tried using different authentication information for
POP, IMAP, and SMTP.  I would think it would be appropriate that seperate
authentication information should be possible, and the highest priority for use
of authentication information for a specific protocol would be the
authentication information configured on that protocol, possibly with a
fall-back to authentication information configured for other protocols if the
primary one fails?  (that last part is debatable whether it should be or not)

ie, if I SMTP auth info entered and enabled, then that info should be used for
SMTP connections over any auth info entered for IMAP or POP.  Perhaps, if the
SMTP auth info fails authentication, then we could fall back to the IMAP or POP
auth info...but I'm not sure that's a wise idea either.

Regardless...if the configuration UI doesn't have an indication that SMTP AUTH
should be used, then it shouldn't use it.

Perhaps if AUTH is offered, not used, and the mail is rejected for some reason
(most likely at RCPT time), then perhaps a dialog indicating the AUTH might be
needed to send the message and directing the user where and how to configure it?

Comment 4

[Wayne Mery (:wsmwk)]

Nikolay, Mehrali, do either of you have ability to test this?

Comment 5

[Parkhideh]

(In reply to Wayne Mery (:wsmwk) from comment #4)
> Nikolay, Mehrali, do either of you have ability to test this?

Wayne, Frankly I do not understand the issue; may be because I do not use mail with news or mail without password.

Comment 6

[Wayne Mery (:wsmwk)]

do you agree this no longer exists or is no longer correct?

Comment 7

[rsx11m]

I don't have an SMTP server available which fully corresponds to the environment in question (i.e., either they require no authentication but then won't offer AUTH to start with, or they offer AUTH but then they mean it). I've thus tested this by using an AUTH-enabled configuration but set "No authentication" in the SMTP preferences (STARTTLS still needed to be applied, though).

Authentication remained enabled for the IMAP part, thus to test any carry-over of credentials from one protocol to the other (which seems unlikely as those are treated fairly isolated from each other except for the mail.smtp.useMatchingHostNameServer and mail.smtp.useMatchingDomainServer settings.

I'm not using the password manager for either password.

The log indicates that "AUTH LOGIN" was stated by the server, but no credentials were actually sent. The server sent a corresponding "Authentication required" response, resulting in the message not being sent.

Thus, from what I can tell (provided that my testing scenario was sufficient) that's WFM with current release. But, maybe leave this open a bit longer for someone who can test in an exactly matching setup to verify that it's no longer reproducible.

Comment 8

[Wayne Mery (:wsmwk)]

WFM per comment 7.
If anyone disagrees, please list steps to reproduce