Bug 108753 - Get MAIL FROM error sending mail
Summary: Get MAIL FROM error sending mail
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution   
(Show other bugs)
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Matthew Barnes
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-01 00:42 UTC by Don Russell
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-11 03:56:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/hosts file (60 bytes, text/plain)
2003-11-04 02:21 UTC, Don Russell
no flags Details

Description Don Russell 2003-11-01 00:42:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
Whenever I try to send mail, I get an error that says MAIL FROM error
response: unknown.

The mail item remains in the outbox.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a new mail messgae
2. Press "send"

Actual Results:  An error pop-up saying an error occurred. Exact text is:

Error while performing operation.
MAIL FROM response error: unknown

Expected Results:  I expected the mail message to be sent successfully.

Additional info:

Using CAMEL_VERBOSE_DEBUG=1 I got a log file that shows:

sending : EHLO []^M
received: 502
sending : MAIL FROM:<dnrlinux@san.rr.com>^M
received: 503 5.0.0 Polite people say HELO first
sending : QUIT^M

Comment 1 Don Russell 2003-11-01 00:52:15 UTC
I tried stripping down the /etc/hosts file to remove white space and
comments, neither of those procedures changed the result for me
sending mail.

A comment though regarding the error pop-up:
"Error while performing operation" provides no valuie at all. OF
COURSE the error was while performing an operation... if no operation
was in progress then no error could happen. How about "Error while
sending mail"?

Why didn't evolution report the error reply from EHLO? THAT's the
cause of the problem. The reasom MAIL FROM failed is because the
server did not receive HELO first.

So, the error pop up should show...
Error while sending mail:
EHLO response error: 502
MAIL FROM response error: 503 Polite people say HELO first

Since EHLO failed, evolution should have done one of two things:
   1 - Try HELO
   2 - Quit then, there's no point in continuing if EHLO failed.

Comment 2 Don Russell 2003-11-01 00:56:09 UTC
I added you to the CC list... I can't send you mail, but this way
you'll see that I entered the bug in Bugzilla. :-)


Comment 3 Jeremy Katz 2003-11-03 03:23:01 UTC
What mail server is this connecting to?  If you just telnet to port
25, does the mail server specify that it allows ESMTP?

Comment 4 Don Russell 2003-11-03 15:24:15 UTC
When I:
   telnet smtp-server.san.rr.com 25

I get this reponse:
   220 orngca-mls01.socal.rr.com ESMTP *** FOR AUTHORIZED USE ONLY! 

Comment 5 Don Russell 2003-11-03 17:02:52 UTC
After reading the error handling specified in RFC1869, I'd have to 
say Evolution is not adhering to the RFC....

cut/paste from RFC 1869...
4.5 Error responses from extended servers
If the server SMTP recognizes the EHLO command, but the command 
argument is unacceptable, it will return code 501. 

If the server SMTP recognizes, but does not implement, the EHLO 
command, it will return code 502. 

If the server SMTP determines that the SMTP service is no longer 
available (e.g., due to imminent system shutdown), it will return 
code 421. 

In the case of any error response, the client SMTP should issue 
either the HELO or QUIT command. 
end cut/paste

This means my orginal comment is correct, if EHLO gets a 502 
response, Evolution should send HELO... as it is now, Evolution 
incorrectly sends MAIL FROM...

Comment 6 Paul Kline 2003-11-03 17:42:18 UTC
Support Page</a>

The above link is Ximian's support part.

I have had this issue on more than one computer.  I do not understand
why it does not work for Don.  Perhaps making a new /etc/hosts file
will correct it.  Please try again Don.

