Hide Forgot
Since I updated my system to Rawhide (and hence Evo 3.1.2), nearly every time I send an email, I get two failures (and have to hit 'Try Again') before it succeeds: "The reported error was "MAIL FROM command failed: mail.happyassassin.net Error: timeout exceeded"." and then: "The reported error was "MAIL FROM command failed: Connection reset by peer"." I suspect what's happening is Evo is not correctly closing the connection to the server after it sends a mail, so the next time you try to send a mail it tries to re-use the still-open connection from the last time you sent a mail, and this fails. The server in question is my own personal server, which is Postfix running on a Mandriva 2011 VM. It may be that I could configure my server somehow to allow the behaviour Evo is trying, but I consider it a bug that Evo regressed from working correctly with my SMTP server configuration in 3.0 to failing like this in 3.1, especially since I can't seem to find any preference to control this behaviour. I can grab logs from the server end if that would help. (The new 'IMAP+' protocol seems to have similar issues with my IMAP server, courier-imap running on the same box; if I use it instead of the 'IMAP' protocol, I get errors about exceeding the maximum number of simultaneous connections or something like that.)
(In reply to comment #0) > I suspect what's happening is Evo is not correctly closing the connection to > the server after it sends a mail, so the next time you try to send a mail it > tries to re-use the still-open connection from the last time you sent a mail, > and this fails. Sounds plausible. If you send a second mail shortly after successfully sending the first one, does the second mail go through without problems?
"If you send a second mail shortly after successfully sending the first one, does the second mail go through without problems?" Seems to be the case, yes.
I'm also seeing stuff like this in my mail server logs: Jun 28 19:00:53 mailserver postfix/smtp[30298]: E06DE505D4: to=<test aproject.org>, relay=int-mx.corp.redhat.com[10.4.122.10]:25, delay=0.74, delays= 0.02/0.02/0.49/0.22, dsn=2.0.0, status=sent (250 2.0.0 p5T20r2l032487 Message ac cepted for delivery) Jun 28 19:00:53 mailserver postfix/qmgr[6780]: E06DE505D4: removed Jun 28 19:06:36 mailserver postfix/smtpd[30293]: timeout after END-OF-MESSAGE from unknown[192.168.1.1] Jun 28 19:06:36 mailserver postfix/smtpd[30293]: disconnect from unknown[192.168.1.1] which seems to support my conjecture (note the email is sent at 19:00, then the timeout at 19:06). Other senders - here's my webserver sending out a mail via the same server - seem to disconnect immediately after submitting, even before the message is actually forwarded on: Jun 28 13:39:12 mailserver postfix/smtpd[29984]: connect from unknown[192.168.1. 4] Jun 28 13:39:12 mailserver postfix/smtpd[29984]: 1C7FD505E1: client=unknown[192. 168.1.4] Jun 28 13:39:12 mailserver postfix/cleanup[29988]: 1C7FD505E1: message-id=<20110628203911.161B33AA1F> Jun 28 13:39:12 mailserver postfix/qmgr[6780]: 1C7FD505E1: from=<apache>, size=1829313, nrcpt=1 (queue active) Jun 28 13:39:12 mailserver postfix/smtpd[29984]: disconnect from unknown[192.168.1.4] Jun 28 13:39:19 mailserver postfix/smtp[29989]: 1C7FD505E1: to=<adamwill>, relay=shawmail.vc.shawcable.net[24.71.223.43]:25, delay=7.8, delays=0.41/0.01/0.73/6.6, dsn=2.0.0, status=sent (250 ok: Message 259242306 accepted)
While testing the above, I noticed a couple of times where it completely failed to send the message, silently - which is much worse :( It would display one error from the server, I'd hit 'Try Again', and it would go away, and even put the mail in the Sent box - but it wasn't actually sent, as my mail server log confirms. I had to try it again immediately after, and it would work, leaving me with two copies in my Sent box, only one of which really went out...
Thanks for a bug report. I noticed similar behaviour earlier too, but not always. The server probably didn't disconnect so quickly. I moved this upstream, as [1], because this isn't fedora specific. Please see [1] for any further updates, though I've a fix for it, thus this will be fixed in the next release. [1] https://bugzilla.gnome.org/show_bug.cgi?id=653618