GNOME Bugzilla – Bug 257951
Evolution guilty of 'smtp slamming' (rfc2821 deficiency)
Last modified: 2004-05-02 14:12:23 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: When sendmail 8.13 is released it will sport a new anti zombie-spam-machine feature called 'greet_pause'. This feature allows an administrator to set a delay for the transmission of the smtp greeting. If any traffic is received from the smtp client before the greeting is transmitted, then a 554 error is sent with the string 'ESMTP not accepting messages' and all further commands rejected. (Arguably, it might make more sense to just drop the connection, but that might violate rfc2821 nor is it relevant to this bug.) I've backported this feature to sendmail 8.12.11 and patched the Fedore Core 2 Test 3 rpm (sendmail-8.12.11-4.6.src.rpm) with it. (It's a small amount of non-invasive C code and a FEATURE in m4.) I then enabled it and tested it by typing the smtp commands after doing a 'telnet localhost smtp'. I had my greet_pause value set to 1500 (1.5 seconds). If I enter any text before the greeting appears (1.5 seconds after the connection is established), then my all my commands get rejected as they should. Next, I bring up evolution (both 1.4.5 and 1.5.7 tested) and set this new smtp server as my outgoing smtp mail server. Compose a new message, hit send, and *bang* it gets rejected with a pop message that reads like this: =-=- cut here =-=- Error while performing operation: Welcome response error: Transaction failed =-=- cut here =-=- Setting my greet_pause value back to zero (or disabling the feature completely), allows messages to go through. This indicates that evolution is issuing smtp commands before receive the connection greeting. Although it is a conditional 'SHOULD' in rfc2821 (see section 4.3.1, second paragraph), I'd like to see evolution be more compliant in this one area. The new greet_pause feature in the upcoming sendmail release is yet one more (admittedly small) weapon in the arsenal in the fight against spam. I'd like to be use it without workarounds for a problem with what I consider the best MUA available for GNU/Linux. Steps to reproduce the problem: 1. Build, install, configure (including the greet_pause feature) and start sendmail 8.13.0.Alpha0. 2. Launch Evolution and set this new smtp server as the outgoing smtp server. 3. Attempt to send mail through this new smtp server Actual Results: Error while performing operation: Welcome response error: Transaction failed Expected Results: Evolution should wait for the smtp greeting before sending any smtp commands so that mail can go through successfully. How often does this happen? Every time. Additional Information: Fix it and I'll buy you a virtual beer. ;-) (Er, well, we'll figure something out.)
uh.... it can't possibly be sending commands before it finishes reading the greeting because the code blocks until it receives a response from the preview command (or, in the case of the greeting, until the greeting has been read). you can see for yourself in the code that what you claim is impossible. also note that "Welcome response error" means "error getting the server greeting" :-) generally this error is caused by a dropped connection or a tcp timeout (where the tcp timeout is whatever the tcp stack uses, we don't set our own tcp timeout).
Arg! Dang it. I had this beautiful rebuttal I was going to add to this bug and lo and behold I think I found out what's going on. TLS. Apparently, this new greet_pause idea in sendmail doesn't play well with TLS. I ran an smtptest (comes with cyrus-imapd) with all the appropriate options (regarding TLS/SSL in particular) and got the same error. I turned off SSL in evolution an voila! It worked. So now I know what the problem is and it's not evolution. Crap. I hate being wrong. Well, I don't really mind, but I hate when it's forever embedded in a bug database just how wrong I was. Sorry! I'll close this bug now and go crawl back into my hole.
Yeah, SSL'd do it :-) I was wondering about that, but figured you weren't using it because you tested with telnet. anyways, being wrong isn't a big deal. I'm wrong sometimes too :-)