From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031027 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): evolution-1.4.5-7 How reproducible: Always Steps to Reproduce: 1. Create a new mail messgae 2. Press "send" 3. 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 [10.10.10.14]^M received: 502 sending : MAIL FROM:<dnrlinux.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 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 5.0.0.0 Polite people say HELO first Since EHLO failed, evolution should have done one of two things: 1 - Try HELO or 2 - Quit then, there's no point in continuing if EHLO failed.
Paul, 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. :-) Don
What mail server is this connecting to? If you just telnet to port 25, does the mail server specify that it allows ESMTP?
When I: 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 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...
<a href="http://support.ximian.com/cgi-bin/ximian.cfg/php/enduser/std_adp.php?p_sid=mYRAjrXg&p_lva=&p_faqid=438&p_created=1064953962&p_sp=cF9ncmlkc29ydD1mYXFzLnVwZGF0ZWQ6RCZwX3Jvd19jbnQ9MTUmcF9zZWFyY2hfdGV4dD0mcF9zZWFyY2hfdHlwZT00JnBfcHJvZF9sdmwxPTImcF9wcm9kX2x2bDI9fmFueX4mcF9jYXRfbHZsMT00JnBfcGFnZT0x&p_li=">Ximan 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.
Hi Paul, From that site I see: (In reference to using the CAMEL_VERBOSE_DEBUG=1) ---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 problem. 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...
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... ---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 Don
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. Don
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. Don
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.
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, Paul
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. Don
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. Don ---cut/paste--- 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... http://bugzilla.ximian.com/show_bug.cgi?id=50535 THIS bug can be closed in favor of the ximian bug.... Don
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? Thanks.
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 http://bugzilla.ximian.com/show_bug.cgi?id=50535 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 http://bugzilla.gnome.org/show_bug.cgi?id=250535 Thank you.
Closing as requested.
"Fixed: UPSTREAM" would have been a more appropriate resolution. Ref. Comment #16