Receiving mail works fine, but.. Everytime I try to send or reply to mail, I get an error from my ISP: "Nice people say HELO first..."

What mozilla build are you using? Thanks...

Never mind...it probably doesn't matter. I just quickly searched through the smtp protocol code and we only issue EHLO. we don't attempt to issue the HELO command to the server.

Nightly Binary Build, downloaded today (11/8/99) around 3:00pm EST

cc'ing Jeff - I think he's an expert on this stuff :-)

The way it should work is: 1) first we try EHLO to see if the server is a ESMTP server, 2) if it failed we send HELO, because it's not an ESMTP server, instead a legacy SMTP server.

Another thing to check is we need to cache the smtp capability somewhere so that we don't have to query the server each time we connect to it.

Mail Review recommends beta2 stopper. Adding nsbeta2 keyword.

rodzilla, could you retest on this one? I believe this should be fixed by now.

Putting on [nsbeta2+] radar for beta2 fix.

I just inspected the code and we do the same thing 4.x used to do. We first issue an EHLO command if that fails then we fall back to HELO. Rodney, if you try to send mail using communicator 4.x do you get the same message?

I'll take this one.

I have a fix for this plus caching the server capability.

fix checked in.

Rodney - is this fixed for you in the latest builds now? Thanks.

Rodney, this is an old bug, fixed for some time. Marking Verified. Please reopen if still a problem. you can get latest daily bits at: http://ftp.mozilla.org/pub/mozilla/nightly/latest/

Reopening due to the fix of bug 55351 ... And this probably will never get fixed ...

Checking the greeting string to figure out whether it's an SMTP or ESMTP is a bad thing to do. There is no requirement for any SMTP server implementation to include either ESMTP or SMTP string in their greeting. One can put any kind of strings in their greeting. Getting a server to return an error message saying about "not receiving 'HELO' command first" is not a catastrophe.

The client should be suppressing the error message it gets from EHLO, only showing an error message it gets from the fallback HELO.

From looking the code, I believe we always do that. Unless the user turned on SMTP authentication check by setting the mail.smtpserver.smtp1.auth_method other than default value - 0 (no auth).

reassigning jefft's bugs to naving

This bug was marked to be fixed in a previous milestone but it didn't get fixed properly. Nominated for beta1.

marking nsbeta1-

Milestone 0.8 has been released. We should either resolve this bug or update its milestone.

Clearing very old milestone (M17) in hope of reevaluation.

over to mscott who is more familiar with smtp code and can fix this in no time, if the problem still exists.

As we always issue EHLO and subsequently HELO on an error, I believe this bug is really fixed (see also bug 55351 for more info). I propose to close this one as fixed...

This bug still exist??? This isn't working now????

Christian, do you know if this is fixed?

Yes, I'm sure this is fixed. We're trying EHLO first. And as long as the server answers with the right error code as per RFC (>=500 && <500) we have no problem falling back to HELO.

Hm... Is it fixed in 1.6 ?... I don't see it: Received: from kraft-s.ru (asy.kraft-s.ru [213.156.193.5]) by srv10.kraft-s.ru (8.12.8p2/8.12.8) with ESMTP id i1J72VeQ004059 for <asy@kraft-s.ru>; Thu, 19 Feb 2004 11:02:41 +0400 Message-ID: <40345EE5.5030603@kraft-s.ru> Date: Thu, 19 Feb 2004 10:59:49 +0400 From: ASY <asy@kraft-s.ru> User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.6) Gecko/20040213 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: asy@kraft-s.ru Subject: test Sendmail write HELO values in Received. I see what HELO (kraft-s.ru) is not FQDN of 213.156.193.5. FQDN is asy.kraft-s.ru. Please see RFC2821: 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully-qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. y The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. I tested it with Alt Linux Mozilla 1.6 package.

What you're writing about is bug 68877. This one is about the server doesn't get an HELO (with just any parameter) at all.