Red Hat Bugzilla – Bug 108753
Get MAIL FROM error sending mail
Last modified: 2007-11-30 17:10:32 EST
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
The mail item remains in the outbox.
Version-Release number of selected component (if applicable):
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.
Using CAMEL_VERBOSE_DEBUG=1 I got a log file that shows:
sending : EHLO [10.10.10.14]^M
sending : MAIL FROM:<email@example.com>^M
received: 503 5.0.0 Polite people say HELO first
sending : QUIT^M
I tried stripping down the /etc/hosts file to remove white space and
comments, neither of those procedures changed the result for me
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
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 22.214.171.124 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.
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. :-)
What mail server is this connecting to? If you just telnet to port
25, does the mail server specify that it allows ESMTP?
telnet smtp-server.san.rr.com 25
I get this reponse:
220 orngca-mls01.socal.rr.com ESMTP *** FOR AUTHORIZED USE ONLY!
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
In the case of any error response, the client SMTP should issue
either the HELO or QUIT command.
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...
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.
From that site I see: (In reference to using the
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.
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
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
RFC1869 is superceded by RFC2821, though, which states that if you
specify that you support ESMTP that EHLO must be allowed.
Also from RFC2821.... Section 2.2.1 Background...
(However, for compatibility with older conforming implementations,
SMTP clients and servers MUST support the original HELO mechanisms as
So, Evolution, upon receivnig a 502 (or any error actually) from EHLO
MUST retry with HELO
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.
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
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.
Created attachment 95700 [details]
This is my /etc/hosts file....
The first line was built by the install... I added the second line.
sending : EHLO [10.10.10.14]
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,
10.10.10.14 IS the correct host... I'm behind a NAT router on subnet
10.10.10.0/24. 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.
I was just reading over RFC2821 again... section 4.1.4...
You can see that the specification of EHLO [ 10.10.10.14 ] 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....
10.10.10.14 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---
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....
Cool, Jeff beat me to the patch then after talking with him on
#evolution. Will be in the next build.
When will this be available via up2date for Fedora Core 1?
This bug also affects evolution-1.4.5-1 on RHEL AS3 U2.
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
INSPECT NAME name SMTP
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
[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.
As per comment #16 this bug can be closed, having been successfully solved by
Closing as requested.
"Fixed: UPSTREAM" would have been a more appropriate resolution. Ref. Comment #16