Comment 7 Don Russell 2003-11-03 18:05:14 UTC
Hi Paul,
From that site I see: (In reference to using the 
---begin paste---
When a message gets sent, some debugging messages will be written to 
the terminal window. Each of these lines will start with either 
sending : or received:. If there is a blank line immediately 
following the sending: EHLO ... line, then this glibc bug is the 

The workaround for this problem is to remove all blank lines and 
comment blocks (comments start with a #) from the /etc/hosts file.

---end paste---

I do not get the "blank line" they refer to above. I suspect this is 
a new bug, where Evolution is not properly handling a 502 response 
from EHLO.

According to RFC1869, a 502 from EHLO means EHLO is recognized, but 
not implemented. The proper action for the client to take after a 502 
from EHLO is to issue HELO or QUIT.

In the interet of removing doubt, I deleted /etc/hosts and created a 
new one....

Same result...

Comment 8 Jeremy Katz 2003-11-03 19:30:20 UTC
RFC1869 is superceded by RFC2821, though, which states that if you
specify that you support ESMTP that EHLO must be allowed.

Comment 9 Don Russell 2003-11-03 20:10:46 UTC
Also from RFC2821.... Section 2.2.1 Background...

---begin cut/paste---
(However, for compatibility with older conforming implementations, 
SMTP clients and servers MUST support the original HELO mechanisms as 
a fallback.)
---end cut/paste---

So, Evolution, upon receivnig a 502 (or any error actually) from EHLO 
MUST retry with HELO


Comment 10 Don Russell 2003-11-03 20:39:20 UTC
I reported this to the ISP support people too... advising them of 
RFC2821 and the requiment to allow EHLO (even if none of the 
extensions are supported/implemented)

Since I'm running Linux is this case, and they specifically do NOT 
support Linux, it will be interesting to see what sort of reply I get.

But, to go back to Evolution again... Evolution is not adhering to 
RFC18169 because it is not trying HELO after a failure from EHLO.

If Evolution is fixed to try HELO when EHLO fails, I beleive my 
problems will be solved, and Evolution will be in accordance with 
RFC1869 and 2821.


Comment 11 Don Russell 2003-11-03 20:47:00 UTC
I'm reopening this bug because I think there are a couple of 
corrections needed in Evolution.

1 - Evolution does not try HELO with EHLO fails. RFC2821 says it MUST 
do that.

2 - The error reporting of such an error is unnecessarily vague. See 
the orignal error text I posted above.... It might as well say "An 
error happened"... there error is not "unknown", it is 503...

Also, the error prior to that was not reported at all, and it's the 
crux of the problem. However, if "1" above is fixed, "2" becomes moot.


Comment 12 Don Russell 2003-11-04 02:21:51 UTC
Created attachment 95700 [details]
/etc/hosts file

This is my /etc/hosts file....
The first line was built by the install... I added the second line.

Comment 13 Paul Kline 2003-11-04 02:31:02 UTC
sending : EHLO []

This is maybe what is most likely giving you grief.  Normally, SMTPS
ignore invalid domains / ip, and proceed otherwise.  However, in your
case, the SMTP is not.  Thus giving you the 502.   I suggest you
configure your computer with the correct host to send to it. 

Hope This Helps,


Comment 14 Don Russell 2003-11-04 04:14:13 UTC IS the correct host... I'm behind a NAT router on subnet Am I supposed to configure evolution with my outside
address and keep track of that and update it every time it changes?
Does evolution require a non-NAT environment? That's crazy... :-)

The 502 means that EHLO is recognized, but not implemented.
According to RFC1869 and 2821 the client (evolution) MUST retry with
HELO if EHLO gets an error. According to RFC 2821 the server MUST
accept EHLO if it says it is an ESMTP server... so both server and
client are in error here.

I've advised my ISP... we'll see what they say...
The beauty of open source is I can change Evolution if I want to... I
just don't have the time right now.... 

Or, I can just drop evolution like a hot potato... this is more grief
than it's worth... :-)

Jeremy closed this bug when he said RFC2821 obsoleted 1869 without
concern that evolution doesn't adhere to that either.

I'm not going to develop a bug fix for this if their attitude is "it's
not a bug".... I'll just find a new e-mail client.

I appreciate your help, but I really think the problem is that
evolution does not properly handle error 502 from EHLO...

As per the RFC the correct handling of such an error is to retry with
HELO, or terminate with QUIT. Instead evolution continues with MAIL
FROM... that is just plain incorrect... the RFC is very clear on that.

So, yes, they could comply with the RFC by QUITting, but in the
interest of making the software work with the most number of (E)SMTP
servers, they should retry with HELO.


Comment 15 Don Russell 2003-11-04 04:32:01 UTC
I was just reading over RFC2821 again... section 4.1.4...

You can see that the specification of EHLO [ ] is valid
syntax, and the server MUST NOT reject the command just because it
can't verify the parameter.

Also, this is another violation of the RFC by Evolution.... provides no information whatsoever.... that is a private
address on the 10.*.*.* IP range, just like 192.168.*.* ...

Evolution should be building a different string to use as the
parameter on EHLO.... but that's a nit. :-)

The real problem is that evolution does not handle 502 from EHLO
properly, plain and simple.


The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a valid principal host name (not a CNAME or MX
   name) for its host.  If this is not possible (e.g., when the client's
   address is dynamically assigned and the client does not have an
   obvious name), an address literal SHOULD be substituted for the
   domain name and supplemental information provided that will assist in
   identifying the client.

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.
--- end cut/paste---

Comment 16 Don Russell 2003-11-05 22:38:25 UTC
I knew this was a bug in Evolution so decided to report it to ximian 
directly... it is now resolved via a patch available at...


THIS bug can be closed in favor of the ximian bug....


Comment 17 Jeremy Katz 2003-11-06 23:50:55 UTC
Cool, Jeff beat me to the patch then after talking with him on
#evolution.  Will be in the next build.

Comment 18 Don Russell 2003-12-20 03:40:35 UTC
When will this be available via up2date for Fedora Core 1?


Comment 19 kevin reichhart 2004-06-29 13:11:22 UTC
This bug also affects evolution-1.4.5-1 on RHEL AS3 U2.

Comment 20 Don Russell 2004-06-29 13:45:06 UTC
This bug was exposed by my Cisco router firewall... for complete 
details refer to the "upstream bug" at 

In a nutshell, if you are using the Cisco IOS firewall with an
statement in effect, when Evolution sends EHLO, the firewall changes 
that unknown-smtp-command to XXXX which of  course the server 
rejects. Evolution then chokes on the failure.

Evolution should NOT be looking at the text upon connection to (E)
SMTP server, but rather it should just start with EHLO and on failure 
fall back to HELO.

Two major points now:
1 - A patch is available from ximian/Evoltion to do as above
2 - Cisco IOS 12.3(7)T adds a new firewall option... ESMTP

Comment 22 John Thacker 2006-10-29 22:52:56 UTC
[This is a mass update sent to many bugs that missed earlier such messages due
to having their version set to a test version.]

This bug was originally filed against a version of Fedora Core which is no
longer supported, even for security updates.  Many changes have occured since
then.  Please retest this bug against a still supported version.  Note that FC3
and FC4 are supported by Fedora Legacy for security fixes only.  If
it still occurs on FC5 or FC6, please assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

This bug will be closed after a few weeks if no information is given indicating
that the bug is still present in a supported release.

Comment 23 Don Russell 2006-10-29 23:49:31 UTC
As per comment #16 this bug can be closed, having been successfully solved by

Thank you.

Comment 24 Matthew Barnes 2006-11-11 03:56:44 UTC
Closing as requested.

Comment 25 Don Russell 2006-11-11 06:40:54 UTC
"Fixed: UPSTREAM" would have been a more appropriate resolution. Ref. Comment #16

Note You need to log in before you can comment on or make changes to this bug.