GNOME Bugzilla – Bug 250535
Doesn't handle EHLO errors properly
Last modified: 2004-03-09 17:12:20 UTC
Distribution: Fedora Core release 1 (Yarrow) Package: Evolution Priority: Major Version: GNOME2.4.0 unspecified Gnome-Distributor: GNOME.Org Synopsis: Doesn't handle EHLO errors properly Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: unspecified Description: Description of Problem: Evolution doesn't handle error 502 from EHLO properly resulting in my inability to send mail. Steps to reproduce the problem: 1. create mail item 2. press send 3. Actual Results: Get error pop-up: Error while performing operation. MAIL FROM response error: unknown Expected Results: I expected my mail message to be delivered. How often does this happen? Always, every single time. Additional Information: 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@san.rr.com>^M received: 503 5.0.0 Polite people say HELO first sending : QUIT^M This is a violation of RFC 1869 and 2821.... if EHLO fails with an error, it SHOULD retry with HELO, or it MAY terminate with QUIT. Secondly, why did evolution report the error as "unknown" when kt is clearly 503... Third, why did the error reply for EHLO not get reported at all? The SMTP server is smtp-server.san.rr.com Unknown reporter: drussel2@san.rr.com, changed to bugbuddy-import@ximian.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
What Evolution version is this?
Please reopen this report when you reply
Sorry... I thought that info was included.... evolution 1.4.5-7
Reopening as requested...
Created attachment 43050 [details] [review] 50535.patch
note that your server is technically broken in that it advertises ESMTP in the greeting... if it didn't, then this code path could never be hit.
Jeff, Yes, I discovered that too and have reported it to my ISP... However, with this patch applied, YOUR code will now comply with RFC2821 which states mail clients should (preferrably) always send EHLO and then fallback to HELO upon failure. So, even though my ISP smtp-server is not behaving correctly, your client will now be tolerant of that error. Thanks for addressing this... now I just have to figure out how to apply the patch. :-) Cheers, Don
patch applied to CVS
Thanks Jeff... do you have an estimate for which evolution version/build this fix will be included in? If I get evolution updates from Redhat/Fedora I want to skip any evolution updates prior to the version with this fix in it. (I still haven't had a chance to try/test the fix) Thanks, Don
Is there a new build of Evolution since 1.4.5-7 that has this fix applied? Thanks, Don
1.4.6 will be out really soon now (TM)
*** bug 254423 has been marked as a duplicate of this bug. ***
This correction is valid and in keeping with the RFC's, however I recently discovered a possible work around depending on network configuration/topology. > IF you are behind a Cisco router running the Cisco firewall with an "inspect name (name) smtp" statement in effect AND the smtp server you connect to supports ESMTP, then this error will occur because the firewall software in IOS does not recognize EHLO as a valid SMTP command and changes it to XXXX. Of course that fails. The work around is to NOT "inspect" smtp traffic. The SOLUTION is to upgrade to IOS 12.3(7)T and change the inspect rule from SMTP to ESMTP. > For complete information, refer to the Cisco documentation at http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123new ft/123t/123t_7/gt_esmtp.htm > Again, this correction in Evolution should still be implemented, because the way Evolution 1.4.5 works now is contrary to the RFCs. > Best regards, Don Russell