55351 - No way to enter a password for a SMTP server

Status: VERIFIED FIXED

(MailNews Core :: Networking: SMTP, defect, P3)

Description

[Igor]

1. Create a POP mail account.
2. When you enter the SMTP server name use an authenticating
server that does not use the same username and password as the
POP account.
3.  After the account is created choose Edit->Mail/News Account Settings.
4. Under Outgoing (SMTP) server select Always use name and password (The box
should be checked, and the smtp server Name should be the one entered when the
account was created.
5. Enter the Name used to log into the SMTP server.
6. Click OK
7. Compose a new message and send it.

Error- A box appears with the following message:

An error occured while sending mail.  The mail server responded: Remote
sending only allowed with authentication!. Please check the message recipients
and try again.

The message is not sent successfully.

The problem seems to be that the SMTP server takes a different password
than the POP server.  When sending a message with Netscape 4.75 with the same
settings, a window will appear with a box prompting the user for a password
for authenticating to the server if needed.  Currently mail does this for
retrieving messages from a POP server, but there doesn't seem to be
away to explicitly specify a password for an outgoing SMTP server.  This is
problematic especially for users that use an ISP's SMTP server for outgoing mail
but use a yahoo or other internet pop account.

Comment 1

[Ninoschka Baca]

Scott, what smtp server can I connect to that requires authentication to try and
reproduce this?

If I switch between a webmail and aol account then I am prompted with a password
dialog. I would like to try a generic smtp server authentication scenario.

Comment 2

[Scott MacGregor]

you should be able to make your netscape smtp server require authentication by
checking the checkbox in the account settings for your smtp server.

Comment 3

[Igor]

The SMTP Server that I'm using is mail.freeport.com They are a free internet
dial-up service here in Utah.  If you want to try their server you can create
a free account at www.freeport.com.

Comment 4

[Ninoschka Baca]

Attachment: SMTP Log

Comment 5

[Ninoschka Baca]

Adding 'rtm' since this should show a password dialog for SMTP Servers that 
support/require authentication.

Comment 6

[Ninoschka Baca]

Branch build 2000-10-05-09MN6: NT4
I reproduced the problem on NT. I already attached the SMTP log.

Comment 7

[Scott MacGregor]

The problem is that this server advertises itself as just a SMTP server and not
a ESMTP server.

So we never issue a EHLO command. The EHLO response lists the cabilities of the
server including the fact that they support AUTH=LOGIN.

Since we never issue it, we assume the server doesn't support auth=login so we
ignore the user's preference to use authentication on the server.

I telnet'ed to the server and it really is an ESMTP server. You can issue a EHLO
and get a response. The problem is that the server incorrectly represents itself
in the greeting.

jefft, do you have any suggestions on how we should handle this case?

Comment 8

[jefft]

The only solution is alway send ehlo command instead of just parsing out the 
greeting. This of course will break another bug we fixed a while back which 
stated that we always send ehlo command to a non ESMTP server. Either way we 
need to make a tradeoff. However, I prefer not fixing this bug. We might as well 
ask the system administrator of mail.freeport.com to chang their greetings.

Comment 9

[Ninoschka Baca]

Attachment: ACN/Earthlink checked

Comment 10

[Scott MacGregor]

Okay, with the second log file you attached, this earthlink server properly
advertises ESMPT. It doesn't support AUTH=LOGIN according to the EHLO response
though. And when you try to send the recipient with a domain outside of
earthlink they are failing with a 550 error code. So it sounds like a slightly
different problem.

Comment 11

[jefft]

I thought about it a little bit more. I think we should always send ehlo first 
instead of parsing the greeting to decide what kind of smtp server is that. 
Because some sever may have a completely innovated greeting without even a SMTP 
strig in it. Make such assumption is a big mistake. I think we should fix this 
bug and break the other.

Comment 12

[jefft]

I just checked with most of the SMTP related spec. No spec enforce the greeting 
should advertising whether the server is a ESMTP server or SMTP server. This 
is a big mistake on my part. So, I think we should revert what we have done in 
the past. We should alway send EHLO first. If the response is an error then we 
send HELO.

Comment 13

[jefft]

mscott, do you want me to take this?

Comment 14

[Scott MacGregor]

Sure Jeff. I can code review for ya...

Comment 15

[jefft]

Attachment: a fix

Comment 16

[scottputterman]

adding rtm need info.

Comment 17

[Scott MacGregor]

Jeff, if we get an error from the EHLO command we still fall back and issue a 
HELO right? As long as you tested that scenario too than sr=mscott

Comment 18

[jefft]

Yes, that's the way it should be. I don't remember which server is an old SMTP 
server but I did test under the debugger to force an error return from EHLO 
command. Adding rtm+....

Comment 19

[jefft]

Remove "need infor"... adding phil, selmer, scottip for rtm++

Comment 20

[Phil Peterson]

PDT marking [rtm++] for mail interop issue which worked in 4.x

Comment 21

[jefft]

Fix checked in for both branch and trunk.

Checking in nsSmtpProtocol.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp,v  <--  nsSmtpProtocol.
cpp
new revision: 1.89.4.1; previous revision: 1.89
done

Checking in nsSmtpProtocol.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsSmtpProtocol.cpp,v  <--  nsSmtpProtocol.
cpp
new revision: 1.90; previous revision: 1.89
done

Comment 22

[Daniel Bratell]

Which is the bug we break? Is it reopened?

Comment 23

[jefft]

Bug 18293.

Comment 24

[Ninoschka Baca]

Branch build 2000-10-11-09MN6: NT4, Linux 6.0, Mac 9.04
Fixed.

Adding keyword 'vtrunk' so this is checked in the trunk as well.

Comment 25

[Ninoschka Baca]

Build 2000-11-28-09: Win95
Verified Fixed on the trunk (removing 'vtrunk' from keywords).

Comment 26

[Ninoschka Baca]

Also checked Linux and Mac (build 2000-11-28-08) and both are working.