Closed Bug 18293 Opened 25 years ago Closed 21 years ago

My ISP complains about not receiving a "HELO" command first...

Categories

(MailNews Core :: Networking, defect, P3)

Product:
MailNews Core
Component:
Networking
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: rodzilla, Assigned: mscott)

References

Details

(Keywords: verifyme, Whiteboard: [nsbeta2+])

Attachments

(1 file)

A fix plus caching server capability
15.28 KB, patch
Details | Diff | Splinter Review 
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
Target Milestone: M14
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.
Target Milestone: M14 → M17
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.
Keywords: nsbeta2
rodzilla, could you retest on this one? I believe this should be fixed by now.
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
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.
Assignee: mscott → jefft
I have a fix for this plus caching the server capability.
Status: NEW → ASSIGNED
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Rodney - is this fixed for you in the latest builds now?  Thanks.
Keywords: verifyme
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/
Status: RESOLVED → VERIFIED
Reopening due to the fix of bug 55351 ... And this probably will never get fixed ...
Blocks: 55351
Status: VERIFIED → REOPENED
Resolution: 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
Assignee: jefft → naving
Status: REOPENED → NEW
This bug was marked to be fixed in a previous milestone but it didn't get fixed 
properly. Nominated for beta1.
Keywords: nsbeta1
marking nsbeta1-
Keywords: nsbeta1 → 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.
Target Milestone: M17 → ---
over to mscott who is more familiar with smtp code and can fix this in 
no time, if the problem still exists.
Assignee: naving → mscott
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...
QA Contact: lchiang → nobody
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.
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → FIXED
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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: