Email is bouncing

xcobaltdude

Verified User
Joined
Aug 25, 2004
Messages
24
Greetings,
Running RHEL3, DA 1.24.0, Exim 4.44.......since the update to DA 1.24, many of our clients, myself included, are having incoming emails bounced.
Here's the message sent back to the original sender:

----begin message-----

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es)
failed:

[email protected]
local delivery failed

The following text was generated during the delivery attempt:

------ [email protected] ------

An error was detected while processing a file of BSMTP input.
The error message was:

421 SMTP incoming data timeout - message abandoned

The SMTP transaction started in line 0.
The error was detected in line 3.
0 previous messages were successfully processed.
The rest of the batch was abandoned.
421 SMTP incoming data timeout - message abandoned
Transaction started in line 0
Error detected in line 3

----end message-------

That's all that we see.....We've had to restart exim twice since May 5 in order to receive email. There were no problems prior to the
Any ideas?
Anyone else experiencing the same?


Thanks......
 
not sure but i am having the same problems.

check your /var/log/exim/mainlog

see if yuo get child processess dying from spam assassin.

also do

ps aux | grep exim if you see a lot of defunct and messages just sitting there it appears spam assassin is not working for you either.

i am having this exact issue and am still lookin for a fix as it appears to be SMP kernel specific for some reason.
 
We're running RedHat EL3......
I think a temporary fix might be to run a cron every hour to restart exim. Restarting exim seems to temporarily solve the problem.

Something else I noticed as well - since the update to 1.24.0, our backups don't seem to work. We perform backups via ftp using the DA backup scheduler. The schedule operates, makes the backup and connects to our backup server, but the files fail to upload. I've watched the connection, so I know that ftp works. It's just that the files are never uploaded.
 
hey vandal, you still having these problems?

One thing I found out is that it is not the DA 1.24 update that is causing the problem. I checked our logs and we didn't update DA until 12 hours after we saw our first bounces.
I checked what up2date had been doing in the last few days, and discovered that 2 packages had been updated shortly *before* we started having these problems.
The 2 packages are:
sharutils-4.2.1-16.2.i386.rpm
cvs-1.11.2-27.i386.rpm
Other than that, nothing has changed as far as I can tell.
 
oh yeah still having problems.

I disabled spamd from talking to exim by commenting it out.

even restarting mine was getting worse and worse depending on load.

using exim 4.51 and spam assassin 3.03 and all the same problems.

from my research the problem seems to be a exim bug.

check this cpanel thread where users are having the same problem as us: http://forums.cpanel.net/showthread.php?t=12359&page=10&pp=15

i have tried many things, raising the spamd threads to 40 and other things but nothing helps.

when i get some time i may try the guys patch on that thread by installing exim from source pre-patched with that fix and see if it works.
 
We turned off spamassassin for a few domains for testing purposes, removed the cron job to restart exim and now everything appears to be okay (hopefully I didn't just curse myself).
We're behind hardware firewall so we just utilize bare-bones iptables rules.
I though DA exim was at 4.44; our spamassassin's are all 2.55-3.2, so there are so differences between what you and I are running.
Exim logs did show about 2 dozen (on May 5th) of the child processes you mentioned, but only for a few domains, even though very many domains were receiving mail.
 
yeah i'm still trying to figure it out too. please let me know if you do find a resolution. :(

it is very random or it's due to load. but some emails were still getting messages while others were just not and user experienced bounce backs.

but sometimes it would be a week before it started doing it.

but it's sad to say i have had to shut off spamd for now as well.
 
Last edited:
Yep, I cursed myself. After working properly for quite a few hours, emails started bouncing at 6:22 EDT this morning, and it's random domains which have bounced email.
I also discovered that it doesn't matter if spamassassin is available to the users' control panel - emails bounced for those domains with or without spamassassin access, so the problem isn't in that area.
We've now shut down spamd as well. No other choice at this time.
 
Last edited:
I finally got around to registering on their forums.....very interesting that this issue goes that far back, I had no idea...
Certainly let us know if that patch helps at all.....
 
a certain patch was put into exim 4.51

this might fix it:

PH/45 In a pipe transport, although a timeout while waiting for the pipe
process to complete was treated as a delivery failure, a timeout while
writing the message to the pipe was logged, but erroneously treated as a
successful delivery. Such timeouts include transport filter timeouts. For
consistency with the overall process timeout, these timeouts are now
treated as errors, giving rise to delivery failures by default. However,
there is now a new Boolean option for the pipe transport called
timeout_defer, which, if set TRUE, converts the failures into defers for
both kinds of timeout. A transport filter timeout is now identified in
the log output.

although i am not certain someone said to try adding temp_errors = * to the spamcheck directive. it would look something like this:

spamcheck:
driver = pipe
batch_max = 100
command = /usr/sbin/exim -oMr spam-scanned -bS
current_directory = "/tmp"
group = mail
home_directory = "/tmp"
log_output
message_prefix =
message_suffix =
return_fail_output
no_return_path_add
transport_filter = /usr/bin/spamc -u
${lookup{$domain}lsearch*{/etc/virtual/domainowners}{$value}}
use_bsmtp
user = mail
temp_errors = *
# must use a privileged user to set $received_protocol on the way back in!

so far so good, however it's only been an hour or so and i'm still researching. I will keep you all posted.
 
Any updates for us, Van Man?

Did you use the newest version of Exim, or add the patch?

Did you make the changes to the spamcheck directive?

And most importantly, has anything you've done solved the problem?

I'm thinking of compiling the latest version of exim from the DA site's source code. It's .51; should it solve the problem?

Thanks.

Jeff
 
Hey Jeff,

well it's to early to tell right now but adding the temp_errors = * so far I have had no child process errors or bounced messages due to spamd.

but then again sometimes it would go for a while without error so lets give it at least a couple days before I can say it's working.

xcobaltdude you should try the same and see if we get the same results.

btw i still haven't forgotten about getting you cpanels 4.51 exim.conf (for the other double piping issue) they just haven't released it stable yet.

Ii am using exim 4.51 and spam assassin 3.0.2 da's normal rpm build.
 
Even with spamd "off", none of our clients have complained about spam, and credit should go to Jeff Lasman and his SpamBlocker.
Perhaps I'm paranoid, but I think I'll wait until DA issues an Exim rpm for 4.51, unless either of you doesn't have any problems (with the source file) until that time.
The darn thing about it, it was so random. I watched emails being rejected for a specific email address while others were being delivered at the same time for the same domain. And then nothing rejected for 2 or 3 days. For our clients that actually lost email, we offered an extra month (free) of hosting.
What's strange is that apparently this very thing has been occuring since 2004 and we'd never seen it. It's Frelling bizarre.
 
Back
Top